制作原型之前，先补全这句话：“我们需要弄清楚是否……”答案决定需要做到什么程度。简单草图可以讨论布局，浏览器中的实际交互则能暴露更复杂的行为问题。过早精修还可能让尚未确定的方案看起来已经获批。
用线框图讨论内容和顺序
线框图保留页面的主要部分。对于一家假想的订餐服务，可能包括套餐、配送范围、饮食信息和下单入口。讨论重点是内容是否齐全、顺序是否合理。
写入有代表性的标题，并使用接近真实的文字长度。空白灰框会隐藏信息表达上的分歧。如果需要知道客户是否理解服务，文案清晰的粗略页面比装饰细节更有价值。
- 适合回答
- 内容顺序对吗？
- 投入
- 无法告诉你
- 实际使用的感觉
只做到问题需要的程度，每升一级修改成本都更高。
用可点击原型检查操作路径
把屏幕连接起来，可以观察用户如何理解选项和完成步骤。例如选择餐食计划、调整份数和确认配送日期。提供返回路径，不要假设所有人第一次就能选对。
列出模拟部分：日历可能展示日期却没有检查配送容量，支付成功也可能只是示意画面。向相关人员说明这些边界，避免把演示误认为成品功能承诺。
当问题涉及真实行为时使用代码
需要检查换行、键盘焦点、输入校验或动态计算时，浏览器原型更合适。让价格随着份数变化，可以发现固定画面没有呈现的细节。测试长名字、意外输入和窄屏手机。
使用测试数据，并与正式服务分离。能够运行的界面代码仍需经过安全、可访问性、维护性和后端行为审查。按钮能够点击，不代表订单已经可靠保存。
提前确定测试后的用途
原型将被丢弃、保留作参考，还是审查后复用？记录已接受的决定、参与者遇到的问题和仍未测试的假设。即使原型不再保留，这些记录也能支持后续开发。
小项目可能只需要一份线框图和一个重点交互演示；复杂应用可能值得多轮验证。选择能够改变决定的最小实验，在问题得到回答后结束这一轮。
开始之前
- 先写下需要回答的问题。
- 使用真实长度的内容，并允许返回修改。
- 标明模拟数据和未连接的服务。
- 正式复用前审查原型代码。