04 · 设计 · 驳回之后
红了还停在班组长列表里，工人不知道要改
交互设计师规定状态、待办和失败之后单据回到谁手里，让驳回不用打电话也能改完。工位屏视距和字号交给 UI，任务顺序先由原型走通。
原型：完工被班组长驳回，单据标红，停在班组长的已驳回里。
工人：我怎么知道要改数量？等班组长打电话。
交互：驳回要同时做三件事：状态回到待工人修改，出现在工人待办，原因是班组长刚写的那句。报完工成功不再弹必须点掉的提示。
交互设计师为状态负责，不为品牌色负责
原型证明人能顺着走完，交互设计师要证明人在走错、被拒绝、没权限、正在等待时还能回来。公开的交互岗位通常写用户旅程、信息架构和反馈机制。落到单据系统里，旅程不是宣传页上的五步，而是一张单的状态机：每个状态谁看得见、谁能改、失败停在哪里、成功要不要打断双手都占着的人。
他和 UI 设计师的交接是状态表，不是视觉稿。危险且不可逆的动作才二次确认，例如作废已付款单据。高频且正确的动作不确认，例如连续报完工。确认弹窗在办公室里是安全，在工位上就是误触和延误。空数据、加载中、无权限、查询失败，不共用同一句「暂无数据」。共用之后，人会以为今天没有工票，其实是账号没有这台机床的权限。
待办是交互的核心对象
很多系统把状态存在单据上，却不把下一步放进当事人的列表。班组长驳回后单据变红，颜色不是通知。交互要求每一个「等待某人」的状态都生成一条待办，待办上写原因原文，点进去就落在可编辑的字段，而不是只读详情再让人自己找编辑入口。待办完成的条件是状态离开这个人，不是他点过一次知道了。
他也规定返回。从待办跳到查在制品，返回必须回到刚才那张未完成的工票，而不是首页。企业软件里丢上下文比配色错误更贵，因为人会重新报一张工，旧票变成垃圾数据。扫码枪把字符打进哪一格，不在本页设计，交给兼容性用验收设备证明。
驳回对话怎样变成可测试的行为
工票被班组长驳回后，旧设计只改颜色。工人的列表按创建时间排序，驳回的单沉下去。他接到电话才知道。交互把行为写成三条，测试可以直接当用例：驳回瞬间，单据从班组长待办消失，出现在原工人待办的第一条；原因显示班组长输入的句子，不显示错误码；工人改完完工数重新提交前，不能把这张工单标成已入库。成功提交只改顶部状态条，不弹窗。弹窗会被袖口点掉，人不知道点掉的是确认还是取消。
这三条交给前端时，交互参加一次走查，用驳回而不是用幸福路径。走查通过的标准是工人不需要旁人开口就能改完。做不到，就不算交互已经交付。UI 设计师可以随后加强原因的字号和颜色，但不能把待办取消，改成只在详情里显示一个红点。
交互设计师还要为同一张单的入口负责。待办、消息和列表点进去必须是同一状态，不能一个入口可编辑、另一个入口只读。只读入口会让人以为自己改过了，其实改在另一个页面。电话因此又会打回来。把入口收成一个，是这个岗位在企业系统里最容易被忽略、也最值钱的部分。