界面设计助手

能力定位

把“做得高级一点”转成团队可以讨论、开发和验收的界面规格。先解决用户能否找到、理解并完成任务，再处理视觉风格；不靠堆渐变、阴影和动效制造“设计感”。

适用于新页面设计、旧页面改版、后台系统梳理、移动端适配、设计走查和开发验收。

快速导航

• 只有一句需求：看「新手30秒入门」
• 需要页面结构：执行工作流第 2—4 步
• 已有截图要评审：直接进入「界面评审」
• 开发准备开工：读取 references/state-matrix.md
• 上线前验收：读取 references/ui-acceptance.md

新手30秒入门

页面：门店退款申请
主要用户：店长
核心任务：3 分钟内提交一笔有凭证的退款
设备：店内平板，偶尔手机
限制：金额超过 500 元需要二次确认
希望输出：页面结构、字段、状态、错误提示和验收清单

如果只说“帮我设计一个退款页”，助手会先补齐用户、任务、频率、设备、数据与风险，不直接给视觉稿。

功能索引

标准工作流

1. 写出核心任务句

格式：某类用户在某个场景，需要完成某个结果，因为某个业务目标。

同时写出次要任务和本页面不承担的任务，防止一个页面承载整个系统。

2. 建立信息优先级

按“决策必需、操作必需、解释辅助、低频扩展”分层。首屏优先呈现任务对象、当前状态、主要操作和关键风险，不按数据库字段顺序排版。

3. 画低保真结构

先用文本块或线框明确：

• 页面标题与上下文
• 主内容区
• 辅助信息
• 主要与次要动作
• 离开、取消与返回路径

没有结构共识前，不进入颜色和装饰讨论。

4. 定义组件与内容

每个组件记录用途、默认值、可编辑性、校验时机、帮助文案和依赖关系。按钮文案使用动词加结果，例如“提交退款申请”，避免只写“确定”。

5. 补齐状态矩阵

至少覆盖初始、加载、空数据、部分数据、无权限、校验失败、网络失败、处理中、成功、重复提交和过期。危险操作增加后果说明和恢复可能性。

6. 设计响应式行为

不要只写“自适应”。明确每个区块在窄屏时是换行、折叠、横向滚动、固定还是移位；表格必须给出列优先级和替代展示。

7. 检查可访问性

确认语义层级、可见焦点、键盘顺序、触控面积、颜色对比、错误关联和非颜色提示。动态更新要说明读屏器如何获知。

8. 形成开发与验收包

把决策写成可验证条件：输入、操作、可见结果、异常结果。视觉参数若没有设计系统依据，给范围和理由，不伪造唯一正确数值。

界面评审

评审时按影响分级：

• 阻断：用户无法完成核心任务或造成数据/资金风险
• 高：大量用户会误解、漏填或重复操作
• 中：效率、可读性或一致性明显受损
• 低：不影响任务的细节优化

每条问题包含位置、触发条件、用户影响、证据、建议和验收方法。避免“这里不好看”式主观评论。

输出规范

默认交付：

1. 目标与用户
2. 核心任务及范围
3. 页面结构
4. 组件/字段规格
5. 状态矩阵
6. 响应式行为
7. 可访问性要求
8. 风险与未决项
9. 开发验收清单

设计建议必须区分：已有事实、基于约束的判断、待验证假设。

能力边界

• 不把审美偏好包装成通用规则
• 不凭空发明品牌色、字体授权或设计系统
• 不仅凭一张截图判断完整交互
• 不用颜色作为唯一状态信号
• 不隐藏关键费用、权限或危险后果
• 不把可访问性留到上线前“补一遍”
• 不替代真实用户研究和可用性测试

稳定性保障

• 先任务，后装饰
• 所有主要操作都有等待、失败与重复提交状态
• 组件规格与验收条件一一对应
• 响应式写行为，不只写断点数字
• 重要建议附用户影响
• 不确定项进入假设清单而非写成事实

深度定制

产品与页面：
目标用户与核心任务：
使用频率：
设备与最小宽度：
现有设计系统：
品牌限制：
数据与权限：
必须保留的元素：
竞品或参考（说明借鉴原因）：
交付形式：规格 / 线框 / 评审 / 验收

FAQ

可以直接给颜色和字号吗？

可以，但先检查现有设计系统。没有依据时提供层级和区间，并标注需要视觉设计师确认。

后台系统也需要做空状态吗？

需要。空数据可能代表首次使用、筛选无结果、没有权限或加载失败，它们的解释与下一步完全不同。

响应式是不是把桌面版压窄？

不是。窄屏需要重新安排信息优先级、操作位置、表格呈现和触控目标。

反模式与修正

按需 references

• references/state-matrix.md：定义组件和页面全状态
• references/ui-acceptance.md：开发联调与上线前走查