阶段6：验证


在验证阶段，设计冲刺团队将会在用户面前呈现我们的设计——这是至关重要的时刻！ 我们能够从与设计原型交互的用户那里得到反馈，并且如果项目需要，还将进行利益相关方审核和技术可行性审核。
在结束设计冲刺时，我们将得到经过验证的方案，或者未通过验证需要改进的方案。无论最终结果如何，设计冲刺团队都已经取得了进步
image.png

6.1 可用性研究（Usability Study）


可用性研究是设计冲刺中的一种研究方法，用于发现可用性问题和确定产品原型的用户满意度，其中包含观察用户如何使用我们的产品并尝试完成任务。
通常会向用户呈现不同的场景，要求他们一边完成任务一边发声思考（译者注：发声思考是用户在完成任务时，同时口头表述自己当前的所思所想）。

可用性研究可以解答的问题有：
●当前的UI设计能否提供足够的信息以便用户开展某项具体任务？
●用户如何使用新的UI设计执行任务？
●页面中的某个元素是否易察觉/易发现？

使用指南：
●招募5名参试者；
●设置一个可用性实验室环境：一间简单用于访谈，另一间留给观察者；
●向参试者介绍测试过程，并为访谈配置好测试脚本。你可能需要借助保密协议（或其他形式的协议）来保护参试者的个人信息；
●确定如何记录测试数据。如果要拍摄测试过程，请务必获得参试者的许可，也可以做访谈记录。

信息概览：
●时长：30-45分钟；
●活动形式：研究员和参试者；
●冲刺类型：所有。

6.2 认知走查（Cognitive Walkthroughs）


认知走查（CW）是设计冲刺中一种进行可用性检查的方法，它强调让新手用户和低频用户完成最常用的任务。

在认知走查中，可用性专家基于以下两个问题，通过完成各种任务来评估产品：
1用户是否知道在当前步骤该做什么？
2如果用户做对了，他们是否知道自己做对了，是否正在向自己的目标靠近？

认知走查是基于任务层面（而非整体）来详尽地评估产品。认知走查的问题设置示例：
●用户能否确定如何完成一项任务？
●用户能否成功合并一个app中的联系人？

使用指南：
●选择任务。为每项任务确定要测试的颗粒度，并相应地分配时间。颗粒度取决于产品和研究问题；
●创建“快乐路径”(Happy Path)，列出完成任务所需的所有操作。如果参与者偏离了这个路径，可能需要将他们引导回来；
●邀请参与者（用户体验或团队中的其他成员）加入会议并以小组形式进行走查。以产品和研究问题为基础，可用性专家按序记录参与者对如何完成任务的描述。主持人应在每项任务之前、期间和之后向参与者提出上文中的两个问题。如果发现存在问题，请记下它并继续走查，直到每项任务都在一开始定好的颗粒度上完成。

信息概览：
●时长：30-34分钟；
●活动形式：研究员和参与者；
●冲刺类型：所有。

6.3 利益相关方评审（Stakeholder Review）


利益相关方评审作为一种设计冲刺方法，用以确认核心利益相关者对于设计原型的支持情况。
核心利益相关方最好能参与整个设计冲刺流程，尽管这并非总是可行。
邀请利益相关方花费半小时参与到设计冲刺中，对设计原型或早期设计概念给予反馈。

使用指南：
●尽早为评审环节排期，以确保利益相关方能够安排进他们的日程；
●如果将评审安排在冲刺的最后阶段，那就安排在用户反馈之后，以便可以分享反馈结果并帮助利益相关方了解用户反馈；
●考虑提前准备好设计原型和用户反馈的演示，以便让整个评审顺利进行。

6.4 技术评审（Technical Review）


类似于利益相关方评审，技术评审这种设计冲刺方法，用以确认产品开发和技术负责人对产品方案的支持。
技术方的利益相关者最好能参与整个设计冲刺流程，尽管这并非总是可行的。
邀请工程师或技术负责人花费半小时参与到设计冲刺中，对设计原型或早期设计概念的可行性给予具体反馈。如
果用新技术或在新领域进行了概念创新，因而需要技术专家
支持，可以从相关的领域内邀请专家组织一次技术评审。

使用指南：
●提前为评审环节排期，以确保工程师或专家能够安排进他们的日程；
●邀请他们亲自前来并且参与用户访谈或者可用性研究；
●考虑提前准备好设计原型和用户反馈的演示，以便让整个评审顺利进行。

信息概览：
●时长：30分钟
●活动形式：小组
●冲刺类型：所有

6.5 冲刺结语：回顾和后续行动（Sprint Conclusion: Recap and Next Steps）


一旦完成验证环节，要将团队再次召集在一起来审视这一阶段的发现。
我们需要为验证环节制作可视化的汇报材料，或者将产出结果汇编进一份文档。此时尤为重要的是团队成员共同复盘研究结果，并从中吸取教训，然后讨论项目的下一步。
每一轮设计冲刺都应该产生可以执行的经验教训，供团队应用到下一轮的产品开发中。

一次设计冲刺可能有如下的产出：
●1次高效的失败：产品原型没能达成目标，但你从中学习到了一些（或者很多）东西，并且避免了你的团队花费4-6个月设计出一个错误的产品。你需要新一轮设计冲刺
●1次有缺陷的成功：有一些想法满足用户需求，但并非所有。你从这次冲刺中有所收获，可以开始再次迭代和测试
●1次史诗般的胜利：产品概念满足用户需求；用户能够轻松完成任务，并且能够融合到你规划的所有特性。万事俱备，只待实施！

结束设计冲刺。 整个团队努力工作，各种想法层出不穷，用户访谈收益颇丰。
冲刺导师这时应该感谢所有成员的努力，祝贺整个团队获得的宝贵经验。
总结，是凝聚团队的好方法。你可以让团队成员分享自己的见解，询问他们将这次经历中获得了什么，让他们有成就感。
此外，或许可以讨论下一步要解决什么问题