软件分析与设计笔记 12：前端设计：把流程变成屏幕

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。08 画了活动图，这一篇把流程落到屏幕上 —— 重点是客服的派单台和片区经理的看板。

0 界面不是最后一步才画的

很多团队的做法是：需求写完、开发做完，最后找个人「做一下界面」。

问题在于，画界面的时候一定会发现流程缺东西。在本例里，给客服小林画派单界面时，第一个问题就会是：

「一单要派多久？如果她同时开三个窗口找三张单，会不会派重？」

这个问题活动图里没写。它不是界面问题，是流程问题 —— 但它只有在画界面时才会被逼出来。

所以界面设计不是装饰环节，它是需求的最后一次压力测试。这一篇讲的顺序也是这个意思：先把流程映射到屏幕，再谈好不好看。

1 从流程到屏幕：三步

1.1 把活动图的每一步映射到屏幕或操作

08 篇那个「申请配件」活动图，逐步映射到屏幕是这样：

映射完常常会发现某些步骤没有屏幕可落 —— 那说明流程里漏了一步。本例映射时也发现了一个：「工程师怎么知道配件到货了？」 活动图里没有这一步，但如果没有它，整个「待件挂起」的流程就断在这里。

1.2 标出主路径和分支

用户 80% 的时间走的是哪条路？那条路应该最短。分支（缺料、改约）可以深一层，但必须能到达。

本例里主路径明确：客服派单。她一天要派 80 单，每单背后都是一次完整的「看排期 → 筛技能 → 选人 → 通知」。这条路径必须能在一屏内完成，不跳页。

而分支路径（比如「工程师临时请假，要改派」）一天可能只有两三次，放在二级页面完全可接受。

1.3 先画线框图（wireframe），再做视觉稿（mock-up）

线框图只表达结构和位置关系（哪里是标题、哪里是列表、按钮在不在视线内），不带颜色和字体。这样讨论时才不会跑题到「这个蓝色不好看」——结构没定之前，颜色讨论没有意义。

而且线框图在本例里有个额外的现实价值：王姐和小林都不是设计专业出身，但她们能看懂方框和文字。拿一张带颜色的稿子去给她们看，她们会不好意思说「不好看」；拿线框图去，她们会直接说「这里应该放客户电话，因为我派单时要打给他」。

2 CRUD 任务流：一张万能的检查表

2.1 四种操作与常见遗漏

任何一个业务实体，用户基本都会对它做四件事：新建、查看、修改、删除 —— 也就是 CRUD（Create / Read / Update / Delete）。把这四件事逐一对着屏幕过一遍，能快速发现缺失。

拿本例的「工单」过一遍：

第三个遗漏特别值得说：「改完要回到哪」这件事，行内人从来不觉得是问题，因为开发知道数据存哪了。但用户不知道 —— 她只知道自己刚改的那一单找不到了。

2.2 列表页和详情页的分工

「查看」这一行值得多说一句：列表页和详情页承担的任务不同 —— 列表页负责让人做筛选和比较，详情页负责让人做决定。列表里该出现的是能支持比较的字段（时间、价格、状态），而不是全部字段堆在一起。

本例的待派列表该放哪些字段，可以从「小林要做什么决定」倒推：

地址不该全放在列表里 —— 太占宽度，而且她在派单前不需要知道具体门牌号。地址放详情页。

3 界面必须回答的三个问题

3.1 三个问题

不管什么界面，用户随时会问三件事：

1. 我在哪？ —— 当前位置是否清楚（标题、面包屑、高亮）；
2. 我能去哪？ —— 有哪些可选的下一步；
3. 我怎么回去？ —— 返回路径是否存在。

三个问题在本例的派单台上分别对应：

• 我在哪 —— 顶部显示「片区 A · 待派单（12）」；
• 我能去哪 —— 每一行右侧有「派单」「改约」两个明确按钮，而不是藏在「更多」菜单里；
• 我怎么回去 —— 派单成功后显示「已派给老陈 · 撤销」，「撤销」就是回去的路。

第三条尤其重要：派错人这件事一定会发生，所以「撤销」不是加分项，是必需项。

3.2 寻路（wayfinding）

这套东西有个专门说法叫寻路（wayfinding），借自建筑与城市设计。人在建筑里迷路，和人在界面里迷路，原因是一样的：缺少位置提示和可预期的路径。

本例里最典型的寻路问题出现在工程师的 App：他一天要跑 4–5 单，如果他不知道「现在是第几单、还有几单」，就会一直心里没底。所以 App 首页必须有一行「今日 4 单 · 已完成 1 · 下一单 14:00」，这一行解决的就是寻路。

