UI设计走查怎么做？交付前的状态检查清单

UI 设计走查可以从一条真实任务开始：固定入口与测试数据，按顺序检查操作、异常状态和页面布局，再把发现的问题写成“出现条件、当前画面、预期结果、修改位置”。交付前先检查设计稿是否把规则画全，研发完成后再验证真实运行行为。同一套检查记录可以贯穿两次检查，但不能把静态画面通过当作功能已通过。

以“管理员邀请一名项目成员”为例，在Pixso 的界面设计与协作画布中把邀请表单、错误反馈、提交中和结果页面放在一起，逐项核对用户每一步能看到什么、还能做什么。走查完成后，设计师应能指出缺少哪幅状态、哪条规则以及哪个位置需要修改。

先把走查范围限定在一条用户任务

这次只检查“在已有项目中邀请成员”，不把新建项目、套餐购买和全部权限管理一起放进来。起点是管理员已进入成员列表，终点是邀请已发出，列表里能看到被邀请邮箱、指定角色和待接受状态。发出邀请不等于对方已经加入，这两个结果必须区分。

这些是示例业务规则，实际项目可以采用不同角色或邀请机制，但必须先确定自己的规则。否则设计、研发和测试可能各自把“邀请成功”理解为发信成功、成员已加入或权限已生效。

第一层：从入口走到结果，检查动作是否连续

按“打开邀请表单—输入邮箱—选择角色—发送邀请—核对结果”的顺序检查。不要刚打开表单就跳去讨论圆角，先看是否缺少让任务继续的操作与反馈。

1. 打开：成员列表能找到邀请入口；表单标题说明正在邀请到哪个项目，取消后能回到原列表。
2. 填写：邮箱字段有明确标签；选择角色时能理解该角色的权限，不只看到一个陌生名称。
3. 发送：按钮文案说明动作；提交中有反馈，避免让用户因为没有反应而重复操作。
4. 确认：邀请结果包含邮箱和角色；列表区分待接受与已加入，失败时不会出现成功记录。

在原型里可以逐步检查跳转与反馈画面；如果原型没有真实输入或服务端响应，用对应状态画板说明变化。不要把原型里的固定跳转当作邮箱校验、邮件发送或权限控制已经实现。

在 Pixso 中，可从画板的流程标签或原型面板进入演示，再在演示侧栏选定要检查的流程。先固定起点，沿同一条路径逐步操作；修复后从这个起点重新检查。

第二层：用六组输入找出遗漏状态

只走通一次正确邮箱远远不够。把下面六组条件逐个对照设计稿：每一行都要有反馈位置、可以继续的动作和对应画板；还没有画出的状态直接记为缺失，不用默认画面代替。

权限变化、重复成员识别和邀请是否真正发送，需要研发结合接口验证。设计稿此时交付的是“各结果怎样反馈”，不是对接口可靠性的证明。把这些项单独标为实现后验证，能避免静态走查过早给出通过结论。

第三层：把同一组内容放到窄屏和长文本里

状态齐全后，再检查它们是否放得下。继续使用刚才的邀请表单，不要换成短邮箱、短项目名来让画面显得整齐。重点看长邮箱是否有阅读方式、角色说明换行后是否挤压操作区、两行错误提示是否遮挡发送按钮。

• 项目名较长：明确允许换行还是截断；若截断，用户仍应能确认正在操作的项目。
• 错误提示变长：提示区随内容增长，角色选择和操作按钮向下顺延，不叠在文字上。
• 窄屏：按钮可以堆叠，但主次顺序和取消入口保持清楚；弹窗超过屏幕高度时，有办法到达底部操作。
• 键盘焦点：给邮箱、角色和按钮明确的焦点样式；打开、关闭弹窗后的预期位置也要说明。

在 Pixso 中调整画板宽度和内容，检查自动布局、间距与组件状态。设计稿可以说明换行与排列规则；手机键盘弹起、浏览器字体加载和真实焦点顺序，则要到实现页面中检查。若项目已进入多端实现验收，可进一步使用设计稿多端验收方法覆盖断点和输入方式。

第四层：留下别人能重新检查的记录

“邀请失败有问题”不够具体。把出现条件、当前表现和预期结果放在同一条记录里，修改者就不必重新猜测问题。例如，发现失败状态没有保留输入时，可以这样记录：

把记录定位到 Pixso 设计文件的具体画面或评论位置。修改完后重新看同一条件，不只确认新图“更完整”：邮箱和角色是否都保留，错误信息是否仍能读到，重试操作是否有对应状态。需要跟进多条意见时，可按设计评审意见处理流程记录负责人和处理结果。

交付前，将已确认与待实现验证分开

设计走查结束后，可以用两列记录收尾。左列是设计稿已经表达清楚的内容，右列是研发实现后需要实际验证的行为；右列不能因为设计画板齐全就提前打勾。

最终交付的不只是正常页面，还有每条异常路径的反馈、可继续的动作和验证条件。下一次走查使用同一任务和数据，设计师便能清楚判断：缺失状态是否补齐，原问题是否解决，以及修改有没有引入新的遗漏。