任务看板应先定义每个状态允许进入哪些后续状态，再设计拖拽。跨列移动可能改变责任人、验证要求和通知对象；同列移动通常只改变顺序。对需要补信息的转换，放下卡片后先完成补填；对提交失败或多人同时修改，恢复到服务端确认的状态并说明原因。同时提供“更改状态”菜单，让用户不用拖动也能完成同一任务。
以缺陷 BUG-214“优惠券金额未刷新”为例：开发人员准备把它从“处理中”交给测试，测试通过后再进入“完成”。可以借助在线原型设计与交互演示把这次流转的页面连起来，评审重点是任务是否真的交出去了，而不只是卡片动画是否顺滑。
四列看板，先写清六条有效转换
本例的业务状态是“待处理、处理中、待验证、完成”。责任人决定谁处理缺陷，验证人决定谁检查修复结果。以下规则是案例约定：开始处理需要责任人；提交验证需要验证人和修复说明；验证未通过或重新打开需要原因。
| 当前状态 | 允许的下一状态 | 转换时必须说明 |
|---|---|---|
| 待处理 | 处理中 | 由谁开始处理 |
| 处理中 | 待处理 | 为何退回待分配，责任人是否保留 |
| 处理中 | 待验证 | 验证人、修复说明 |
| 待验证 | 处理中 | 未通过的验证项与返回原因 |
| 待验证 | 完成 | 验证结论及有权确认的操作者 |
| 完成 | 待处理 | 重新打开原因 |
因此，BUG-214 在“处理中”时不能直接拖到“完成”。如果某产品确实允许负责人跳过验证，需要在规则中另行列出这种转换及适用角色，界面再表现它，不能通过“所有列都能拖入”默认开放。
状态和列也不一定一一对应。例如把“处理中”和“等待外部反馈”合并展示在“进行中”列时，列内两张卡片可能具有不同业务状态。Jira 的列配置说明就允许把多个状态映射到一列。设计自己的看板时，应明确列的展示归组和卡片的业务状态，不能仅凭列名发送状态变更。
拖到哪里、是否能放，拖动途中就要看得懂
开始拖动 BUG-214 时，卡片标题或编号必须保持可辨认，原位置留出线索。可进入的列显示有效落点，不可进入的列给出稳定的限制提示；指针移到“完成”列时，可以提示“此缺陷需先完成验证”，避免松手后卡片毫无解释地弹回。
目标列如果包含多个业务状态，落点必须进一步说明目标，例如“转为等待反馈”，或在放下后让用户选择。不能随机取该列的第一个状态。若状态转换需要填验证人，落点可以先标明“移到待验证后需补充信息”，减少突然出现表单的意外。
同列排序另有规则。当列表按优先级或更新时间自动排列时，用户手动拖出的顺序可能立即被自动排序覆盖。此时可以关闭手动排序并说明当前排序依据；跨列状态转换仍可保留。需要设计任意位置调整时，可继续阅读拖拽排序中的插入位置与替代操作，它解决的是位置表达，本例则着重状态含义。
列标题数字要与显示范围一致。筛选“只看分配给我”后显示3张卡片，标题不能不加说明地写成全列18项。若需要同时体现工作总量，可写“显示3项，共18项”；卡片因转换不再符合当前筛选而消失时，也应告诉用户它已转到哪个状态。
“交给测试”需要一个小表单，不需要整页编辑
开发把 BUG-214 放到“待验证”后，本例打开“提交验证”面板，顶部显示缺陷编号和标题，下面只放验证人、修复说明等本次转换所需字段。原缺陷的标题、优先级等不必重新填写。主按钮写“提交验证”，取消按钮关闭面板并保留“处理中”。
补填期间，卡片还没有完成状态变更。可以把它留在原列，并在面板中预览目标状态；也可以显示一张明确标记“待提交”的临时卡片，但不能同时在两列各算一项。本例在未提交补填面板时把卡片留在原列；用户点击“提交验证”后，才将卡片移到目标列并标记“正在更新”，等待保存结果。
如果验证人已经离开项目，保留修复说明，只要求重新选择验证人。取消面板则放弃这次转换，不把卡片留在“待验证”又不通知测试。更改状态菜单、卡片详情里的状态按钮和拖拽入口都应该打开同一份补填内容，避免一条路需要验证说明、另一条路却直接通过。
在 Pixso 中先画一张四列缺陷看板，再复制出“拖入待验证”“补填验证人”“正在提交”“状态已更新”四个画板，始终使用缺陷 BUG-214。把取消补填连接回原列，把提交失败连接到恢复后的页面；连线旁注明这是状态转换，卡片的同列位置另行处理。
可打开 Pixso 绘制 BUG-214 的状态流转，分别演示拖拽入口和“更改状态”菜单入口。两条路径应到达同一补填页与同一结果，菜单也能用点击、轻触和键盘完成操作。把验证人、修复说明和取消后的落点逐项标在对应画板旁。
卡片已经移过去，却没有保存成功怎么办
先确定一种一致的提交反馈。对于跨列转换，本例让卡片在目标列显示“正在更新”，禁止对同一张卡片连续发起冲突转换；得到成功回执后才显示最终状态。对于需要额外确认的关键流转，也可以等成功后再移卡片，但等待期间必须有可见反馈。
| 返回情况 | 卡片位置 | 反馈与恢复 |
|---|---|---|
| 明确保存成功 | 服务端确认的目标列 | “BUG-214 已提交验证”，显示验证人 |
| 明确校验拒绝，原状态未变 | 回到确认的原列 | 指出无效字段，保留本次修复说明供修改 |
| 请求结果暂时未知 | 标记状态待确认 | 查询最新状态，暂不宣告成功或失败 |
| 任务已由他人改动 | 最新确认状态所在列 | 说明状态已更新，提供查看最新详情 |
| 任务已被删除或不再可见 | 按最新权限与存在状态处理 | 说明当前无法继续，不让用户反复拖动失效卡片 |
网络超时不等于服务端拒绝。若回读发现 BUG-214 已进入“待验证”，应结束待确认状态，不能把它拖回“处理中”制造相反结果。如果回读仍然失败，可保留“状态待确认”提示和重查入口，让用户知道当前画面还不能作为最终依据。
多人协作时也不能简单回滚到拖动前的本地快照。开发提交验证的同时，负责人可能已退回任务并修改责任人。回读后应展示当前确认版本，解释“该任务已由他人更新”，保留用户刚写的说明供参考；再次操作前由用户决定是否仍要执行原转换。
重新打开是一条业务路径，不是把卡片往左拖
测试在新版本中再次遇到 BUG-214，选择“重新打开”。这次动作需要记录重现条件，让后续处理人区分旧问题复现和新问题。完成时间、旧验证记录如何展示，也应事先定义：可以保留历史记录，当前状态恢复为“待处理”，不要把旧的处理经过抹掉。
“撤销刚才的移动”和“重新打开已完成缺陷”也不等价。前者可能只在某次转换后提供短暂恢复能力；后者是业务允许的后续动作，仍受当前权限和字段规则约束。若自动通知或其他后续操作已经发生，界面不能用一个没有范围说明的“撤销”承诺把所有结果一并恢复。
最后用同一张卡片做一次有干扰的评审：开发把缺陷提交验证，测试退回并写明失败步骤，开发再次提交，验证人完成后又发现复现。让参与者每一步都回答“现在谁负责、缺什么信息、下一步能做什么”。如果必须由设计师口头解释这些问题，优先修改卡片状态、转换面板和结果反馈，再处理动画与装饰。