4 信息架构

4.1 两种起点：top-down 与 bottom-up

信息架构（information architecture） 要解决的是「内容怎么组织」。两种起点：

• top-down（自顶向下） —— 先问「用户要完成什么任务」，再按任务组织内容；
• bottom-up（自底向上） —— 先把已有内容归类，再抽出上层结构。

实际项目通常是两者结合：新系统偏 top-down，改造老系统偏 bottom-up。

本例属于前者偏多 —— 因为是新建系统。但有一块必须 bottom-up：配件分类。仓管小周的台账上已经有几百个配件型号，那套分类方式（按家电类型 / 按品牌 / 按功能）虽然不完美，但硬改成新分类会导致历史数据对不上。所以配件这块沿用旧分类，其他部分按新任务组织。

4.2 组织原则

组织内容时还需要一个组织原则（organizing principle） —— 也就是「按什么分组」。常见的几种：按任务、按主题、按对象、按受众。选哪一种取决于用户脑子里是怎么找东西的。

本例里，四个角色的组织原则其实不一样：

这一条直接否掉了「做一套通用界面给所有人」的想法。四个角色的组织方式不同，硬合并只会让每个人都要在自己不需要的信息里找。

4.3 受控词汇

最后是受控词汇（controlled vocabulary）：全站用统一的词表。同一个东西不能在列表页叫「订单」、在详情页叫「交易」、在报表里叫「单据」—— 用户会以为是三样东西。

本例的受控词表很短，但要一开始定死：

这张表看着琐碎，但它是客服和客户在电话里沟通的基础 —— 如果客服说「您的派工单」，客户会问「什么是派工单」。

5 导航设计（navigation design）：五种类型

5.1 五种类型的分工

5.2 上下文导航为什么最有用

其中上下文导航最容易被忽略，但价值最高 —— 它出现在用户刚好需要的那一刻。

本例里有个很强的例子：客服在派单前，最想知道的往往是「这个客户以前是谁去的」。如果是老客户，派给同一个工程师体验最好，而且那人熟悉这家的情况。

如果这个链接不存在，她要先复制客户名、切到客户页、搜索、找历史单 —— 四步，通常就放弃了。把它做成工单详情里的一行「上次由老陈维修 · 查看」，她一步就能看到。

判断某个上下文导航值不值得做，问一句：不做的话，用户要绕几步？绕四步以上的，基本都值得做。

6 交互设计与视觉设计

6.1 交互设计管的是什么

交互设计（interaction design） 管的是「操作的反馈」：点了有没有反应、要等多久、出错怎么提示。

本例里三个具体的交互决策：

• 派单按钮点击后立刻禁用 —— 防止客服手快连点两次派出两单；
• 查询外部库存时显示「正在查询供应商…」（带进度） —— 因为这个调用可能要 2–3 秒，没有反馈她会以为卡死了；
• 表单校验在失焦时做，不在输入时做 —— 输入时就报错会让人烦躁（「我刚打了个 1 你就说不行」）。

6.2 视觉设计的四条规则

视觉设计（visual design） 管的是呈现。几条最实用的规则：

• 一致性（consistency） —— 同类元素用同样的样式和行为。内部不一致会让用户反复试探；
• 留白（white space） —— 不是浪费空间。没有留白，信息密度过高，反而没人看得下去；
• 字体排印（typography） —— 字号层级要能一眼分辨主次，正文字号不该小于舒适阅读的下限；
• 响应时间（response time） —— 操作反馈的时间直接影响可用性（usability）。超过大约一秒没有反馈，用户就会怀疑是不是没点上。

第四条在本例里有个具体阈值：外部库存查询一旦超过 1 秒，就必须有 loading 状态。这不是「好看」，而是「让她知道系统没死」。

7 两类特殊页面

7.1 启动台

启动台（launching pad） —— 系统的主入口页。它不该是功能的堆积，而应该回答「这个人现在最可能要做哪几件事」，把高频入口放在最显眼处。

本例的四个角色，启动台应该完全不同：

如果四个人看到的是同一个首页，那这个首页一定不是启动台，只是功能入口目录。

7.2 仪表板

仪表板（dashboard） —— 面向管理者的一屏概览。它的难点不是把指标堆上去，而是选出真正需要每天看的那几个。这里会用到数据叙事（data storytelling）的思路：一屏讲清一件事，而不是把二十个图表摆满。

