软件项目开发全流程 · 第 8 课 · 原型与 UI/UX 设计：先画出来，再写代码
1、为什么"先画再写"
第 7 课我们得到了文字规格。但文字有天然的歧义：你写"任务列表"，有人脑子里是表格，有人想的是卡片流。
改一行原型，成本是 5 分钟；改一个已上线的界面，成本是数天。 原型就是最便宜的试错工具：让用户在还没写代码的时候就说"这个不对"。
本课回答四个问题：
- 需求怎么变成界面与流程？
- 低保真、高保真原型分别用在什么时候？
- 怎么判断"好不好用"，而不是"我觉得挺好看"？
- 设计怎么落到可实现的组件上，为后面的架构设计铺路？
2、从需求到界面的桥：信息架构与用户流程
写界面之前，先定两样东西：
① 信息架构（IA）：内容怎么分层归类。
- 有多少个一级入口？（建议 ≤ 5，人的短期记忆就那么点）
- 哪些是高频操作，必须一眼可见？
- 哪些是低频配置，可以折进"设置"？
② 用户流程（User Flow）：用户完成一件事要走几步。
打开 App → 任务列表 → 点"新建" → 填标题/指派 → 保存 → 回到列表（看到新任务）画流程的价值在于暴露多余步骤和断点：如果"创建任务"要点 4 次才到，就该合并。
一个检验标准：画出流程后，问"新手第一次能独立走通吗？" 走不通，就是缺引导或缺默认值。
3、原型的三个保真度
| 层级 | 工具/形式 | 回答的问题 | 什么时候用 |
|---|---|---|---|
| 低保真 | 纸笔草图、线框图 | 结构对不对、流程顺不顺 | 需求刚明确，还在探索方案 |
| 中保真 | 可点击原型（Figma/墨刀） | 操作路径、信息层级 | 方案基本确定，要给干系人演示 |
| 高保真 | 视觉稿 + 真实数据 | 视觉规范、状态细节 | 开发前定稿，前后端对齐 |
关键原则：保真度要匹配决策阶段。
在"到底要不要做这个功能"还没定的时候，别去做像素级视觉稿——那是巨大的浪费。先用低保真快速否定错误的方案。
低保真也有技巧：
- 用方块 + 文字代替图标（"▢ 新建"），避免大家纠结颜色。
- 每个屏只放 1 个主要动作，让主次自然浮现。
- 明确画出空状态、加载态、错误态——这三个常被漏掉，却最影响体验。
4、可用性检查：别问"好不好看"
"你觉得这个设计怎么样？" → 用户只会礼貌地说"挺好的"。要测的是任务完成能力，不是审美偏好。
轻量可用性测试（5 人法）：
- 找 5 个目标用户类型的人（不用 50 个，5 个就能发现 80% 的严重问题）。
- 给任务而不是给界面："请新建一个任务并指派给小李。"
- 闭嘴观察：他卡在哪？犹豫在哪？哪里点错了？
- 记录三条：任务是否完成、耗时、卡点原话。
Nielsen 十大启发式（挑最常用的六条）：
| 原则 | 说明 | 反例 |
|---|---|---|
| 系统状态可见 | 操作要有反馈 | 点了保存没任何提示，用户狂点 |
| 贴近现实语言 | 用用户的话，别用内部术语 | "实体关联失败" |
| 用户可控 | 能撤销、能返回 | 误删后无法恢复 |
| 一致性与标准 | 同类操作位置一致 | 有的页面右上角保存，有的左下角 |
| 错误预防 | 提前拦住错误 | 删除前二次确认 |
| 帮助用户识别而非回忆 | 选项可见，少靠记忆 | 要用户记住 ID 才能查询 |
错误提示的三要素：说清发生了什么、为什么、怎么办。只写"操作失败"等于没提示。
5、设计走查与评审（敏捷中的原型）
设计走查（Design Review） 的参与人：设计、开发、测试、产品各 1 人。走查不是"看着好不好看"，而是逐项核对：
- 每个界面对应哪条需求/验收标准？（对不上就是镀金或漏做）
- 异常态和权限差异画了吗？（管理员和普通成员看到的一样吗？）
- 文案是否明确、无歧义？
敏捷里的一个实用做法：把原型当作验收标准的锚点。故事卡上写"点击'新建'弹出表单，字段与原型 P-03 一致"——测试和开发就不用在"到底长什么样"上扯皮。
迭代式设计：不必一次画完所有页面。每个迭代只细化这个迭代要做的故事对应的界面，其余保持粗线条。这样设计不会超前于认知，也不会浪费。
6、设计与实现的接口：设计系统与组件化
界面能画出来，不代表能一致地实现出来。解决办法是设计系统（Design System）：
- 设计令牌（Design Token）：颜色、字号、间距、圆角的统一变量（如
--color-primary）。 - 组件库：按钮、输入框、弹窗、表格的定义与状态（默认/悬停/禁用/错误）。
- 使用规范：什么场景用主按钮、什么场景用文字按钮。
好处有三：
- 一致性：不会出现 3 种蓝色和 4 种圆角。
- 效率：开发和设计都基于同一套积木，沟通成本大降。
- 可维护：改一次令牌，全局生效。
组件化不止是"好看"——它直接决定了第 9 课的架构分层：组件 → 页面 → 业务模块，边界要提前想清楚。
7、常见的四个坑
- 跳过低保真直上高保真：方案没定就做精修，一改全废。
- 只画正常态：空态、加载、错误、无权限全部漏掉，开发时靠猜。
- 拿"老板喜欢"当可用性结论：决策者不是用户。
- 设计稿与组件库脱节：设计自由发挥，开发被迫硬编码，样式从此失控。
8、动手实验 🎯
任务：为「团队任务清单」画出三张关键页面。
- 列出产品的 5 个一级入口，说明每个入口服务的高频任务是什么。
- 画一条核心用户流程（创建 → 指派 → 完成），标注每一步的输入与反馈。
用纸笔或画图工具做 3 张低保真线框图：任务列表、新建任务、任务详情。
- 每张必须画出 空状态 和 错误状态（如标题为空）。
- 找 3 个人做一次 5 分钟可用性测试：只给任务、不给说明，记录他卡住的位置。
- 根据测试结果改一版，并写下"改了哪 3 处、为什么"。
- 定义一套最小设计令牌（主色、字号 3 档、间距 3 档），并列出 5 个基础组件及其状态。
做完这步，你手里就有一份"用户已经试过、异常态已覆盖、可直接落到组件"的界面方案——下一课我们把它变成能支撑这些界面的系统架构。
9、今天你带走的三句话
- 改原型 5 分钟，改线上界面 5 天——保真度要匹配决策阶段，先粗后细。
- 可用性要用任务测，不要问审美；5 个人就能挖出大部分严重问题。
- 设计系统 = 设计令牌 + 组件 + 规范，它同时解决一致性和实现效率。
下一课进入系统架构设计——把这些界面和需求，组织成模块边界清晰、能长期演进的系统骨架。