Google倾力打造的设计冲刺方法论(6/6):验证阶段

阶段6:验证

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

产品经理,产品经理网站

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次史诗般的胜利:产品概念满足用户需求;用户能够轻松完成任务,并且能够融合到你规划的所有特性。万事俱备,只待实施!

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

 

内容原创作者:Google

原文链接:https://designsprintkit.withgoogle.com/methodology/phase6-validate

翻译: TANG  审校:华姐

本文作者 @TANG

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部