本例的经理看板只放四块，理由都很具体：

27 篇里的那张仪表板成品图，就是照这张表画的。

8 移动端与 Web 端的差别

8.1 移动端的四点特殊性

移动端的特殊性（本例里工程师用 App）：

• 屏幕小 → 一屏只能做一件事，步骤必须分开。他填工单时不希望同时看到别的；
• 网络不稳 → 需要明确加载状态、断网处理、数据不丢。他在客户家里，可能是地下车库没信号 —— 填了一半的工单必须能暂存；
• 有系统级通知 → 可以主动触达，但也带来了打扰的风险。派单推送在晚上十点发出去会被骂；
• 有平台规范（human interface guidelines, HIG）→ 遵循它能让用户不需要重新学习。

第二条在本例里是硬需求：工程师回填工单必须支持离线暂存。这一条在 Web 端通常不需要考虑，但在移动端是「不做就没人用」的功能。

8.2 Web 端的特殊性

Web 端的特殊性（客服与经理用）：

• 窗口尺寸不可控 → 需要响应式设计（responsive web design）；
• 层级深 → 面包屑（bread crumbs）和搜索变得重要；
• 用户来自不同地区 → 需要考虑国际化（internationalization）与本地化。

本例里第二条很实际：客服端三层（分区 → 列表 → 详情），她一天要在这三层之间来回几十次。没有面包屑，她会迷路；没有全局搜索，她只能用浏览器后退。

9 界面设计会反过来改需求

9.1 三类会被暴露出来的问题

回到开头的观点。画界面的过程会稳定地暴露三类问题：

1. 流程缺步骤 —— 某个状态没有出口，用户卡在原地。本例：「工程师怎么知道配件到货了」这一步活动图里没有；
2. 数据不够 —— 界面上需要展示的信息，需求里没定义。本例：列表要显示「是否老客户」，但领域模型里没有这个字段；
3. 规则没说清 —— 「确定删除吗」之后到底删了什么，只有画界面时才会被迫回答。本例：删工单时，配件消耗记录跟不跟着删？

所以界面设计最好在需求定稿之前做一轮，这样它发现的漏洞还能低成本地补回去。

第 3 条在本例里还有个延伸：工单能不能删？讨论到的结论是「不能删，只能作废」—— 因为它是结算依据。这个决定如果在开发完成后才提出来，表结构就要大改。

本节自测

1. 为什么先画线框图再讨论视觉？跳过这一步会出什么问题？
2. 用 CRUD 检查一遍工单，四个操作里哪一个最容易漏掉后续状态？本例的具体表现是什么？
3. 「我在哪 / 我能去哪 / 我怎么回去」三个问题，分别靠界面上的什么元素回答？本例中「撤销」为什么是必需项？
4. 五种导航类型里，哪一种最容易被忽略、又最有用？用什么标准判断它值不值得做？
5. 响应时间为什么属于界面设计问题，而不只是性能问题？
6. 本例中配件分类为什么必须沿用旧分类（bottom-up），而其他部分可以按新任务组织？
7. 移动端的「网络不稳」在本例里变成了哪一条硬需求？

参考答案

1. 因为线框图只表达结构与位置，讨论才不会跑题到颜色。跳过它会让业务方不好意思说「不好看」，却说不出真正的结构问题。本例中画线框图是为了让王姐和小林能直接说「这里该放客户电话」（§1.3）。
2. Update（修改）。本例表现：改完跳回列表后，因为列表按创建时间排序，刚改的那条沉到底，客服找不到自己刚改的单（§2.1）。
3. 我在哪靠标题与计数（「片区 A · 待派单 12」）；我能去哪靠每行的明确按钮；我怎么回去靠返回路径与「撤销」。本例「撤销」是必需项，因为派错人一定会发生（§3.1）。
4. 上下文导航最有价值。判据是 「不做的话用户要绕几步」 —— 绕四步以上的基本都值得做。本例「上次由老陈维修」不做要绕四步（§5.2）。
5. 因为超过一秒没有反馈，用户会怀疑是不是没点上，这直接破坏可用性。本例给外部库存查询定了「超 1 秒必须有 loading」（§6.2）。
6. 因为仓管台账上已有几百个配件型号，硬改成新分类会导致历史数据对不上。这属于改造既有内容的场景，适合 bottom-up（§4.1）。
7. 变成「工程师回填工单必须支持离线暂存」。他在客户家里可能在地下车库没信号，填了一半的工单不能丢（§8.1）。

术语表