第四天-第五天，协同设计阶段
协同设计阶段帮助减少低效沟通消耗掉的时间。
让所有团队成员就要解决什么样的问题达成一致（即“如何做”背后的“为什么做”），能够最大程度地减少实施过程中的方向错误。设计师和开发人员能够更多地进行思考，而不是一味地执行。
协同设计阶段有两个步骤：
1）设计发散
2）设计收敛
每一个HMW问题都会经历各自的发散和收敛阶段，并且不止一次。从上个阶段你们定义的最高风险的问题开始吧。
记住设计协同需要在一个对所有想法（无论是多么疯狂的想法）都非常友好的环境中开展。
能够杀死想法的语句是普遍存在的，比如“那样根本行不通，”“我们不会这做，”或“这方法我们已经尝试过了”，它们往往会破坏自由表达的氛围。
如你所想，这个阶段会产生大量的草图。有些成员会羞于表达，他们觉得自己没什么创意或者短暂的时间内无法完成。然而创意在每个人的脑中，“有创造力的人”和其他人的区别仅仅在于态度和经验两个方面。
▍设计发散
为了解决HMW问题而创想出尽可能多的想法和方案，这个阶段叫做发散。下一步再对所有想法进行检视，筛选出最好的几个。
只有穷尽所有可能，才能知道什么样的解决方案最有价值——所以本阶段的目标是构思，并且越多越好。
此时我们的目标是数量，而非质量。
1）热身阶段
该阶段从探讨粗略的功能列表开始。为团队准备好所有的想法和概念，好让大家可以共同绘制草图。
△ 给团队5分钟的时间在便利贴上写下任何能够回答HMW问题的设计功能点；
△ 告诉团队不需要去探讨实际功能或者视觉效果的细节，只是较为粗略的功能；
△ 将这些便利贴贴在讨论墙上，对它们进行初步的分类。会开始形成几个大的功能点。
假设有一个预算较高的项目，针对宽泛的HMW问题像是“我们怎样提高顾客对产品的粘性？”可能会产生这几组便利贴内容：“游戏化体验“”易用性“及”社交媒体功能“。在绘制草图的过程中，大家将会开始探索这些功能（例如我们对哪几步的流程进行游戏化设计）。
不管你在设计什么样的产品，世界某处的某些人或许已经做了类似的事情。用这些类似的产品当作解决方案最初构想的来源。
△ 鼓励团队所有成员进行相关产品的收集。
△ 在开始协同设计前，将案例打印出来以帮助设计出更好的产品。
先不要限制任何想法（这是下一阶段的工作）。你只能促进大家得出更多的想法并帮助大家进行归类。此时的成果将指导草图设计，毕竟不是每个人都是视觉设计师，能做到从0开始进行设计。
2）共同绘制草图
目前你们已经得到了很多关于功能点的构想，共同绘制草图阶段从“6+”（6-up）开始。（“6+”是一张A3纸，分成了6个线框，每个线框将用来表现一种方案。）
给大家5分钟的时间，根据HMW问题绘制出尽可能多的解决方案。
时间到了之后，将所有的草图张贴到墙上。每人向团队展示他们的解决方案。当他们在讲解的过程中，其他的团队成员将意见写在便利贴上。
所有的反馈遵循以下两种形式：
△ “我喜欢……”——你认为该构想的闪光点在哪里
△ “我想……”——你认为可以怎样改善这个解决方案
此时大家应该尽可能多地写下自己的反馈和想法——每张便利贴写一个。确保每个人都在相应的方案下贴上了自己的想法。
▍设计收敛
每个人都展示了他们的构思后，大家一起浏览便利贴上的反馈意见，整合出每个功能点的最优设计方案。
要记住每个想法都不是个人所有，而是集体共有。只有不断相互启发和拓展，才能得到最好的解决方案。
给大家5分钟的时间，将他们自己心中的最优方案画下来。在一张“1+”纸上进行。“1+”（“1-up”）是一张A3大小纸，上面印有相应设备、状态的模版。
5分钟后，大家把“1+”方案轮流贴在之前的“6+”方案一侧。
每个团队成员再次向所有人展示他们的方案，揭示草图背后的逻辑依据。
现在大家不用给予反馈，而是开始投票。即可以给完整方案投票，也可以支持其中的某一个功能概念。给每个成员三张圆形的贴纸以供投票使用。
如果有方案全票通过，就可以直接拿去进行原型设计了。如果大家的投票都很分散，则可以从不同的方案中提取好的部分，整合为一个原型。为防止最后整合出一个“怪物”（Frankendesign），此时让设计师和产品经理来做决定。
如果有两个方案不相伯仲，则可以绘制两套方案的原型，并进行A/B测试，以决定哪个在用户测试中的表现更佳。
对于剩下的HMW问题，采取同样的发散和收敛的方式。保存好所有的设计草图。
如果你是UXPIN的用户，这时可以将草图拖入你们的项目中（他们将对随后的原型设计起到指导作用，并且你也省去了保存一叠纸张的空间和时间）。在讨论结束后，有任何新的想法团队成员都可以在草图下方进行评论。
第六天-第七天制作原型
一旦完成了方案的发散和收敛阶段，你们就会得到一个值得进行深入设计的核心功能列表，来开始共同设计。
在绘制原型的过程中，要尽可能地省时省力。记住精益和敏捷ux的重要教训在于：专注于最小可实现产品（MVP）的构建。
从我个人经验来说，这个阶段不需要进行代码的编写，因为很难快速对代码进行迭代。而且不是每个设计师都能像手绘和电脑制图一样，快捷地用代码直接编制出原型。
▍电脑原型
对于数字产品而言，让一到两位经验丰富的设计师来将协同设计的成果提炼为原型——如果要做A/B测试的话，就要设计出两套原型。让我们来探索如何快速进行原型设计吧。
1）列举出主要的用户流程
在开始绘制原型之前，构想一下在用户测试中会让他们执行哪一种流程。据此你能够确定原型设计的范围。
例如，想象我们正在绘制一个饮食管理的APP，我们要回答的HMW问题时：“我们要怎样鼓励用户尽可能多地使用我们的APP？”最后脱颖而出的解决方案可能是用游戏化的方式，当用户完成任务时，发放徽章作为奖励——例如发布第一道健康午餐／晚餐、严格遵守当天的卡路里摄入标准、减掉5磅等等。
如果只绘制出之前协同设计中所构思到的页面，你们会得到一些散乱的界面，比如上传午餐的、展示徽章的。然而这并不符合用户真实使用的场景。
相反的，你们需要思考在进行用户测试时的完整用户旅程。例如：
拿出手机——>打开APP——>浏览到了“添加一道健康餐”的模块——>点击添加——>找到他们早餐吃的食物——>点击提交——>收到发布第一道健康餐的奖励，一个徽章。
接下来为了更好地验证这次用户旅程，你需要：
△ 让用户重复相似的操作：添加午餐、晚餐、各种零食
△ 然后发放给他们一个徽章，作为他们遵守卡路里摄入指标的奖励。
通过这种更接近真实场景的方法，测试环节将会更加精确。将这些流程覆盖的每一个步骤都列出来，你就会得到本次需要绘制哪些页面。
2）绘制这些具体步骤的草图
现在我们把之前得票较高的“1+”草图都拿出来，
如果在这些方案中，一张草图脱颖而出，且它各个功能点的得票比较分散，则：
△ 将得票数高的功能提取出来，研究怎样将它们结合在一起。这些功能点应当互不相同。如果很相似的话，就绘制两套原型并进行A/B测试。
如果这些草图中，有几个得票非常相似：
△ 构思出A、B两种方案。确定两个方案各自的核心竞争力，构建平衡的竞争关系。例如在A/B测试中，使用同样的测试流程，以防止用户在使用第二个方案时产生疲劳感。
如果协同设计中已经出现了明确的赢家：
△ 仍然将用户流程每个步骤的草图画出来，以指导原型设计。
你可能已经发现了，原型中并不包含所有的内容。例如，导航可能就没有涉及到。别着急——协同设计的目标是找到HMW问题的答案（核心功能点）。你们的交互设计师能够用UI元素去填补流程中的空白。
下一步，在纸上或者白板上绘制每一个界面的草图。
千万不要与上一步的成果相差太远。如果你这样做了，无异于侵蚀了团队辛辛苦苦奠定的良好基础，也否定了协同设计的意义。
通过草图决定了每个界面该怎样表达后，一切即准备就绪，可以自由选择便捷的原型工具进行绘制了。尝试花尽量少的时间完成电脑原型。例如，只绘制必要的界面。如果你们在测试中不会让用户去看“关于我们”这一页，就不要去画它。
如果你是用在线工具（如UXPin）绘制的草图，现在就可以向利益相关者和客户展示它们，以获得反馈。
▍原型保真度
原型保真度即是原型接近真实画面的程度。
例如，低保真原型可以是纸面草图；高保真原型则可能不仅看起来，连互动起来都与真实网站别无二致。
原型保真度越高，你能从中学到的东西就越多。例如，你将能知道什么样的颜色最能吸引到用户的注意、用户对产品的界面和氛围有什么用的想法。
如果你们已经有现成的风格指南，做高保真原型就会更加容易，因为它省去了很多进行决策需要花费的时间。这样的情况下就建议制作高保真原型。如果时间很紧张的话，做低保真或者中保真页可以，同样能够验证方案有没有对大部分的HMW给出解答。
做低保真或者中保真原型时，几种精力在20%的核心功能点上，它们能解决80%的HMW问题。
▍制作实物原型
制作实物原型的步骤几乎和制作数字原型的步骤相仿，除非你完全用实体的方式来进行产品设计。
确保你用的是轻量级、易于修整的材料。例如，如果你在做一个停车设备的原型，不要用木材或者金属，用纸板。因为纸板更便携，而且易于修改。
同样的，也得平衡时间精力和保真度。太过低保真的话，用户测试的场景就会与真实情况相去甚远。太高保真则会花费太多时间。
例如，有一次我们用彩笔在纸盒上绘制出包装图案去进行用户测试。在用户测试的过程中我们发现，人们不会严肃地看待这件事情。因此在下一轮测试中，我们用AI绘制了图形，用光面纸张打印，固定在高品质的纸板上。这一过程和在纸盒上手绘花费的时间几乎一样长，但明显得到了更有帮助的测试结果。
第八天-用户测试
用户测试这一阶段是大家所公认的真理时刻。既然已经设计了原型，这时可以向真实用户获取反馈了。
在我们过去的经验当中，原型的第一次测试中，我们得到的重要发现从没少于过20个，所以在测试前，先准备好面对严肃的反馈吧。
▍定义测试角色
在用户测试过程中，需要两种角色来保证测试的正常进行。
1）任务推动者
任务推动者给予用户任务并且在用户执行的过程当中提问。他的工作是保证测试全程的真实性并且观察和发现用户的真实想法。一般这一职责由设计师来担任。
2）记录员
记录员负责在测试过程中精确记录用户的行为。为了一字不差地记录下（而不是自己用户的反馈，你们需要选择一个打字很快的人。
千万不要低估这个角色的重要性——如果没有很好的记录下测试过程中的发现，大家会忘了测试中发生了什么，以及导致这些情况的原因。
对于团队其他成员来说，共同观察测试过程也非常重要。这能够帮助他们得到第一手的信息：什么要素发挥了作用，而哪些没有效果。这比事后说服他们要高效多了。
如果你做的是电子原型的测试，可以尝试各种各样的工具来将不同用户与原型的所有交互过程记录下来，不论测试设备是android手机、iphone还是电脑（这样的程序有Lookback，UserTesting，或者Uxpin）。另外一种可选方式是用智能手机、Gopro或者其他相机来录下测试的全过程。
如果对测试过程进行了录像，就不一定非得需要一名记录员了。
如果有Wifi的话，也可以通过Google Hangouts，X-Split，Skype等工具来进行线上测试。
不论你在现场观看还是和大家一起看录制的视频，都试着从团队的角度来观察。大家观察每个用户使用原型的过程时，鼓励他们将发现写在便利贴上：
△ 绿色代表着积极的评价
△ 粉色代表消极的评价
△ 蓝色表示个人观察到的一些点
用粗头的笔来写字，这样才易于读取，重点是能够保证内容的简洁。
写完之后，将你的发现贴在墙上，快速得到一个亲和图。你们会开始看到不同的用户也会有着类似的反馈。将这些发现进行归类，会得到如下的一个成果：
如果你的团队成员无法在同一房间内工作，则可以用彩虹电子表格来得到相似的成果。（这是由前Google用户体验设计师Tomer Sharon提出的一种方法）
▍如何开展和主持用户测试
△ 从自我介绍开始。
向参与测试的用户提出几个简单的关于他们自己的问题，来确认他们是否符合你们对于人物模型的定义。
△ 随后，提醒他们用户测试的一些原则。
△ 真正的测试从给用户设置真实的使用场景开始。给用户讲述一个真实的故事，便于他们想象真实的使用场景。例如可以这样说：
随后他们就准备好进行第一个任务了，这个任务可能是这样：
每一个任务需要覆盖到产品的某一个功能特性。直到测试完了所有你想测试的部分，再停止。
△ 结束的时候问他们3个问题，旨在了解用户对于产品整体的看法。例如：
“对于这个产品你最喜欢的一点是什么？”
“对于这个产品你最不喜欢的一点是什么？”
“你会如何向朋友介绍这款产品？”
▍鼓励用户提出建设性意见
在测试的过程中，通过以下的方法鼓励用户多多给予反馈：
1）试探
通常这样询问：
“你现在在思考什么问题？”
“你下一步打算做什么？”
“假设你[在家]（通常的地点）进行这个任务，你会怎么去做呢？”
2）重复
如果用户说到：“哦，真怪异。”
任务推动者应该问：“什么让你觉得很怪异？”
这种方法能够让你直接得到用户反馈的原因，而不是进行推测。
3）反问
用户遇到难题时，既有可能向任务推动者询问，也有可能自问自答。了解用户在无人帮助的情况下怎么理解问题，同样非常有帮助。这时你可以反问他们：
“我需要注册吗？”
“你觉得如何呢？”
4）为什么
如果用户评论了什么或者做了些什么，询问原因。
这能够帮助你了解具体情况，并进一步帮助设计进行决策。同时重复用户的语言，减少测试人员偏向性用词对用户的影响。如：
“这个很酷～”
“为什么觉得它很酷呢？”
▍测试后跟进
测试阶段结束后，别忘了给参与的用户发邮件，重申一下内容：
△ 测试报酬落实的进程（如你将何时以何种形式给他们发放礼品卡或者礼品袋）；
△ 表达对于他们充满洞察力的反馈的感激
△ 保证他们的反馈是完全保密的，不会做为公司项目以外的任何用途。
第九天及之后-原型迭代
在与团队成员讨论、分析用户测试阶段的成果，并将大家的观察进行分类后，你们就该准备对设计进行迭代了。
现在带领团队直接跳转回之前的协同设计阶段。第二次的协同设计与之前的流程类似，不同之处仅在于这次是基于用户测试的结果进行设计。
针对所有需要迭代的功能点，遵循同样的发散、收敛设计的过程。
然后再次对产品进行测试，对这次迭代进行验证。毋庸置疑的是，还会发现很多亟待解决的问题。
在将来的设计冲刺中，你们可以开始处理哪些候补的低优先级HMW问题。通过同样的发散、收敛和测试，解决它们。
如果你是Uxpin用户的话，迭代就变得很容易了：只需要点击右上角的“迭代”按钮（iterations），开始下一版本的原型设计工作，之前的版本会被自动保存。
不断重复测试、迭代的环节，直到参与测试的用户开始问你类似的问题：
“这个版本什么时候发布呀？”
“这个产品大概多少钱？”
“我可以拿去用吗？”
到了这个阶段的时候，你就可以开始准备将设计转化为代码了。
但你的工作还没结束。正如很多人说过的那样：设计是一件团体运动。和开发人员一起校核每个版本，向团队其他成员展示最后设计实施的情况并征求意见。
这整个过程我设置的时间是9天，但大家可以按照自己的需求来安排。完成设计冲刺后，你将作出更加明智的产品决策。
上一篇：
下一篇：
