原型风险矩阵用来决定先验证哪个假设，而不是先画哪个页面。把“不确定的判断、判断出错的后果、现有依据、下一步验证”放在同一张表中，优先处理影响大、依据弱、后期难以修改的问题，再为它做一段能走通的原型。这样，原型评审讨论的就不只是页面好不好看，而是项目最重要的不确定性有没有减少。
例如设计企业设备借用流程，最值得先做的可能不是设备详情页，而是“选中的日期已被占用时，员工能否改期并保留设备与申请信息”。可以用墨刀原型连接冲突、改期和确认页面，让团队沿同一条路径检查这个问题。
风险矩阵里放假设，不放功能愿望
“增加日期选择器”是一个解决方案，不能直接说明风险；“员工能够发现日期冲突，并在不重填申请的情况下改期”才是可验证的假设。后者同时包含用户、条件、预期行为和失败后果。
先从需求讨论、客服反馈和业务规则里找出团队目前只是“觉得应该如此”的判断。每条只写一个问题，避免把库存、审批和提醒揉成一行。设备借用可以先列出下面三条：
| 假设 | 如果判断错了 | 现在应找什么依据 |
|---|---|---|
| 员工理解“提交申请”不等于“已借用” | 以为预约已经生效，到现场才发现未获批准 | 是否出现过类似咨询；申请人与管理人的理解是否一致 |
| 日期冲突后可以改期，不必重新选设备 | 反复填表，或者误以为原来的设备被取消 | 当前页面是否保留信息；员工能否独立完成恢复 |
| 填申请理由之前可以判断日期是否可用 | 填完长表单才遇到冲突，前面的工作可能白做 | 可用性信息来自哪里；展示时点是否足够早 |
不要把“现在应找什么依据”写成已经得到的结论。没有访谈、记录或演练结果，就写“暂无直接依据”，下一步安排一次相应检查。把未知写清楚，远比用一个看似精确的分数掩盖未知更有用。
按后果、依据和修改代价排序
第一次使用不必建立复杂公式。团队先用高、中、低三个等级回答三个问题：判断错了会影响什么任务；现有依据是否直接对应当前场景；如果上线后再改，要牵动多少流程和规则。
| 组合 | 处理方式 | 设备借用中的对应问题 |
|---|---|---|
| 影响高，依据弱 | 优先安排验证，再投入细节设计 | 冲突后是否保留已选设备与填写信息 |
| 影响高，已有直接依据 | 把已知规则落实到原型，并检查遗漏条件 | 审批通过后才确认借用，不能只用模糊成功文案 |
| 影响低，修改容易 | 记录并靠后处理 | 设备卡片次要说明的排列位置 |
| 修改代价大，即使发生机会不明 | 单独提出决策，不让它被平均分淹没 | 日期占用是在提交申请时还是审批通过时发生 |
最后一项尤其容易漏掉。页面上都可以画一个“不可用”提示，但占用时点不同，会改变审批、冲突处理和通知逻辑。这类问题应先由业务与研发确定规则；原型随后验证规则能否被理解。原型画得再完整，也不能替团队决定库存分配政策。
若团队确实需要数字，可用统一的三档评分辅助排序，同时保留理由。不要把评分解释成失败概率，也不要因为两条风险差一分，就跳过对业务后果的讨论。
把最高优先级压缩成一段可验证的路径
假设这一轮优先验证“日期冲突后能否恢复”。原型只需要覆盖员工从发现冲突到重新确认的过程，不必先画完设备采购、维修和管理后台。
- 建立“设备与日期已选”页面：设备为“摄影套装 A”，数量为 1，已经选好计划借用日期。若表单还包含申请理由，也填入固定内容，便于之后核对。
- 建立“日期冲突”状态：指出是哪一天不可用，保留已选设备、数量以及当前日期，不把整张表清空；已有的申请理由也应保留。
- 建立“选择其他日期”状态：员工可以改到另一个可用日期，也可以取消改期，回到原来的申请内容。
- 建立“申请确认”页面：仍是摄影套装 A、数量为 1，日期已更新；若有申请理由，应保持不变。提交后的文案明确进入待审批，而不是显示借用已完成。
在墨刀中为这些状态分别建立页面并连接操作。页面名写成“借用申请—日期冲突”“借用申请—改期后确认”，评审意见就能指向具体状态。若一个按钮在两个入口下应返回不同位置，需要分别连线检查，不能用一张孤立的成功页代替完整路径。
先写判断条件，再邀请别人评审
如果先看演示再定标准，团队很容易把“演示顺利”当成“风险已解决”。开始前就写清楚，什么观察会让你继续推进，什么观察要求修改。
给评审者一份已填好的设备申请，让其处理日期不可用的问题。评审者应能说明冲突发生在哪一天，自行改到可用日期，确认设备和数量没有丢失，并知道提交后还需等待审批。任何一步需要主持人指出操作位置，都应记录具体卡点。
任务说明不要写“点击更换日期”。这会直接提示操作，无法检验员工是否能发现恢复入口。更合适的说法是：“你需要借用这套设备完成拍摄，但原计划的日期不可用，请把申请调整到另一个可用日期。”
要进一步区分任务脚本、观察和结论，可以使用原型可用性测试的记录方法。本轮只需要围绕当前高优先级假设取证，不必顺带给所有页面做一次完整测试。
把评审结果写成决定，而不是“基本没问题”
以下记录格式可以直接放进团队文档。它让下一位接手的人知道为什么改、改到哪里，以及还缺什么决定。
- 风险编号与假设：R-02，日期冲突后能保留设备和数量完成改期。
- 失败后果：员工重新填写或误判申请状态，无法确定是否需要重新提交。
- 当前依据：填写实际的访谈、咨询记录或演练观察；尚未验证时保持为空缺待办。
- 原型范围：日期已选、冲突、改期、确认四个状态及对应版本。
- 判断条件：能指出冲突、完成改期、核对信息保留、理解待审批。
- 观察与决定：记录哪一步停顿、误解了什么；选择继续、修改后再看，或先补业务规则。
- 后续负责人：设计修改恢复入口，业务确认占用时点，研发确认真实冲突校验。
例如评审中发现员工以为“取消”会放弃整份申请，就应修改按钮文案或返回方式，并重走取消分支。不能只把矩阵中的风险等级调低，却让原型保持原样。涉及真实可用性的数据检查，则要交给实现环节验证，不写成原型已经证明库存正确。
什么时候可以停止这一轮验证
可以推进到下一步的条件是：当前假设已有足以支持决定的观察，关键状态在同一版本中可重走，剩余问题已明确影响和负责人。没有必要为了“零风险”把所有页面做成高保真，也不能因为页面很完整就提前结束。
确定先验证什么之后，再用原型分支覆盖清单确认取消、失败与返回路径有没有遗漏。风险矩阵负责排优先级，分支清单负责把选中的任务做完整，两者不要各自维护一份相互矛盾的规则。
开始时只挑一条“后果明显、依据不足”的假设，把相关页面连起来，分享给需要作出决定的人。第一轮原型的价值，是帮助团队决定下一步值得投入什么。
