设计冲刺包括六个阶段——理解、定义、草图、决策、原型和验证。本文主要讲验证阶段，设计冲刺团队将会在用户面前呈现我们的设计——这是至关重要的时刻！

阶段6：验证

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

6.1 可用性研究（Usability Study）

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

可用性研究可以解答的问题有：

当前的UI设计能否提供足够的信息以便用户开展某项具体任务？

用户如何使用新的UI设计执行任务？

页面中的某个元素是否易察觉/易发现？

使用指南：

招募5名参试者；

设置一个可用性实验室环境：一间简单用于访谈，另一间留给观察者；

向参试者介绍测试过程，并为访谈配置好测试脚本。你可能需要借助保密协议（或其他形式的协议）来保护参试者的个人信息；

确定如何记录测试数据。如果要拍摄测试过程，请务必获得参试者的许可，也可以做访谈记录。

信息概览：

时长：30-45分钟；

活动形式：研究员和参试者；

冲刺类型：所有。

6.2 认知走查（Cognitive Walkthroughs）

认知走查（CW）是设计冲刺中一种进行可用性检查的 *** ，它强调让新手用户和低频用户完成最常用的任务。在认知走查中，可用性专家基于以下两个问题，通过完成各种任务来评估产品：

用户是否知道在当前步骤该做什么？

如果用户做对了，他们是否知道自己做对了，是否正在向自己的目标靠近？

认知走查是基于任务层面（而非整体）来详尽地评估产品。认知走查的问题设置示例：

用户能否确定如何完成一项任务？

用户能否成功合并一个app中的联系人？

使用指南：

选择任务。为每项任务确定要测试的颗粒度，并相应地分配时间。颗粒度取决于产品和研究问题；

创建“快乐路径”(Happy Path)，列出完成任务所需的所有操作。如果参与者偏离了这个路径，可能需要将他们引导回来；

邀请参与者（用户体验或团队中的其他成员）加入会议并以小组形式进行走查。以产品和研究问题为基础，可用性专家按序记录参与者对如何完成任务的描述。主持人应在每项任务之前、期间和之后向参与者提出上文中的两个问题。如果发现存在问题，请记下它并继续走查，直到每项任务都在一开始定好的颗粒度上完成。

信息概览：

时长：30-34分钟；

活动形式：研究员和参与者；

冲刺类型：所有。

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

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

使用指南：

尽早为评审环节排期，以确保利益相关方能够安排进他们的日程；

如果将评审安排在冲刺的最后阶段，那就安排在用户反馈之后，以便可以分享反馈结果并帮助利益相关方了解用户反馈；

考虑提前准备好设计原型和用户反馈的演示，以便让整个评审顺利进行。

6.4 技术评审（Technical Review）

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

使用指南：

提前为评审环节排期，以确保工程师或专家能够安排进他们的日程；

邀请他们亲自前来并且参与用户访谈或者可用性研究；

考虑提前准备好设计原型和用户反馈的演示，以便让整个评审顺利进行。

信息概览：

时长：30分钟

活动形式：小组

冲刺类型：所有

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