13 · 设计首次访问到完成任务的流程

本页为文字教程；视频与配套媒体仍以实际发布状态为准。

返回课程总览 · 返回模块

本课交付：四条可恢复的任务路径

页面结构已经确定，本课检查用户能否真正从第一次访问走到可使用的初稿。示范任务是：一位创作者要为一个虚构的便携笔记工具写英文商品介绍，已知事实包括适用人群、两项能力与一个限制。你将设计正常生成、事实不足、网络超时和复制失败四条路径。

这里不评判原型是否漂亮，也不把生成一段任意文字视为完成。最终结果要能被核对、编辑并带走；无法完成时，用户应知道发生了什么，资料是否保留，以及下一步可做什么。

跟做一：写出用户进入时知道什么

假设用户从搜索进入工具页，他未必读过首页。开头应说明需要提供哪些事实，会得到什么初稿，以及模型不能自行确认哪些信息。可以提供一个“载入示例”入口，但必须让示例与用户自己的输入清楚区分，避免误把演示结果当成本次生成。

将输入限制放在提交之前。web.dev 的表单可访问性资料强调标签、输入说明与错误识别。Accessibility: forms | web.dev 因此，“产品名称”“主要能力”等字段应有真实标签，必填规则和格式说明能被找到，不能只用浅色占位文字代替。用户开始输入后，占位提示消失不应让他忘记字段用途。

跟做二：把正常路径写成状态表

用状态、用户看到什么、允许操作、服务端事实和退出条件五列记录。例如，idle 时可以编辑；validating 时检查输入；submitted 表示服务端已经接受任务；generating 表示正在处理；ready 表示结果可核对；copied 只表示浏览器确认复制成功。不要用一个 loading 状态遮盖所有过程。

正常路径还要包含人工核对。结果区可以把用户提供的事实列在旁边，提示检查没有添加未经确认的能力。允许修改并复制，这样用户得到的是一个可以接管的成果，而不是必须相信的最终答案。若业务未来增加收费，这个边界同样适用。

跟做三：设计事实不足的恢复

虚构输入若只有“它很好用”，系统不应悄悄补充产品功能。界面可以指出缺少适用人群或具体能力，提供返回输入的入口，并保留已有内容。是否允许生成一个带待确认标记的框架，需要在产品范围中明确，不能一会儿拒绝、一会儿随机编造。

错误提示应说明可修正动作，例如“请补充至少一项已经确认的能力”，而不是只显示 Invalid request。颜色可以辅助，但文字本身也要能表达错误，键盘与屏幕阅读器用户应能找到它。将焦点移到合适位置时，还要避免突然丢失正在编辑的内容。

跟做四：区分网络失败与业务失败

MDN 的 Fetch 说明提醒，HTTP 错误状态并不一定让 fetch 的 Promise 自动失败，需要检查响应状态。Using the Fetch API | MDN 这会影响你的流程设计：收到错误 JSON、没有网络、请求超时和上游拒绝并非同一种情况，用户能否重试也可能不同。

对长任务，可以返回任务编号，让刷新后重新查询状态。若浏览器超时，先确认原任务是否继续运行，不直接创建第二次昂贵调用。原型阶段就应把这类恢复画出来，开发时才不会用“请再试一次”覆盖所有情况。提交按钮禁用只是界面保护，服务端仍需处理重复请求。

跟做五：处理结果之后的失败

复制可能被浏览器权限或环境阻止。此时保留结果，显示可手动选择的文本，并明确复制没有完成，不能一律弹出成功提示。用户重新编辑输入时，也要说明旧结果属于哪一版，避免把先前结果误认为最新输入的答案。

如果结果需要登录保存，可以在用户已经看到价值后清楚说明保存入口，同时解释未保存内容的保留范围。不要在用户投入大量输入后突然隐藏原本承诺的结果，除非这种规则在开始前已经明确且合理。流程中的每一次门槛都影响信任。

加练：演练输入改变后的旧结果

增加一个容易被漏掉的场景：用户提交第一份事实后又开始编辑，旧请求稍后返回。界面必须知道结果属于哪次提交，不能把旧稿显示成最新事实的产物。可以通过任务编号或输入版本关联，但原型也要提前表达“这是先前提交的结果”以及下一步怎样重新生成。

在纸上排出提交、编辑、旧响应、再次提交四个事件，请同伴按顺序指出当前输入与当前结果分别属于哪个版本。如果他需要猜测，就补上清楚状态，不要依靠用户记忆。相同原则也适用于刷新和多标签页。

将此场景加入交付表，并区分可见提示与服务端真实关联。原型文字可以说明设计意图，只有程序正确关联任务后，才算实现；不要用一个固定提示掩盖实际数据混淆。

独立作业：让别人按目标走图

GOV.UK 的可用性测试指南建议围绕明确任务观察参与者，而不把操作答案直接提示给对方。Using moderated usability testing | GOV.UK Service Manual 请一位符合场景的人看原型，只告诉他要完成的目标，不告诉他按哪个按钮。你记录每次停顿、求助、误解和恢复，区分自行完成与得到帮助后完成。

至少为四条路径各写一个验收结果。正常路径要得到可带走的初稿；事实不足要能回到输入；超时要知道是否存在原任务；复制失败要有可行替代动作。提交时附上状态表、恢复文案和观察记录，明确哪些仍是模拟，哪些已经在真实程序中验证。