很多团队把“用户流程已经画完”误认为“可以开始做UI”。真正的断点往往发生在两者之间：流程图描述了用户要经过哪些节点，却没有说明每个节点要看见什么、能做什么、失败后怎么办。UI设计如果直接从页面外观开始，后面一处流程调整就会牵动整套视觉稿。
最稳妥的顺序是：先把用户任务拆成可验证的流程节点，再把每个节点翻译成页面、状态和组件，最后用视觉规则统一界面。下面用“预约上门维修”这一条真实任务贯穿全篇，给出从用户流程进入UI设计的5步做法。
先分清三张图：流程图、线框图和UI稿
用户流程、线框图和UI设计稿是连续产物，但它们回答的问题不同。把三者混在一起，评审就会从“用户能不能完成任务”滑向“按钮颜色好不好看”。
| 产物 | 回答的问题 | 最小可验证结果 |
|---|---|---|
| 用户流程图 | 用户从哪里来，要完成什么，遇到分支如何继续？ | 入口、主路径、返回路径和异常分支可走通 |
| 线框图/低保真原型 | 每个节点需要哪些信息和操作？ | 页面结构、信息层级和关键跳转可点击验证 |
| UI设计稿 | 信息如何被看懂，组件如何保持一致并交付实现？ | 视觉规则、组件状态、响应式和研发说明齐全 |
因此，UI设计的起点不是“打开设计软件”，而是拿到一条边界清楚、能够被复述的用户任务。没有任务，颜色和布局就没有判断标准。
第1步：把用户流程改写成一条可验收的任务
先把流程图上的名词改写成用户动作。以预约上门维修为例，不要只写“维修服务”，而要写成“用户在30分钟内完成故障描述、选择时段并提交预约，提交失败时仍能保留已填信息”。这句话同时包含角色、场景、目标和成功条件。
建议在流程图旁补齐四类信息：
- 入口：用户从首页、通知、搜索结果还是订单列表进入。
- 动作：用户需要选择、输入、上传、确认还是等待。
- 结果：成功后看到什么，系统保存什么，下一步去哪里。
- 约束：权限、网络、设备、数据来源和业务规则有哪些。
如果一句话无法说清成功条件，先不要画高保真页面。你需要的是补需求证据，而不是增加视觉细节。
第2步：把流程节点翻译成页面与状态
流程节点不是页面清单。一个节点可能只是一个弹窗、一个空状态，或者同一页面中的状态切换。翻译时要问：用户在这里需要做什么决定？系统需要给出什么反馈？
可以用下面的映射表逐节点检查：
| 流程节点 | 用户问题 | 页面或状态 | 关键组件 | 验证证据 |
|---|---|---|---|---|
| 选择服务 | 我能解决什么问题？ | 服务列表页 | 分类、卡片、搜索 | 用户能找到正确服务 |
| 描述故障 | 系统需要哪些信息？ | 表单默认态 | 输入框、上传、字数提示 | 必填项和示例清楚 |
| 选择时段 | 哪个时间可预约？ | 日期与时段选择态 | 日期控件、禁用项、库存提示 | 不可选原因可理解 |
| 提交预约 | 我提交成功了吗？ | 提交中、成功、失败 | 按钮、进度、结果反馈 | 成功有凭证，失败可恢复 |
这一步的独特价值在于把“流程分支”变成“界面状态”。状态没有被写出来，UI稿再漂亮也无法指导开发。
第3步：先用低保真原型跑通路径
低保真不是粗糙版UI，而是专门用来验证结构的试验场。只放真实的页面标题、按钮文案和关键字段，暂时拿掉颜色、阴影和装饰图片。评审时让参与者按任务操作，不要由设计师一边讲解一边替用户完成。
- 先搭入口、主路径和完成页，确认用户知道从哪里开始、完成后到哪里结束。
- 再补返回、取消、重复提交和无数据等高风险分支。
- 用真实长度的文案和一组接近真实的数据，观察是否溢出、遮挡或改变层级。
- 把评审意见按“流程问题、信息问题、状态问题、视觉问题”分类，先修前两类。
用墨刀制作时，可以在白板中整理流程和信息架构，再进入原型画布连接页面、状态和交互。这样团队评审的是同一条可点击路径，而不是散落的截图。需要更完整的流程梳理方法，可参考AI思维导图梳理用户流程的实战指南。
第4步：把验证过的结构提升为UI规则
只有当主路径和高风险分支已经走通，才进入视觉设计。先定义规则，再做页面，能避免每张图都重新做决定。建议先建立四组最小规则：
- 层级规则：页面标题、任务说明、主要操作和辅助信息分别用什么字号与间距。
- 语义颜色：品牌色只承担主要行动，成功、警告、错误和禁用状态有明确含义。
- 组件规则：按钮、输入框、卡片、弹窗和导航写清默认、悬停、按下、禁用、加载和错误状态。
- 布局规则：确定栅格、间距单位、内容最大宽度及不同屏幕下的折行和堆叠方式。
从一个“基准页面”开始最容易落地。例如先完成预约表单页：把字段、错误提示、提交中和成功反馈做全，再将同一套输入框、按钮和提示复用到其他页面。组件复用的意义不是少画几个矩形，而是让同一类动作始终有同一种反馈。
第5步：用状态和交付反向检查UI是否成立
UI稿交付前，沿着用户流程反向走一遍。每一个流程节点都应该能在设计稿中找到对应页面或状态，每一个重要动作都应该有结果反馈。
- 主路径：用户是否能在不听讲解的情况下完成任务？
- 异常路径：网络中断、时段不可用、权限不足、输入错误时，下一步是否明确？
- 内容路径：真实长度的标题、价格、日期和错误文案是否破坏布局？
- 协作路径：研发能否从标注、组件和状态说明理解行为，不必猜测？
- 回收路径：用户误操作后能否撤销、返回或重新编辑，而不是被卡在死路？
交付包至少包含高保真页面、组件与状态、响应式说明、交互触发条件、资源和待确认问题。把“待确认”单独列出来，比用一张看似完整的视觉稿掩盖未知更可靠。
一张检查表：什么时候可以从流程进入UI
| 检查层 | 放行条件 | 未通过时的动作 |
|---|---|---|
| 任务 | 角色、场景、目标和成功条件能被一句话复述 | 回到需求和研究材料，缩小任务范围 |
| 流程 | 入口、主路径、返回和异常分支有明确负责人 | 补流程节点与决策条件 |
| 结构 | 页面清单与节点映射，关键状态可点击体验 | 先修线框，不进入视觉细节 |
| 规则 | 组件、颜色语义、内容和响应式约束已定义 | 建立最小设计规则和基准页面 |
| 交付 | 研发能读懂行为、状态、资源与待确认项 | 补标注、交互说明和验收问题 |
把预约表单走一遍：一次小型可用性走查
拿已经连接好的低保真原型做一次15分钟走查，参与者只拿到任务，不先看设计说明：“请为厨房水槽漏水预约周六上午的上门维修，如果没有合适时段，请告诉我下一步怎么做。”观察重点不是完成速度，而是用户是否在关键节点做出了预期判断。
- 用户在服务列表停顿，说明分类或搜索词不贴近真实表达；先改入口信息，不急着改颜色。
- 用户填写故障描述却找不到上传入口，说明辅助动作被主任务遮住；可以调整字段分组或补充示例。
- 用户点击不可选时段后反复尝试，说明禁用状态缺少原因；需要在控件旁给出恢复路径。
- 用户提交后回到列表页，无法确认是否成功，说明结果反馈没有形成闭环；应提供预约编号、状态和查看入口。
把每次停顿记录成“观察—推断—改动—复测”四列，下一轮评审就能判断改动是否真正解决问题。这比收集“我觉得更好看”更接近可执行的UI决策。
流程变化时，先判断改哪一层
项目进入迭代后，不是每个需求都要重做整套UI。可以按影响范围分层处理：
- 任务变化：目标用户、成功条件或权限变化，回到流程层重新确认入口和分支。
- 信息变化：字段、文案或数据规则变化，优先更新页面结构、内容和状态。
- 表现变化：品牌色、字体或间距变化，在组件和视觉规则层处理，避免逐页手改。
- 实现变化：接口、设备或性能约束变化，补充响应式与交互说明，并同步研发评审。
这套分层能帮助团队找到最小改动范围：先改产生变化的那一层，再检查它向下游的影响，不要把局部问题扩大成全量返工。
常见误区：为什么流程图画完，UI还是会返工
把每个流程节点都画成一张页面
节点是用户或系统发生的一次变化，不一定需要新页面。把状态变化、弹窗和页面跳转混成同一种节点，会导致页面数量膨胀，也会让真正的关键状态被忽略。
用占位文案替代真实内容
“标题文字”不会暴露长标题换行，“按钮”不会暴露多语言和错误提示的长度。至少选一组接近真实的内容跑一次，再决定栅格和组件尺寸。
把视觉评审当作流程评审
视觉稿可以帮助发现层级和可读性问题，但不能替代任务测试。流程是否成立，要让目标用户或熟悉业务的人按步骤操作，并记录停顿、误解和恢复动作。
让AI直接从一句话生成最终UI
AI适合快速产生页面候选和文案方向，但它不了解你的权限、库存、数据和异常规则。更稳妥的用法是先提供已经确认的任务与流程，让AI生成可编辑初稿，再由设计师逐状态复核，最后由产品和研发确认边界。
把流程变成界面，核心是减少“猜”
从用户流程进入UI设计，不是把流程图换一种颜色，而是完成一次信息翻译：把用户动作翻译成页面，把业务规则翻译成状态，把团队共识翻译成组件和交付说明。顺序一旦稳定，设计师可以把时间用在真正有价值的判断上，产品和研发也能在更早阶段发现问题。
墨刀适合把这条链路放在同一工作空间里：用白板整理用户流程，用原型连接页面和交互，再用设计能力建立组件与视觉规则，最后通过分享链接进行评审和交付。工具不会替团队做决定，但能让决定、证据和下一步动作留在同一个上下文中。
进入墨刀设计，从一条真实任务开始，把流程走通，再把界面做清楚。
