常见设计错误与纠正方法
下面不是简单的“注意事项”，而是业务应用开发中反复出现的失败模式。发现症状时，应回到对应分析阶段修正根因。
一、需求阶段
1. 一上来就问需要哪些字段
症状：
- 访谈迅速变成列字段；
- 表单很像旧 Excel；
- 后续不断增加状态、流程和权限补丁。
**根因：**把解决方案当成需求，没有先定义业务目标、角色和场景。
**纠正：**先完成目标卡、现状流程和核心场景，再识别业务对象和字段。
2. 只听提出需求的负责人
症状：
- 页面符合管理者想象；
- 一线用户仍在外部记录；
- 异常流程没人知道怎样处理。
**根因：**没有访谈和观察真实操作者、审批人和执行人员。
**纠正：**建立相关人员地图，至少追踪一笔真实业务。
3. 把“灵活”“智能”“好用”当成需求
症状：
- 每个人对完成标准理解不同；
- 验收时只能争论感觉。
**根因：**没有改写成可观察行为和结果。
**纠正：**写清角色、前提、操作、结果和反例。
4. 第一版什么都想做
症状：
- 蓝图越来越大；
- 核心闭环迟迟不能试用；
- 每个模块都只完成一半。
**根因：**没有明确包含、不包含和优先级。
**纠正：**围绕一个可运行闭环确定必须项，其他进入后续清单。
二、业务分析阶段
5. 直接复制 Excel 结构
症状：
- 一张表混合多个业务对象；
- 同一信息重复；
- 数据无法稳定查询和授权。
**根因：**把现有工具形状当成业务本身。
**纠正：**重新识别对象、主信息、明细、关系和生命周期。
6. 每个名词都拆成独立对象
症状：
- 创建一笔业务要跳很多页面；
- 大量基础资料无人维护；
- 设计复杂度远高于业务价值。
**根因：**为未来想象过度设计。
**纠正：**用独立编号、生命周期、查询和复用需求判断是否真正独立。
7. 状态只是页面操作名称
症状：
- 出现“已点击”“已保存 2”等状态；
- 管理者仍不知道业务到哪一步；
- 责任人无法确定。
**根因：**没有从业务生命周期设计状态。
**纠正：**每个状态必须能说明阶段、责任、允许动作和下一步。
8. 只画正常流程
症状：
- 退回、撤回和作废只能线下处理；
- 人员缺失时流程停住；
- 上线后异常全部找管理员。
**根因：**访谈和设计只关注演示成功。
**纠正：**从输入、业务、人员、时间和权限五类异常逐项补充。
9. 规则没有边界
症状：
- “大额”“及时”“长期”没有数字；
- 刚好 5000 元时不同人期待不同结果。
**根因：**口头制度没有被改写成可执行规则。
**纠正：**明确比较方式、时点、等号归属和边界测试。
三、应用设计阶段
10. 一个角色一张重复表单
症状：
- 申请人、主管、行政各有一张“采购表”；
- 同一业务产生多份记录；
- 状态和金额难以保持一致。
**根因：**把角色视角误当成不同业务对象。
**纠正：**使用同一业务记录，通过状态、权限和视图区分角色。
11. 所有信息都让用户填写
症状：
- 编号、日期、金额和状态都靠人工；
- 同一信息反复输入；
- 错误和不一致频繁。
**根因：**没有区分用户输入、默认、计算和过程信息。
**纠正：**逐字段问“应用是否已经知道或可以得到”。
12. 所有字段都设为必填
症状：
- 草稿无法保存；
- 用户为了继续随便填；
- 不同阶段需要的信息混在一起。
**根因：**没有区分保存草稿和正式提交。
**纠正：**基础完整性在保存时检查，阶段性要求在提交或相应动作时检查。
13. 用自由文本保存人员、状态和分类
症状：
- 同一部门出现多种写法；
- 流程、权限和统计无法可靠使用；
- 人员离职后不知道如何交接。
**根因：**为了快速搭建牺牲业务含义。
**纠正：**使用稳定选择或组织关系；当前不支持时显式记录差距，不静默退化。
14. 自动化像黑盒
症状：
- 值突然变化；
- 用户不知道来自哪里；
- 失败只提示“操作失败”；
- 用户在外部重新计算。
**根因：**只设计了成功动作，没有设计解释和失败。
**纠正：**每条自动化写事件、条件、动作、结果、失败和补救。
15. 把所有业务步骤都画成审批
症状：
- 行政采购也需要点“同意”；
- 待办数量巨大；
- 状态和职责混乱。
**根因：**把业务过程等同于审批流程。
**纠正：**只有正式决策使用审批；执行工作使用责任、状态、任务或动作。
16. 为了方便开放全部权限
症状：
- 开发时所有账号都能工作；
- 上线后发现敏感数据泄露；
- 无法证明某人为什么有权限。
**根因：**没有按角色和数据范围设计。
**纠正：**建立权限矩阵，从最小权限开始，用目标角色做正反例。
17. 一个万能视图展示一切
症状：
- 列太多；
- 用户找不到待处理项；
- 管理和个人数据混在一起。
**根因：**没有从角色任务设计视图。
**纠正：**分别设计个人、运营和管理视图，每个只服务一个主要任务。
18. 通知代替责任
症状：
- 消息发了很多，但事情仍没人处理；
- 无法查询谁在等待；
- 通知丢失后没有入口。
**根因：**把“知道”当成“负责完成”。
**纠正：**必须处理的业务要有状态、责任人和待办；通知只提醒。
四、开发与测试阶段
19. 一次配置全部功能
症状：
- 问题出现时无法定位；
- 基础数据改动引发大量返工；
- 真实用户很晚才参与。
**根因：**没有最小闭环和分阶段验收。
**纠正：**按骨架、数据表单、动作、权限视图、流程、输出逐步开发。
20. 配置界面有了就算完成
症状：
- 保存后重开配置消失或行为不同；
- 运行时并未按配置生效；
- 用户角色看不到。
**根因：**只验证设计界面，没有验证业务运行结果。
**纠正：**执行保存、重开、真实使用、反例和业务结果五步验证。
21. 全程只用管理员账号
症状：
- 开发者认为功能都能用；
- 普通用户上线后看不到入口或权限过大。
**根因：**管理员能力掩盖了真实权限路径。
**纠正：**从开发早期就准备每个主要角色账号。
22. 只测正常成功
症状：
- 演示顺利；
- 一次退回、重复点击或人员缺失就中断。
**根因：**测试来自页面功能，而不是业务规则和异常。
**纠正：**覆盖正常、边界、异常、权限、重复和变更回归。
23. 不重新打开已保存记录
症状：
- 页面上看见了正确金额；
- 再次进入后内容或状态不对。
**根因：**把临时页面变化当成业务事实。
**纠正：**重要场景都执行保存、离开、列表查找、重新打开和核对。
五、发布与运营阶段
24. 版本说明只写“优化”
症状：
- 无法判断哪条规则何时改变；
- 出问题后不知道影响哪些记录；
- 用户不知道新版本有什么不同。
**根因：**把版本当成技术编号，不当成业务决定记录。
**纠正：**说明变更原因、内容、角色、影响、测试和限制。
25. 直接修改正式规则
症状：
- 一句聊天消息就改变审批边界；
- 在途业务出现不同结果；
- 业务负责人事后不认可。
**根因：**缺少变更流程和影响分析。
**纠正：**提出问题、分析影响、确认决定、更新蓝图、测试后发布。
26. 上线后没有应用负责人
症状：
- 问题散落在群聊；
- 角色不维护；
- 规则和文档逐渐失真；
- 用户重新使用旧工具。
**根因：**把上线当成项目结束。
**纠正：**明确业务负责人、应用维护人、反馈入口、检查节奏和迭代流程。
27. 只增加功能，从不简化
症状：
- 表单字段越来越多；
- 入口和规则越来越复杂；
- 很多功能无人使用。
**根因：**迭代只接受新增，不检查实际价值。
**纠正：**定期复盘采用率、绕行和管理效果；删除无价值步骤，收回无用权限，简化体验。