原型评审会上意见互相冲突，怎样用待验证问题代替现场投票？

原型评审意见互相冲突时，应先确认各方想解决的用户任务和所依据的证据，再决定哪些意见可以直接修订、哪些需要验证。现场投票可以反映偏好，却不能证明路径更适合用户；评审要留下问题、假设、验证动作与决定人。

让意见说明失败后果

听到“按钮应该大一点”“流程太长”时，追问它影响谁、发生在哪一步、会造成什么困难。若只是个人偏好，可以记录为方向意见；若指向真实任务失败，应附上操作或反馈证据。

不同角色关注点可能合理却不一致。业务人员希望资料完整，用户可能希望先了解适用范围，开发人员关注条件是否可实现。先明确这些问题的对象，避免将所有意见混成一个版式争论。

成功标志是每条意见能够对应任务、约束或偏好类别，并说明哪些事实已经确认。会议因此可以讨论决定条件，不必反复让参与者重述同一句喜好。

冲突写成两个可比较的假设

把冲突方向表述为能验证的问题。例如，先展示简要说明是否足以帮助用户选择，还是需要先填写资料才有正确路径。记录每个方向假设用户知道什么，以及需要什么业务条件。

不要将方案名称写成结论。“更简洁”或“更专业”仍需说明具体含义；可以比较用户能否找出必要信息、解释下一步和识别限制，而不是只问更喜欢哪个版本。

与界达设计工作室（JVDS）开展原型与官网设计沟通时，可将冲突记录和已批准资料作为输入。验证方法、参与者获取与实施边界按项目明确，不把会议中的假设当作已证实需求。

验证方式要与问题相匹配

信息是否容易找到，可以通过任务观察；业务规则是否允许，应找责任人确认；实施条件是否成立，应由技术人员核对。不能让用户投票决定企业权限规则，也不能让技术可行性代替用户理解检查。

假设评审争论要不要先展示全部服务内容，可以给参与者同样任务，比较两种组织下怎样判断适用范围。不要先教会其中一组答案，再将它与另一组的独立表现比较。

样本和条件有限时，应保留结论边界。一次受控验证可以帮助选择当前方案，但不能推导所有访客都会得到相同体验，或某方向必然带来商业增长。

给决定留下可以再打开的条件

决定记录写明问题、现有证据、采用方向、理由、负责人和需要继续观察的情况。这样后续有人提出不同意见时，能补新证据，而不是重新进行同样的现场争论。

未解决的业务条件可以暂停对应分支，同时推进不依赖它的工作。暂停的是特定决定，不需要让整套原型无期限等待；但也不能在缺少批准时假装该规则已经确定。相关操作可参阅《低保真、高保真、可交互原型有什么区别？按验证问题来选》。

成功标志是团队知道下一步做什么、谁提供依据、什么时候重新讨论。原型评审由此成为减少不确定的过程，视觉偏好也能得到合适的位置，而不是压过任务与事实。

常见问题

所有人都喜欢同一个版本，可以直接通过吗？

可以作为偏好证据，但还要核对主任务、业务规则与实施条件。若这些条件已经明确且无关键缺口，可以确认方案；一致喜好本身不能替代任务验证。

没有时间做用户测试，冲突怎样处理？

先确认已有证据与必要约束，记录仍未验证的假设，由明确负责人选择当前方向并安排后续复查。不能因为没有测试时间，就将内部选择写成已被用户验证。相关操作可参阅《设计稿开发前怎么验证？别把内部评审当成用户验证》。