Lean UX （第二部分）
过程
某个星期二，Rick， Mark, Olga和Arti站在白板面前，看着他们画的线框图。Artis有一支记号笔在手上，但是她没有在画。“Rick, 我不知道你在策划什么，你能解释一下存在的问题吗？”
Rick拿起记号笔，擦干了板上的一部分内容，又一次解释了规则。团队正在为股票商们设计应用，而这个应用要严格遵循一个系列的规则。Rick作为一个商业分析师有责任保证团队的设计是支持这些规则的。
过了一会儿，团队成员们点了点头，Arti再次拿起了记号笔。她对这个白板上的app设计建议了一个修改，而团队又一次点头认同。他们都拿出了iphone，对板上的内容拍了照片，并且同意明天再次开会。他们很有信心，认为这个他们达成一致意见的东西会为周三的用户测试做好准备。
Arti作为设计师回到她自己的位子上开始为他们所画的设计补充细节。Mark作为前端设计师开始建立页面--他根据设计的情况从现有的样式指南中选择预制的组件来制作，这样他将基本控件布置好之前就不用等Arti的设计。Rick 打开wiki站点，同时开始记录团队关于应用行为做的决定。他会和产品拥有者在后面的时间讨论这些选择。Olga，作为qa测试，开始编写这个应用的新的部分的测试流程。
这就是每一天的精益UX节奏：整个团队在很少的相互干涉、最小化的产物交付中协同、重复、平行地工作，伴随极小化的交付，并且专注于工作软件和市场反馈。在这一章节中，你会看到这是怎么做的。
在之前的章节中，我给你们展示了精益UX背后的想法——那些驱动工作的原则。在这个章节中，我会切实而细致地描述实行精益UX的过程。
章节三，“视角、框架和产出”描述精益UX是如何逐步地提升我们构筑工作的方法。我们的目标不是去创造一个可交付的成果，而是去改变这个世界上的一些东西——去创造一个产物。在这个章节中我会描述我们用的关键工具：假设陈述。
章节四，"协同设计”，描述了我们设计过程中的转换。精益体验运用了很多设计师熟悉的技术但是转换了我们工作的重心。我们变得更加合作化。我们的目标是速度第一。我们优先考虑学习。我们用了一个非常关键的工具来达到这个目标：MVP工具。
第五章，“MVPs和试验”是关于试验的部分。精益体验的基础是我们要有一个从假设中开始工作的想法。我们用试验来测试我们的假设，同时将我们的学习建立在这些试验之上。这一章节向您介绍了如何围绕试验和学习定位自己的设计流程。
章节六，“反馈和试验”，处理反馈的东西。任何形式的用户体验工作都需要优质的用户信息输入。精益用户体验非常注重利用持续的用户反馈来指导我们的设计流程。这一章节展现给你精益用户体验团队用来尽快拿到用户反馈的技术，以及如何将这些反馈应用在我们未来的产品迭代。
第三章：
视角，框架和产出
传统来说，用户体验设计项目是通过需求和交付产物来构建的，将需求传达给团队，然后团队做出可交付的产品。精益用户体验逐渐转化了我们构建工作的方法。我们的目标不是去创造一个简单的可交付产物，而是去改变世界上的一些东西——-去创造一种结果。我们从猜想开始而不是需求，我们在创造的同时测试我们的假设。我们会去衡量是否达到了我们期望的结果。
这一章节主要介绍以结果为中心的工作方式的主要工具：假设陈述。这个假设陈述是一个项目的开始点。它在为工作展现了一个清晰的愿景的同时，也将团队成员和他们的管理者的交流从产出（比如”我们会创造一个单点登录功能”）转变为结果（比如“我们想要增加我们服务的新登陆数量”）。
假设陈述是以一种可测试的表达我们猜想的方式。是通过以下元素组成的：
猜想
对于我们相信是正确的东西的更高级的表达方式。
假设
对于我们的猜想更精细的形容，如特定目标市场或试验的工作流程。
结果
我们在市场上寻找用以证明我们的猜想正确或错误的信号。这些信号一般都是定量的，但也可能是定性的。
人物角色模型
这些人物模型中的人物，我们相信我们正在为他们解决问题。
功能点
我们相信产品的改变和进步会促进我们寻找的结果。
让我们来更细致地看看每一个元素。
猜想
精益用户体验流程中的第一步是表达自己的猜想。每一个项目都是从猜想开始的，但是通常我们不会明确确认这一事实。反而，我们尝试去忽略猜想，更糟糕的是，我们还会把它们当作事实。
声明你的猜想会让你的团队去创造一个共同的起点。整个团队通过这一行为，你可以给每一个团队中的设计者或者非设计者一个表达他自己对于如何最好解决问题观点的机会。经过假设陈述能让每个人的想法展现到白板上。它能展现出团队的意见分歧，同时展现一系列可能的解决方案。
猜想陈述是精益体验流程中的第一步，见图下图：
方法：猜想陈述
谁
猜想陈述是一个团队活动。团结你的团队，确保每一个学科都有可代表的人物，保证任何项目中任何关系到的东西都有相关专家能给予重要的知识。比如，如果你正在处理一个经常性的用户抱怨，有一个呼叫中心的用户服务代表参与将会很有利。呼叫中心的服务代表比组织里的任何一个人与更多的用户谈话，在这点上比团队里的任何一个人更有想法。
准备工作
预先给团队关于他们将要处理的问题的通知，好让每个人都有机会在你开始前，去准备他们需要的任何材料，或者做相关的调查。预先要准备的重要的东西包括：
1 描述当前的产品是如何被使用的分析报告
2 描述用户为什么在你的产品上做相关操作的可用性报告
3 过去尝试解决这些问题时留下的信息，以及他们的成果和失败
4 企业利益相关者的分析，用以了解解决这个问题会如何影像企业的表现。
5 竞品分析，展现竞品是如何解决这些相同的问题的
方法：问题陈述
团队需要这个活动的一个开始点。我发现从问题陈述开始是非常有帮助的。（可以在此章节的后面部分看这个陈述的模型）问题陈述的方式可以给你的团队在他们工作上一个明确的侧重点。它同时定义了所有重要的约束。团队工作需要制约因素。这些制约因素提供的“保护围栏”让你的团队务实落地同时井然有序。
问题陈述模型
问题陈述模型是由这三个元素组成的：
1.产品或者系统当前的目标
2 业务利益者希望解决的问题（即，目标没有满足的地方）
3 没有规定特别解决方案的明确需要改善的需求
模型
[我们的服务或者产品]是设计来完成[这些目标]的。我们发现产品或者服务没有达到[这些目标]，反而对我们的生意引起了[这个副作用]。我们如何来改善[服务或者产品]来让我们的用户在[这些可衡量的准则]上更成功呢？
比如，这里有一个我们在TheLadders（一个我工作的在线招聘公司）开始的项目上使用的问题陈述。（你会在这本书上看到更多的从TheLadders来的例子。）
我们的服务提供了一个在寻找工作的人和雇佣者之间的渠道。通过我们的服务，雇主可以通过提供就业机会，在我们的生态系统中找到求职者。我们发现一个影响用户满意度的关键因素是求职者对于雇主信息反应的频繁程度。当前，求职者对于这些沟通的回应处于一个很低的程度。我们如何才能提升我们沟通产品的效率，从而让雇主在他们的工作上更加成功，让求业者对我们的服务更加满意？
问题陈述充满了各种猜想。团队的工作是将问题陈述纳入到它的核心猜想中。你可以通过如下的业务猜想工作表来做这个。需要注意的是一些团队，尤其是那些从头开始的团队，可能没有一个明确的问题陈述。没事，你仍然可以尝试这个工作表。你只是要在一些问题上用更多的时间来达到共识。
——————————————————————————————————————————
业务猜想工作表
我喜欢用这个表格（由我的搭档Giff Constable创造的）来促成猜想讨论。这里有非常多的方式来完成这个工作表。你可以作为一个团队来回答问题，简单地讨论每一个回答。或者你可以通过一个系统的头脑风暴/分类地图练习来完成。然而当你执行的时候，你要记住给每一个人表现的机会是非常重要的。同时，不要担心如果你在到达结尾的时候，对于所有问题没有一个明确的意见统一。这个活动的目的是收集反映你和你的团队认为是正确的陈述。如果你对于某一点有强烈的不同意见，请抓住这个不同的视角。
猜想工作表
业务猜想
1 我相信我的用户需要_____。
2 这些需求可以通过_____解决。
3 我最初的用户是（或者将是）_____。
4 一个用户最想要从我们的服务中获得的价值是_____。
5 用户同样可以得到一些额外的价值如_____。
6 我会通过_____来获取我的主要的用户。
7 我会通过_____来挣钱。
8 在市场上我主要的竞争会是_____。
9 我们能打败他们的原因是_____。
10 我最大的产品危机是_____。
11 我们会通过_____来解决危机。
12 我们有哪些其他猜想，这些猜想如果被证明错误将会导致我们的业务或者项目失败？
用户猜想
1 谁是用户？
2 我们的产品是如何适用于他们的工作或者生活的？
3 我们的产品解决了什么问题？
4 我们的产品是在何时以及何种方式被使用的？
5 什么功能点是重要的？
6 我们的产品应该看起来或使用起来是什么样子的？
你会发现这里面一些问题并不适用于你们的项目。这没关系，你可以根据需要将这些问题按照你们的情况做调整。如果是处于产品的开始阶段，你可能花更多的时间在业务猜想上面。如果你已经有了一个成熟的产品，你可能会花精力在用户猜想上面。关键是要撒大网，从项目的各个维度寻找猜想。
如果你已经完成了这个工作表，你会得到一个猜想陈述的列表。下一步是对这些猜想排优先级。
——————————————————————————————————————————
猜想的优先级
我们之所以要在工作开始时阐明猜想，是因为它可以让我们识别出项目的风险。一旦你有了一系列的猜想，你要弄清楚哪些是最有风险的，因此你们的工作可以先从它们开始。
精益用户体验是一个无情的优先级划分活动。你要清楚你不可能测试每一个猜想，你如何决定先测哪一个？我倾向于做一个类似于下图（3-2）的图表，然后用它来制定猜想列表。
这样做的目的是对一系列的猜想进行优先级排序，以根据他们的风险等级（即，如果关于这个我们错了，情况会有多糟糕？）和对于这个问题我们有多少认知来进行测试。越高的风险和相关知识越缺乏也就意味着需要以越高的优先级来测试这些猜想。
这并不意味着没有在第一次被测试的猜想就永远不会被处理。将其他认知到的猜想做一个累积保存，这样在需要处理的时候就可以回来测试他们。
图表 3-2 优先矩阵
假设
通过你手头上的猜想优先级排序列表，你已经准备好进入下一个阶段了：测试你的猜想。要做这个，先把每个猜想陈述转换成一种更容易的形式去测试：一个假设陈述。
通常来说，假设陈述使用以下形式：
我们相信[这个陈述是正确的]
我们会知道我们是[正确的/错误的]当我们看到以下从市场上来的反馈：
[定性反馈]和/或者[定量反馈]和/或者[关键性能指标的变化]
你可以看到它包含两个部分。一个是对于你认为正确的假设所做的陈述，还有一个则是对于那些可以用来证明你是正确的市场反馈的陈述。
通过这样的方式来表达你的猜想将变成一种非常有力的技术。它从决策确定阶段中去除很多的主观性和政治性的对话，而将你的团队定位到市场的反馈中。它同样指引团队走到用户和使用者中去。
子假设：将假设分解成一些小的部分
有时你会发现假设太大了，以至于不能用一个测试来处理。它可能会包含太多的不确定成分，太多的子假设。当这个情况发生的时候，我发现将假设拆分成更小更具体的部分会很有帮助。虽然有很多方法可以去实现它，但对于产品工作，我发现以下这种形式非常有帮助：
[做这个工作/建立功能点/创造经验]
是为了让[这些人群/人物模型]
得到[这样的结果]。
当我们看到
[这个市场反馈，定量测试或者定性分析]
我们将会知道这是正确的。
第一个部分包含那些你正在考虑要为产品添加的功能点或者改进的地方。第二个部分精确地描述了你的哪部分目标用户会在这个功能点中获利。下一个部分谈及用户从功能点中获得的利益。最后的陈述将所有的这些都联系在一起。而这个陈述决定了你的假设是否正确。你会选择哪些市场反馈来表明你的想法是正确的？这个反馈可以是对于某一功能点的使用情况的定量测量，业务度量的增量或者是某些定性评估。
——————————————————————————————————————————
这并不意味着一切听数据的！值得注意的是在设计界中充满对于测量数据为导向的设计的反抗。他们的观点是当我们把所有的设计决策降低到可衡量的因素上时，我们也将快乐和灵魂带离了产品。事实上，我很同意这一观点，这也就是为何我认为在成功衡量标准中加入定性反馈非常重要。人们是否因为设计而快乐？他们是否会向朋友推荐你的产品？他们是否会在微博上谈论你的产品？当你寻找成功时，记住它不全用数据决定。
让我们通过一个例子来看看这一形式如何运作。我们将会再次看到之前提到过的TheLadders的问题陈述：
我们的服务提供了一个在寻找工作的人和雇佣者之间的渠道。通过我们的服务，雇主可以通过提供就业机会，在我们的生态系统中找到求职者。我们发现一个影响用户满意度的关键因素是求职者对于雇主信息反应的频繁程度。当前，求职者对于这些沟通的回应处于一个很低的程度。我们如何才能提升我们沟通产品的效率，从而让雇主在他们的工作上更加成功，让求业者对我们的服务更加满意？
我们在这个问题陈述中做出的一个假设就是招聘者将会使用新的渠道（TheLadders）来与求职者接洽。这并不是一个已经证明的事实，因而需要被测试。我们要如何为那个陈述来建立假设？让我们来拿出模板并填满它：
我们相信
在TheLadders的产品体验中创造一个有效的交流系统
是为了让招聘者和求职者
得到更高的接触成功率和产品满意度。
当我们看到求职者对于招聘者回应数量的增长以及招聘者在我们系统中发布信息数量的增长，我们将会知道这是正确的。
——————————————————————————————————————————
基准的重要性
请记住，如果你没有在写下你的假设前优先制定一个基准，那么你的一切度量都不再有意义。这个基准——你用于确定想法的成功性的度量的当前状态（比如当前数据）——需要在确保你的团队了解目标前就被找到。
完成你的假设陈述
为了建立你的假设陈述，请将这些“积木”堆积起来。把你想要创造的结果，想要服务的人物角色模型，以及一系列你认为在这个情景下会起到作用的功能点放到一起。一旦你获得这些原始素材，你就能把他们组织在一系列陈述中。让我们更进一步地了解一下这些元素。
结果
当你在创建一个用于测试的假设时，你会希望在特殊对待每一个想要取得的结果。我在之前说过精益用户体验更关注的是产出所导致的结果，而不是产出（文档，绘图，甚至是我们创造的产品或功能点）本身：我们更关注我们是否能让用户更容易的登陆站点？是否能鼓励更多人来注册？是否能在系统用户中创建更多的合作关系？
和你的团队一起去关注那些你尝试去解决的问题。你可能会想要取得一些高层次的结果（比如，提升注册量，提升使用量等等）。考虑一下，你要如何把这些等层次的结果分解为一些小部分。什么行为能预测出更高的使用量：更多到站点的访客？市场邮件更高的点击量？购物车中出现更多物品？有些时候，让团队来一个头脑风暴，去列出一张结果清单（这些结果放在一起，将会预测出你所追寻的大结果）将会很有帮助。
图3-3（下图）展现了一个来自于Giff Constable的例子，在这个例子中，执行领导团队进行了头脑风暴，并在之后票选了公司应该在未来追寻的关键性表现指标（KPI）。当把照片中的列表放在一起之后，每个执行者被给予了4颗M&M巧克力。成员们用巧克力为他们认为最重要的度量标准投票。关联性会被CEO打破。
图3-3。 KPI优先级投票
人物角色模型
设计师经常会建立人物角色模型来代表他们所建立的系统中的用户。如果你的团队已经有一些明确定义的人物角色模型，那么你在此时唯一需要考虑的事情就是在你的假设陈述中应该使用哪一个。如果你还没有人物角色模型，这一部分将会解释如何为精益用户体验过程建立人物角色模型。
角色原型
设计师一直以来都是终端用户的支持者。精益用户体验也是一样。当我们对于商业和我们想要取得的结果做出假设时，我们还需要保证用户是我们思考的核心。
我们大多数人都认为人物角色模型是一个表达我们从研究中习得信息的工具。我们通常把人物角色模型作为漫长，昂贵的研究的产出物。以这种方式来创建的人物角色模型存在一个问题，那就是它假设人物角色模型只能以这种方式构建，还有就是由于创建人物角色模型所需要做的工作而让人感觉如此构建的模型是无法触及的。
在精益用户体验中，我们会改变人物角色模型构建的操作流程。当我们用这一新方法来建立人物角色模型时，我们会从假设开始，并在之后利用研究来验证我们的假设。不再是花费数月来实地采访用户，我们会花几小时的时间来创建角色原型（proto-personas）。角色原型是我们对于谁在使用（或者将会使用）我们的产品及原因的最好的猜测。我们会让整个团队一起参与，在纸上描绘他们——我们希望能体现每个人的假设。之后，当我们从之后的研究中获得信息后，我们能很快找出我们一开始的猜测是否准确，找出我们是否需要去调整我们的目标受众（人物角色模型）——当然还有我们的设计。
使用角色原型
一个与我们合作的团队建立了一个为纽约市民提升社区支持农业（CSA ）体验的应用。CSA是一个让城市居民能够共同集资并从当地农民处购买整个季节的农产品的项目。之后，农民们每周向CSA的成员提供农作物。很多CSA的订购者处于20-30岁之间，他们需要在忙碌的工作生活，丰富的社交生活和参与CSA的愿景中做出平衡。
这个团队假设大多数CSA的消费者都是喜欢烹饪的女性。他们花了一个小时的时间建立了一个叫做Susan的人物角色模型。但是，当他们开始实地考察时，他们马上发现大多数的烹饪者及产品的潜在用户是年轻男性。于是他们回到了办公室，并重新制定了他们的人物角色模型，创建了Timothy。（下图3-4）
图3-4 角色原型例子
Timothy被证明是一个更准确的目标用户。团队不需要再浪费时间于错误的受众。现在他们能关注于一个虽然不完美，但相较最初的假设来说更准确的对象。
人物角色模型的模板
我们喜欢利用一个手绘的四象限纸来描绘角色原型，就像在图3-5和图3-6描绘的（你可以从把一张纸折成4部分开始）。左上角的象限包含对角色模型的粗略描绘，以及他的名字或者角色。右上角包含基本的人口统计学信息。在这里要关注于那些能预测某些特定的行为的人口统计学信息。例如，在某些事件中一个人物角色的年龄可能显得没有关联，但是他们对于类似iphone这样设备的接触却会完全改变他们和你的产品的交互方式。
图3-5 空白的任务角色模板
在角色原型的下半部分我们会放置核心的信息。左下角的象限包含用户对于现有产品或情景的需求和挫败感，产品尝试解决的痛点或者你的产品想要抓住的机会。右下角则包含对于这些需求的潜在解决方案。你可以使用右下角的相信来抓住功能点和解决问题的想法。
图3-6 完成后的人物角色模板
人物角色模型的建立过程
伴随着来自于假设陈述的一些其他元素，我们可以从一次头脑风暴来开始人物角色模型的建立。团队成员提供他们对于产品目标用户的意见，以及产品将如何影响潜在的产品用户。一旦完成了头脑风暴，团队应该筛选一部分的想法，去创立三或四个人物角色模型，来反应他们认为最可能成为目标用户的受众。请从需求和角色的维度来区分不同的人物角色模型，而不仅仅是依靠人口统计上的信息。
功能点
当你已经在脑子中构想了一系列的结果，并且专注于一群核心用户时，你就应该开始思考一下怎样的策略，功能点，产品和服务能够取得你想要获得的结果。通常来说，在这个阶段团队中的每一员都会表达出强有力的观点——毕竟，功能点是我们能处理的最具实体化的东西，因此功能点也是最容易让我们来表达想法的地方。虽然，我们的设计过程经常从某些人对于功能点的想法开始，而在最后尝试去验证这些功能点。但是在精益用户体验中，功能点的存在是为了服务于商业，顾客和用户的需求。
针对功能点的头脑风暴过程
和之前所描述的方法一样，我们习惯于通过一个团队参与的头脑风暴来创造一个功能点的列表。我们会寻找那些能将用户行为导向目标方向的功能点。让团队中的每个人，用记号笔在便利贴上写下每一个想法。然后，让每个人把自己的便利贴张贴到墙壁上，并让团队成员根据主题来对它们进行归类整理。
组合你的小假设
当你创造了所有这些原始资料，你也就准备好可以将这些材料转变为一系列可以测试的假设了。我们希望创建一个如图3-7的表格，然后用我们在头脑风暴中得到的材料来填满它。
当你写下你的假设时，请考虑一下你提出的解决方案在为哪一个人物角色模型服务。我们经常会发现一些解决方案不止服务一个人物角色。同样的，我们也会经常创造一些不仅仅带来一个结果的功能点。当你看到这样的事情发生时，请把一个假设分成两部分——我们希望每个假设陈述只对应一个结果。在整个过程中，有一件重要的事情一定要记住，那就是保证每个想法都有足够具体，从而你能创建一些有意义的测试来核实你的想法是否站得住脚。
图3-7 假设创建表格
当你的假设列表被完成时，你也就为下一阶段——设计——做好了准备。如果你和整个团队一起完成了这一过程（我强烈推荐你这么做），你们将能以一种更好的状态保持前进。这一过程能非常有效的在你的团队中创造一个共通的理解和共通的任务。
总结
在这一章中，我们探讨了如何通过结果来重组我们的工作，而这也正是精益用户体验非常重要的技能：通过结果来组织工作让我们（和我们的团队）从寻找最好的解决方案中解放出来，从而关注手头上存在的问题。我们同时也着眼于阐明结果的过程。为了完成这些事情，我们从项目的问题陈述开始，之后确认我们的猜想，并把猜想转换为假设。我们也展现了如何书写包含目标功能点，受众和目标的假设陈述，并让这些假设足够具体从而能被测试。在最后，你将得到一系列陈述，它们将作为地图来引导你的下一个精益用户体验进程：协同设计。
在下一章中，我们将定义什么是协同设计，并讲述它和传统产品设计的差别。我们会讨论到一些具体的工具和方法来帮助团队更好地共同设计，并说明协同设计如何成为假设核实过程的开端。
评论