# 应用设计清单

这份清单是动手前和提交前的检查工具，不是必须照抄的页面模板。先阅读 [UI 设计原则](/doc/styles/design-principles)，再根据真实任务选择结构。应用可以使用原生 DOM 和包内 CSS 做出不同的界面，但每个差异都应有产品理由。

## 页面结构

- [ ] 页面只有一个明确的主目的和一个主要操作；次要操作不会抢走焦点。（注意力）
- [ ] 标题、说明、内容和操作按照真实依赖关系分组，相关内容彼此靠近。（空间）
- [ ] 列表、详情和编辑属于不同任务时，使用清楚的页面位置、抽屉或弹窗表达层级；返回路径始终可见。（状态）
- [ ] 列表项只显示做决定所需的信息；完整内容在详情中阅读，不把所有字段挤在一行。（经验）

错误写法：在同一张卡片里同时放总览、筛选、编辑表单、批量删除和帮助说明。

正确写法：总览先显示一个焦点；筛选就地放在列表上方；编辑作为独立任务打开；低频帮助放在不打断流程的位置。

## 状态

| 状态 | 对应原则 | 必须说明 | 正例 / 反例 |
| --- | --- | --- | --- |
| 空 | 空状态属于结构的一部分（空间） | 当前范围为什么没有内容 | 正例：「还没有账目，添加第一笔」；反例：只留一块空白 |
| 加载 | 呈现必须跟随系统状态（时间） | 正在读取什么 | 正例：「正在读取本周记录」；反例：加载时显示成空列表 |
| 错误 | 不确定结果不能伪装成成功（时间） | 哪一步没有完成、是否可能已经保存 | 正例：「暂时无法读取，请重试」；反例：「出错了」 |
| 成功 | 变化要保留用户当前位置（时间） | 刚才完成了什么 | 正例：「账目已经保存」并留在当前列表；反例：跳回首页且没有提示 |
| 禁用 | 可见差异必须有真实原因（经验） | 为什么暂时不能操作 | 正例：说明「需要先选择日期」；反例：只降低透明度 |

状态示例必须同时满足四问：错误或加载时保留已经展示的内容和当前筛选，成功后保留当前位置，空状态提供下一步；这样状态变化不会让用户失去上下文。（空间、时间、注意力）

## 移动端

- [ ] 主要内容在窄屏仍然按照同一层级排列，不要求横向滚动才能完成主要任务。（空间）
- [ ] 触控目标清晰可用；输入文字至少 16px；底部操作不会被键盘或安全区遮挡。（经验）
- [ ] 次要列可以改为详情页、底部抽屉或菜单，但不删除 Web 端已有能力。（状态）
- [ ] 横向数据确实需要比较时才使用横向滚动，并且给出可见的列标题和当前位置。（注意力）

## 中文文案

- [ ] 文案描述用户正在做的具体事情，例如「正在读取记录」「已经保存」。（经验）
- [ ] 按钮使用动作名称，例如「添加记录」「保存修改」「撤销删除」，不使用「提交」「处理」等没有对象的词。（注意力）
- [ ] 不向普通用户展示 `platform`、Bridge、API、revision、静态检查等内部词语。（经验）
- [ ] 进度文案不会把尚未完成的操作说成成功；错误文案说明下一步。（状态）

## 可访问性

- [ ] 每个输入都有可见标签或等价的 `aria-label`，placeholder 不是唯一说明。（经验）
- [ ] 可操作元素使用 button、label 等熟悉语义，并且键盘可以到达和触发。（经验）
- [ ] 状态变化使用 `role="status"` 或清楚的文本更新，不只依赖颜色、动画或图标。（状态）
- [ ] 颜色和背景不是唯一的差异表达；减少动态效果时仍然可以完成任务。（空间）

正例：按钮写「保存修改」、输入有「金额」标签、完成状态同时显示文字；反例：按钮只写「提交」、输入只写 placeholder、只用颜色区分已完成和未完成。（经验、时间）

## 提交前四问

1. 看起来的关系，和实际的关系一致吗？
2. 注意力的分配，和重要性一致吗？
3. 用户此刻是否清楚自己在哪、能做什么、发生了什么、怎么回去？
4. 一个用过同类产品的人，能不能不经学习就看懂、会用？

把每一问写成 0–2 分：0 分表示明显违背，1 分表示部分满足，2 分表示清楚满足。低于 2 分时，先修改界面和文案，再提交源码。