设计好填、少错、易懂的表单
本章目标：从用户任务出发设计表单，让正确操作更容易、错误更难发生，并照顾新增、修改和查看等不同使用场景。
1. 表单设计不是美化工作
一张业务表单的质量主要体现在：
- 用户是否知道从哪里开始；
- 信息顺序是否符合工作思路；
- 不必要的输入是否被减少；
- 错误是否能在正确时间被清楚指出；
- 不同角色能否快速找到自己需要的信息；
- 在不同业务状态下，允许的操作是否清楚。
颜色、边框和字体很重要，但它们应该服务于信息层级，而不是代替业务设计。
2. 先定义用户任务
采购申请表单至少服务四种任务：
- 申请人新建并提交；
- 申请人修改退回内容；
- 审批人查看并判断；
- 行政采购员查看批准内容并登记采购结果。
同一张表单中的信息，可以在不同任务下拥有不同重要程度和可编辑性。
新建
重点是少填、快填、避免遗漏。
修改
重点是看见原内容、退回原因和允许修改的部分。
查看
重点是快速理解业务事实和进度，不应出现容易误以为可编辑的控件。
详细状态行为可参考填报态行为。
3. 按业务思路分组
采购表单可以分为：
基本信息
申请编号、申请日期、申请人、部门。
申请说明
用途、紧急程度、期望日期。
采购明细
物品、规格、数量、预计单价、行金额。
金额汇总
申请总额和必要说明。
处理信息
当前状态、审批结果、采购结果。
分组应让用户自然地从“为什么申请”走到“申请什么”，再看到“总共多少”和“后续怎样处理”。
4. 决定信息顺序
推荐顺序：
- 用户作决定所需的背景；
- 用户必须填写的核心内容；
- 根据核心内容自动得到的结果；
- 低频补充信息；
- 过程和历史信息。
不要因为字段在数据字典里按字母排序，就按同样顺序摆放。
审批人最关心的用途、金额和明细应该在明显位置；内部维护备注不应占据表单顶部。
5. 减少不必要输入
每个字段问四个问题：
- 系统是否已经知道？
- 能否从其他选择自动带出？
- 能否通过计算得到？
- 是否真的在后续规则、流程或查询中使用？
采购案例中：
- 申请编号自动生成；
- 申请日期默认当天；
- 行金额自动计算；
- 总金额自动汇总；
- 当前状态随过程变化；
- 申请人无需手工填写自己的姓名。
减少输入不仅提高效率，也减少不一致。
6. 选择合适的填写方式
| 业务特点 | 适合方式 |
|---|---|
| 只有少量固定选项 | 单选或选择列表 |
| 可以选择多个值 | 多选 |
| 是/否且没有第三种含义 | 开关或勾选 |
| 候选项有层级 | 级联选择 |
| 需要精确日期 | 日期选择 |
| 需要长篇说明 | 长文本 |
| 多行重复结构 | 明细表 |
具体控件配置参见填写控件配置。
不要把一个有固定选项的字段设计成自由文本，再依赖用户记住标准写法。
7. 默认值要帮助用户，而不是替用户作决定
好的默认值：
- 申请日期默认当天；
- 常见紧急程度默认“普通”；
- 数量可以根据业务决定是否默认 1。
危险默认值：
- 审批意见默认“同意”；
- 实际采购金额默认等于预计金额；
- 完成日期在新建时默认当天；
- 申请类别默认一个并不适合大多数人的值。
默认值会被部分用户直接接受，因此必须代表安全、常见且可见的选择。
8. 校验要放在正确时机
输入时即时提示
适合简单格式和范围：
- 数量不能为负数；
- 日期格式不正确；
- 文本超过限制。
保存草稿时
只检查数据是否能够安全保存，不必强制所有正式信息完整。
提交时
检查进入下一业务阶段所需的完整规则：
- 至少有一行明细；
- 每行物品、数量和预计单价完整；
- 高金额申请已填写详细用途；
- 总金额已经正确得到。
如果所有正式校验都阻止草稿保存，用户可能因为暂时缺一项信息而丢失已经填写的内容。
9. 写用户看得懂的错误提示
差的提示：
保存失败。
好的提示：
第 2 行“数量”必须大于 0，请修改后重新提交。
好的提示包含：
- 哪里有问题；
- 为什么不允许；
- 用户下一步怎么做；
- 如果用户无法处理，应联系谁。
对跨字段规则：
期望采购日期不能早于申请日期。
对流程前提：
当前账号没有可用的直属主管，暂时无法提交。请联系应用管理员检查组织信息。
10. 设计明细表体验
多行明细需要特别考虑：
- 新增行入口是否明显；
- 最少和最多允许多少行；
- 是否允许复制上一行；
- 行金额是否实时得到；
- 删除行是否需要确认；
- 重复物品如何处理；
- 空白行在提交时怎样提示；
- 总金额是否始终可见。
明细很多时，应考虑筛选、排序、批量填写和导入需求，但不要在第一版没有真实需要时过早增加复杂操作。
11. 用视觉层级表达业务重点
- 标题和分组名称清楚；
- 核心字段靠前；
- 必填标识一致；
- 自动计算结果与手工输入有所区分；
- 状态和异常信息明显但不过度抢眼；
- 危险操作与普通操作分开；
- 同类字段保持对齐；
- 不用大量颜色表达本应由文字说明的含义。
12. 设计操作按钮
按钮名称应说明业务结果：
- “保存草稿”；
- “提交审批”；
- “撤回申请”；
- “登记采购完成”。
避免：
- “确定”；
- “处理”；
- “执行”；
- 多个含义相近的“保存”按钮。
点击后要有明确反馈：
- 是否成功；
- 当前状态是什么；
- 下一步由谁处理；
- 失败时如何修正；
- 是否可以重复点击。
13. 查看和审批体验
审批人需要的是作决定所需的信息，不是所有设计字段：
- 申请人和用途；
- 金额和明细；
- 紧急程度；
- 必要附件；
- 历史意见；
- 当前需要作出的决定。
行政采购员需要：
- 已批准的最终申请内容；
- 采购所需规格和数量；
- 可登记的采购结果；
- 缺货、作废等异常入口。
通过分组、只读和状态控制，让不同角色知道哪些是事实、哪些是自己需要补充的内容。
14. 考虑输出和不同设备
如果用户需要打印：
- 屏幕布局不一定等于打印布局；
- 明细跨页时表头如何重复；
- 是否需要签字、编号、水印或多联；
- 哪些内部字段不应打印。
如果大量用户在小屏设备使用：
- 避免必须横向浏览的超宽表单；
- 让主要操作容易找到；
- 控制一次展示的信息量；
- 用实际设备验证，不要只缩小浏览器窗口想象。
15. 用纸面原型先验证
在正式配置前，可以画简单草图：
text
采购申请
┌ 基本信息 ─────────────────┐
│ 编号 [自动] 日期 [今天] 状态 [草稿] │
└─────────────────────────┘
┌ 申请说明 ─────────────────┐
│ 用途 [ ] │
│ 紧急程度 [普通▼] │
└─────────────────────────┘
┌ 采购明细 ─────────────────┐
│ 物品 | 规格 | 数量 | 单价 | 金额 │
└─────────────────────────┘
总额：¥____
[保存草稿] [提交审批]让申请人、主管和行政分别指出：
- 找不到什么；
- 哪些内容看不懂；
- 哪些内容不应该由自己填写；
- 作决定时还缺什么。
16. 常见错误
- 按数据字段顺序排版；
- 一打开就展示所有低频信息；
- 草稿保存也要求全部正式信息；
- 默认值替用户作出高风险决定；
- 错误提示只有“操作失败”；
- 自动计算字段看起来仍可随意修改；
- 同一个按钮名称在不同状态代表不同结果；
- 只为申请人设计，没有考虑审批和执行角色。
17. 本章完成标准
- [ ] 表单围绕明确用户任务设计；
- [ ] 新增、修改、查看和处理场景都已考虑；
- [ ] 信息按业务思路分组和排序；
- [ ] 可自动得到的信息不再要求重复填写；
- [ ] 草稿校验与提交校验已区分；
- [ ] 错误提示能说明位置、原因和修正方法；
- [ ] 明细新增、删除、计算和空行规则清楚；
- [ ] 纸面原型已由至少两类真实角色评审。
下一步
表单让用户输入和查看，动作让重复的业务规则自动发生。下一章学习设计计算、校验、联动与自动动作。