15 · 制作原型并获取用户反馈
围绕核心任务制作可测试原型，区分固定演示与真实生成能力，以英文商品介绍工具设计招募说明、任务脚本、观察表和问题分级。结合 GOV.UK 用户研究、表单可访问性和原作者创业建议开展不诱导的试用，记录独立完成、得到帮助和失败恢复，最终提交可追溯的改版决定而非只收集审美好评。
发布时间：2026-10-31
本页为文字教程；视频与配套媒体仍以实际发布状态为准。
本课交付：原型链接、观察记录与改版决定
本课把前几课的结构、流程和文案连接成一个能被观察的原型。目标不是证明大家喜欢你的设计，而是找出用户是否理解任务、能否准备输入、能否看懂结果并完成复制。示范站仍使用虚构商品资料，不能把固定输出包装成真实模型分析。
原型可以低保真，也可以是使用测试替身的网页。选择能够回答本轮问题的最低复杂度：如果只测入口与理解，就不需要真实模型；如果要判断结果质量，则必须说明原型无法回答，并另行安排真实处理测试。
跟做一：写清楚本轮要研究什么
将研究问题缩小为几项可观察行为，例如用户是否知道需要提供事实，是否理解初稿需要核对，遇到输入不足能否自己恢复。不要同时把视觉审美、付费、长期留存和模型优劣都塞进一轮原型测试，结果会难以解释。
GOV.UK 的主持式可用性测试指南建议围绕明确任务观察真实或可能的用户。Using moderated usability testing | GOV.UK Service Manual 你可以按这个原则准备一段中性任务：“你正在为一个产品发布英文介绍，请用现有资料完成一份你愿意继续编辑的初稿。”不要在任务里直接说去哪个页面、点击哪个按钮，否则无法检查入口是否清楚。
跟做二：准备原型与研究材料
原型至少包含开始、输入、等待、结果和一条失败恢复路径。固定样本旁标注演示，任何不能操作的部分说明其限制。准备一份自行创作的商品事实，包含目标人群、功能和限制；若参与者自愿使用自己的材料，也必须先确认你能按约定安全处理，不索取机密资料。
再准备观察表：任务起点、用户动作、停顿、原话、是否求助、主持人是否提示、最终结果和你的解释。录屏不是必需条件；如需记录，应先明确征得同意并说明用途。你在本课练习中无需收集用户密码或真实支付信息，也不应让原型触发正式收费。
跟做三：让参与者自己寻找路径
开始前说明测试的是原型，不是考核参与者。介绍任务后尽量观察，鼓励对方说出正在想什么，但不要在每次停顿时马上教操作。记录没有帮助完成与得到提示后完成的区别；如果必须解释才能继续，这本身就是重要发现。
Paul Graham 的《Startups in 13 Sentences》将尽早发布与理解用户联系起来。Startups in 13 Sentences | Paul Graham 本课的应用不是仓促把未完成服务卖给用户，而是尽快让设计接触真实任务。原型能帮助学习，却不能替代最终程序的权限、数据和外部调用验证；两种证据应分别保存。
跟做四：检查不同使用条件
至少用键盘完成一遍输入、生成和复制，并检查焦点是否可见。web.dev 的表单可访问性资料说明标签、说明和错误提示的重要性。Accessibility: forms | web.dev 在原型中就发现问题，通常比开发完成后再重做状态与布局更容易。错误不能只靠颜色，字段用途不能只依赖会消失的占位文字。
如果用户使用手机或辅助技术，尽量让他使用熟悉的设备和设置。不要因为自己在大屏电脑上能完成，就把其他环境标成通过。若无法安排真实设备或参与者，提交一份待验证清单，明确当前只做了结构或桌面检查，而不是编造测试结果。
跟做五：按任务影响整理问题
把问题分成阻止完成、造成明显误解、增加无谓工作和可改进表达几类。每条附上观察证据与受影响路径，不只写“界面不够高级”。例如，参与者把示例结果当成自己的生成结果，属于会影响信任的误解，应优先于更换按钮圆角。
保留不同解释。如果用户没有复制，可能是不满意、还想编辑，或根本没看到按钮；先查记录，再通过追问或下一轮测试确认。不要把所有问题都变成用户提出的功能建议，也不要将少数人的偏好当成全体用户的结论。
加练：把一次求助转为可检验问题
在主持演练中，安排一个虚构场景：参与者问“我需要自己查产品事实吗”。观察者不要立刻新增一个“联网调查”功能，而先记录他看到的页面与产生误解的位置。候选原因可能是首页用了 discover facts 的表达，也可能是输入字段没有说明资料需要已经确认。
先选一个低代价、直接对应证据的修改，例如改清输入说明，再安排下一轮观察。只有当真实任务持续显示需要外部资料收集，才重新讨论产品范围。这个例子是研究脚本练习，不代表我们实际观察到某位参与者。
提交时保留原问题、解释候选、所选修改与尚待验证的预期。你应能解释为何先修文案而不是立刻增加抓取服务，这比只交一个新界面更能证明学习过程。
独立作业：做一次有依据的改版
选择一个影响核心任务的问题，修改相关结构、流程或文案，并写明预期改善。保留其余主要条件，重新观察一轮，说明问题是否仍出现。没有条件安排第二轮时，就提交待验证假设，不宣布改版已经有效。
最终交付包含原型版本、任务脚本、研究告知、匿名化观察记录、问题清单、改版与未解决事项。示例、模拟和真实观察要清楚区分。下一模块将开始实现，你需要把已确认设计与尚未验证的假设分开交给 AI，而不是让它重新猜测整个产品。