发布产品并了解用户行为

发布产品并了解用户行为在项目初期，我们从习惯商业角度来理解设计问题，从而开始推动项目展开。然后我们去到产品实际使用场景中验证自己的想法，建立起产品最终用户的同理心。当我们具备了这些知识，用户体验过程看起来就是将想法手绘出来，大家一起头脑风暴来探索设计模式以及今后可能的发展方向。接下来，我们创建了交互原型，用以将思维模式可视化展现出来。在整个过程中，我们邀请用户帮助来调整、优化、更新设计流程和方法。当产品发布日期近在咫尺时，用户体验设计流程给了我们最好的保证——产品上线后，将以预期的方式去运作。在这一章中，我们要完成设计流程并揭开用户的使用习惯，这一目的是为了改变用户未来的行为。1.设计阶段用户体验过程中设计（和开发）阶段，如图1所示，所关注的是产品的全部设计细节。这是设计和开发中一个不断循环往复的过程，而最终结果就是你会亲眼看到产品完成并发布的那一刻的到来。图1.设计阶段：流程中的最后阶段这个阶段通常会很没意思，因为我们要重新审查产品的每个方面以确其保一致性，最终决定哪些部分保留，哪些要去掉，然后将所有数据重新打包准备上线发布。从与产品设计和开发相关的创意过程中获得的奖励是丰厚的，但也伴随着混乱、紧张、彻头彻尾地无奈。所以我想说的是干的漂亮——你几乎都做到了！发布花絮花一分钟想想你最近推出的产品。从头到尾的推出过程中，你最关注的重点是什么？哪个阶段耗尽你了计划的全部时间？下次，你会努力在什么不同的问题上集中主要精力？2.完成设计最终的产品基本上只是第一个版本。推动这样的结果发生的一切因素——例如遵循用户体验设计流程来进行设计探究和产品迭代，为了让用户简单便捷地抓握产品——都能让现在的你为自己曾经做出的选择而感到骄傲。当你到达这个阶段的时候，不要认为你的原型将解决系统或应用程序在实际使用过程中出现的每一个设计上的问题。通常来说，仍然需要一些轻微的（有时是主要的）变动和调整。如果你深刻了解你的用户，那么你可以决定用户是否会适应在该阶段设计上所做出的改变，或者它是否将导致用户不必要的认知混乱或不满情绪产生。连续的设计过程设计过程是连续的，从权重最高的设计问题入手；然后从原型中研究设计细节，让它演变成一种开发解决方案。尽管你已经与用户验证了设计的总体方向，但开发过程中依然不可避免地会遇到新问题，这就导致设计需要随着问题的出现而做出调整。这开始看起来像一个敏捷开发过程，设计原型逐渐成为开发过程的解决方案，不断调整，直至产品准备发布。你的意思是用户体验和敏捷开发可以和谐相处？关于用户体验哲学和敏捷开发是否兼容的辩论总是不绝于耳，而这经常将取决于你工作所处的情景或环境中。以我的经验来看，成功取决于围绕敏捷环境去构建用户体验的时间框架。这是无论企业环境大小与否都可以实施的敏捷方法。遵循用户体验设计过程为你创造产品提供了明确的目标和方向，产品交付的过程也反映了图形可视化的策略；例如，人物角色创建，竞品分析，使用情景图、交互设计、草图、线框和原型绘制。为了确保敏捷开发和用户体验设计的成功结合，用户体验设计过程在时间上要先于敏捷开发开始。图2显示了整个过程的主要步骤。项目始于对问题详细的研究和分析，然后是概念设计与敏捷开发同步进行的阶段。图2.用户体验和敏捷开发过程合并进行通常情况下，书中概述的迭代和概念设计周期的实践操作方式与敏捷开发类似。然而，很关键的问题是，你要确保有足够的时间去将完整的过程概念化显示，在开发前去和你的用户验证和确认。杜绝开发过程远离用户这种现象，这常常是敏捷开发中优先考虑的问题。你也应该时刻牢记的是，在整个敏捷开过程中也需要用户参与进来。在我所见过的众多设计过程中，尽管有些团队无法将产品回归到用户中去验证后期的迭代版本，但这样做是的确是很关键的。正如上一章中的建议一样，确保每一个人——包括开发人员——都同意你的用户参与到整个设计过程中，这样就可以提前制定好计划，而不是后期再去重新组织用户参与。见怪不怪的合伙人你在敏捷开发和用户体验过程方面有何经历？这在你的项目中起作用了吗？你的经验是什么？你现在和之前做的事有什么不同？调整设计当你即将完成最终设计的时候，记住，你仍然处在一个消除和简化过程中。完美的产品是由许许多多精益求精的小细节组成的，所以在没有必要的地方，一定要抵制“增加价值（功能）”的诱惑。当你准备启动产品开发流程的时候，设计和开发都应该朝着统一、简化和放大这几个目标去努力。这意味着将你设计的所有方面聚合在一起在不失去既定目标的前提下）尽可能去简化他们，然后放大设计的关键方面，这也是你的产品吸引用户的地方。这个过程让用户对你的产品理解更加升入，同时也强化了你希望看到他们使用产品时的行为反应。通过测试来帮助你调整设计在产品发布前，邀请一小群人参加一个私人测试真的很有用。公开测试是用户验收测试（UAT）的其中一种形式，是将产品的试用版（主要是产品试验版本）发布给核心团队外的用户去使用。试水用户验收测试包括在项目的最后阶段的测试，以确保产品的执行所需的最低商业需求。通常，一个产品必须完全通过测试，客户才会考虑最终签订合同。正如任何最终的网站内容编辑一样，敏锐的双目可以帮助你发现对你来说其实不明显的缺陷。测试组试用你的产品，在漫长的时间里帮助改进你的设计，并对产品进行技术测试。在选择测试组时，选择不同领域的专家来帮助你识别和优化提升具体某个领域内的问题，这样你可以利用他们在该领域的专业想法来改善设计。我们发现Bug测试和边缘情况试用对于产品开发人员来说特别有用。招募一些产品的常用用户的或目标用户，来了解一般用户是如何看待你的产品的。如果你一直在努力着眼于对现有产品的优化改进，寻找哪些过去曾给予过深刻思考并提出建设性意见的用户进行测试；甚至去询问那些充满使用热情的用户也可以。邀请的用户人数应该是你认为的所需人数的两倍。因为可能有一半以上的人最终无法参加，或者很难有充裕的时间完成访谈，所以你需要确保自己有足够的人员储备。如果你能负担得起的话，可以考虑使用现金激励，让用户的注意力能够维持地更久一点。经常与他们在网上或私下里聊天，保持他们的参与感；人们起初会畅所欲言，但一个较长的测试周期内，有时他们的注意力会不集中。相比之下，获得与设计功能和可用性相关的反馈意见比获得用户纵向习惯反馈的细节要多很多。（纵向研究涉及在较长的一段时间对同一变量的观察。）从测试组中获得的信息能够帮助改进产品的初次使用情况。测试组将帮助你完善用户使用产品的初步体验，所以要去探究他们的初次印象并收集改善建议。测试组主要是寻求对产品微细节的反馈。他们注意到你计划中会出现的“哇哦”的时刻了么？反之他们又对你的哪些设计感到懊恼？确保你真的采纳了用户反馈的内容！如果你没有时间去解决这些问题，那么收集很多好的想法就完全没有意义了，因此你需要建立一个优先级列表，通过系统的工作去改善表上的每一条内容。测试可以帮助你对设计进行微调，纠正任何末期遗留的开发和系统问题，收集整个产品模型的使用反馈，调整设计细节。解决高权重功能随着设计流程的推进，需要关注的设计细节会越来越多，此时想要拥有的特性和功能的堆积成为你了关注的焦点。对于设计中不同的功能的最佳顺序如何排序，要努力去做出决策。测试可以帮助你确定这个功能对现有产品是否会带来冲击，团队成员或产品拥有者是否可能对那些特征情有独钟。你可能会将一些特征推迟到以后的版本中再发布。这些都是精美的印刷品用户体验文档将一系列最佳界面设计实践整理成一份参考文档。对于数字产品来说，它通常包括总体结构和用户导航方式。突出强调期望的可用性标准，表明了对产品易用性持续关注的认同和支持。产品数字文档也会覆盖更多的具体内容，如语言风格、企业风采或品牌特征，视觉规范（颜色，标志，字体，图标页面或屏幕布局（间距，对齐，使用诸如下拉菜单，按钮和复选框等界面控件）。有时你的草图存档将帮助团队理解设计中融入的设计理念。这可以免去他们为了一个早已行不通的道路去找更多废弃的理由（而浪费时间）。考虑将你的原始草图按时间顺序归档，或把你的草图照片及与项目相关的内容都放在移动硬盘中，这样一来他们就可以很容易地用来作为参考使用。在概念设计阶段，无论你设计了什么，当你想要向他人传达你的设计意图时，正确的引导和规范的格式能够让对方很容易理解；例如设计原型或交互文档。不要害怕进行团队走查，这能够让你看到什么事他们最看重的功能特征。如果你不参与开发过程，只是负责为令一个团队创建文档的话，在项目早期需要明确这个文档是给谁使用的，这样你可以按照使用对象的需求来调整它。什么时候输出设计文档，要输出多少？当产品细节设计完成后，就到了将设计整理成文档的时候。然而，如果是遵循敏捷开发方法，文档往往是要减少或避免出现的。这是因为用户研究已经纳入了产品开发过程中。详细的设计文档可以作为教育帮助工具，解释界面设计的概念和方法，确保在设计初期到未来更新迭代版本中基本可用性功能的留存。文档数量的多少在很大程度上取决于你的工作方法。例如，你独自一人单干还是和团队协同工作？你会设计开发你自己的解决方案吗？你一直在以第三方身份与客户接触吗？在你需要与另外一个人，业务组织或公司交接的时候，这些问题的答案会影响到你最终提供的文档数量。创建足够多的文档来传达设计的意义和交互意图。一般来说，那些将要使用你的设计文档的主要是一些专家，包括系统架构师，开发人员，业务分析师，营销专家，或从事质量保证工作的人员，依据项目的阶段不同人员也会有所差异。我发现在用户体验文档中最有用的内容包括：1.你创建的作为设计过程一部分的原型：鲜活的、栩栩如生的案例来表明你的设计意图2.一份包含设计模型中每个页面和细节的交互设计文档原型就是指路明灯你绘制的作为迭代过程一部分的原型，对于最终产品的创建来说，是一份很好的路线图。理想情况下，你通过合作的方式来制定设计决策，从而去帮助开发团队完成工作，如在一个敏捷开发团队中——让每个成员头脑中都时刻清醒认识到，用户是谁，什么样的产品对他们最有用。如果你无法当面讲清楚的话，你的原型会成为是一个十分有用的参考文档，因为他们显示了关键页面的交互设计模型背后的意图和理念究竟是什么。确保你更新后的原型是基于最后一轮用户测试结果而来的，原型代表了验证后设计的最新版本。考虑到要创建一个“请阅读我”文档，因此需要将其创建的关键使用场景，以及可点击的区域进行详细描述。交互指南交互指南和原型的结合，帮助指导开发人员和设计师在你不在场情况下，也能继续在产品创建过程中做出合理的决定。交互指南是高度可视化的文档，描述了设计中足够多细节，足以让另一个专家理解并按要求执行，如图3所示。他们应该有足够的注释，让人能够理解，并对某些方面为什么以这种特定的方式设计有一个清晰的认识。图3.交互指南帮助其他人去理解你的设计这里有一些小的建议可以帮助你创建高效的交互指南：特别注意文档的信息内容，例如步骤序列、基本模板、链接或控件，商业规则或其他方面的限制，以及标准设计元素（如图表，标注和错误信息）。任何与文档相关的参考资料；这可能包括尚未解决的问题或一般的笔记和评论。创建计划保证在你不在场的情况其他人也能按照指南行事；这将更好地应对那些可能要求更改或延长文档内设定的结束时间的情况。考虑你创建的文档选择什么样的版式。为什么不把它放到网上？你甚至可以考虑将工作原型和交互指南合并为一个模型，在上下文中展示设计规则和指导方针。慷慨地分享！如果你不与人分享，那么你创建文档就一点意义都没有了。让他人与你建立共同理解并支持你的设计方向，以及意识到你所采取的是何种方法。如何记录？在项目结束时，你将创建哪些内容作为最终文档的一部分并移交给客户或团队？对你来说，在过去的工作中哪方面表现得最好，为什么？最终检查和制衡在发布前检查你的产品，就像进行最后的编辑一样；因此，有条不紊地回顾产品的各方面是至关重要的。特别是，在考虑到整个产品的一致性问题上。网上有很多检核表格式资源可以提供帮助，我不想去描述详尽的使用细节，而是强调一些关键点帮助你开个好头。视觉设计元素图像资源是需要精心呈现的。确保你对整个产品一致性进行了检查，并对品牌和整体营销信息做最后的检查。仔细阅读每一页文档，检查内容的一致性。确保没有拼写错误，标题描述明确，任何测试内容都已被删除。导航和信息架构检查链接是否是一致，容易识别的，保证产品贯穿一个清晰逻辑顺序和任务流。验证标签和分组信息有助于你的用户定位网站的核心内容。技术测试在产品发布前执行最终的技术测试（例如系统测试，集成测试，回归测试和负载测试）和产品的用户验收测试，保证用户初次使用的时候，没有令人讨厌的“惊喜”出现。编码标准和可访问性确认产品满足了期望标准或（由你的客户和行业内的）设定的产品规范的需求。营销与推广考虑一项启动计划，就是当产品发布后，会发生什么事情，几周以后又会发生什么。你一定要经常与组内人员沟通交流保证工作顺利进行——因为你只有一次让用户感到惊艳的机会。（剩下的就是需要不断地更新迭代去优化产品。）输入和输出评估你的设计还有哪些功能需求没有解决。输出一份产品功能内容留存和更新的时间列表；如果列表是分布式的，要确保你知道是谁在做这件事情。发布列表？也检查一下吧如果你已经这么做了，我会鼓励你创建自己的产品发布清单，这样有助于你跟进每个项目。每个项目结束或更新升级后，基于你自己定期的了解，去构建一个列表记录在过去的工作中哪些方面你做的最好，（作为自我提升的经验。）现在，你的产品应该已经达成了一些目标，所以在发布前的最后一次验证着实是一个伟大的时刻。从头至尾遵循用户体验过程，能够保证你的产品会得到用户的好评，但发布前的测试可以发掘之前未被检测出的问题，而这时整个产品可能已经作为一个完整的功能单元被组装完毕。直至发布的最后一分钟依旧需要复查任何小的细节，不对产品的整体意图妥协，这是一种很棒方法，对用户也十分有意义。你是如何看待你的产品的？到了产品发布的最后几周或几天时，其中一个最大的准备指标是你的幸福感。你的幸福雷达是一片主观的灰色区域，但一直以来你所采取的方法应该给你的设计发布准备带来信心。这里是一些自省的小问题：你对自己的设计感到高兴吗？有没有统一，简化和放大产品的核心内容和功能特征？产品时如预期那样简单么？如你希望的“哇哦”的时刻——他们很突出吗？（如果之前有旧版本它是否较之有显着的优化提升？你已经做了足够的努力保证产品会在充斥着同类产品的拥挤的市场中脱颖而出吗？当产品在市场中突出重围后，过几天重新审视自己产品，你感觉又是如何？幸福的时刻反思一下，在你完成设计工作，并推动产品最终完成和发布这一过程中，你所寻求的是什么。哪些迹象让你感受到设计带给自己的幸福感？3.发现改变行为的习惯设计改变行为：这就是事实。在这本书中，我强调理解用户行为对于确保用户能够依照你希望的产品使用方式去使用来说是很重要的；但是，如果连你自己都不理解用户习惯，你又如何才能改变他们的行为？习惯，当然，并不是非黑即白的。他们往往是强烈或者微弱的。你越是不由自主地去做某些行为，习惯就越会被强化。如果你想了解如何与你的产品会影响用户的行为，那么请记住，你需要在设计前，设计中和产品发布后都要考虑用户习惯。在2章中，我鼓励你去探索和发掘用户行为，用户的行为目标。然后再回顾一下你最初设定的行为目标。了解用户行为到目前为止，你在这件事上所做的一切已经让产品初具雏形了，现在来看看它与目标用户是否会产生共鸣。你的耳边可能充斥着许多流行语，但基本上都是用一个新的方式来解释为什么我们要遵循用户体验过程的某些方面（想想精益生产，精益用户体验，敏捷开发，游击，MVP，等等）。我会避免去解释这些想法，因为我相信用来描述的我们所做的这些事的术语总是会因为新问题的出现而转变。最重要的是，当我们开发产品的时候，我们正在了解潜在用户的行为，并利用这些信息和洞察结果来塑造我们的设计方法。这最终帮助我们来决定哪些功能将是最重要的。发布前的假设那么在产品发布后，你应该去了解一些什么事情呢？产品发布前，你需要考虑一些因素。一定要密切关注这些因素，因为一旦产品发布了，你能看到在很长一段时间内它取得成功的过程。这些措施包括：内在价值尝试快速确定用户更看重产品的哪些方面。可能的障碍什么因素限制了用户对产品不同功能的理解和使用？适者生存你能够拥对抗自己的竞争对手吗？你能为用户提供超出竞争对手产品足够多的价值，以实现产品的差异化并防止被山寨吗？用户习惯哪些因素会让用户爱上你的产品，甚至用上瘾呢？他们会用了一遍又一遍，并邀请和鼓励其他人做同样的事吗？可扩展性和成长有足够多的会发现产品价值的用户存在，使得用户群随着时间的推移而扩大么？产品可行性你能够将受欢迎程度不断增长的产品转变成为一个可行的和可持续的收入来源吗？你会如何解读这些数据？你可以坚定不移地专注于你的用户行为，一旦产品推出投放到市场中后，你可以采取一系列措施来变更你的设计。然后基于对围绕产品本身的用户使用习惯的明确了解，你可以将用户的行为扭转到你希望的方向上。阅读如图4中的信息图能否帮助你理解用户行为？图4版本发布前后的测量行为对于产品是如何被用户接受的有一个快速的了解，将有助于整个产品战略的塑造，影响未来的版本的特征和功能。习惯由什么组成？当你回想过去20年中的一些伟大的技术解决方案时，他们许多都有一个共同点：他们创造了一种习惯。当技术创造了人的一种习惯时，人们自动就会去使用该产品，而无需再去纠结是否应该使用。拥有社会属性的技术在用户习惯养成的赌局中明显的是一位赢家。Facebook，Pinterest和Twitter的用户一天中都会多次访问网站，看看别人都说了些什么，发了哪些帖子或喜欢了内容——有时甚至一个小时内要看好几次。习惯养成额外的游戏规则就是移动设备使用的爆发式增长。即使是传统的非习惯形成的网站，其本质上也更多地偏向于事务处理方面，当它出现在移动手机上时，也能够促成习惯的形成（例如，移动银行）。想想看，智能手机已经改变了我们与企业的交互方式，如图5所示。图5.智能手机：改变了我们处理事务的方式每天使用的产品，在市场中为防止竞争对手的踏入创建了一个壁垒。如果你的用户无法想象没有你的产品的生活将会是什么样子，那么你可以说你已经达到目标了。习惯到底是如何养成的呢？在没有做出清醒决定的时候，你做的事情越多，习惯就越会被强化。使用频率导致用户群体中习惯的养成；如果用户经常回来使用你的产品，很有可能是习惯已经形成。请考虑图6中的场景。图6.你能想象生活里没有手机的情形吗？养成习惯在我们讨论如何衡量你的用户的习惯之前，产品发布后，你认为你会解决这个问题吗？你有没有考虑过这个问题？如果答案是肯定的，你在过去做了什么？什么起作用了，什么又没起作用？如何去评估习惯？评估设计在创造习惯方面的有效性，可以分解为几个任务，有些是产品发布前完成的，有些是在之后完成的。在产品发布前·定义一个习惯性用户他们有没有经常使用的网站？他们都是做什么的？他们在网站驻留多久？访问频率如何？在产品发布前，这些问题会帮助你罗列出你所预期的内容。如果产品已经存在，这件事做起来就更容易了，但是至少试着去估计一下你所期待或希望的是什么。一天，一周，或者一个月内，你认为产品真实的使用次数有多少？为产品使用频率设定一个清晰的期望值，但是要现实一些。每个人都希望用户每天，甚至每小时都用自己的产品——但是几乎没有产品能做到这一点。产品的使用情景有助于引导你设定合理期望值。·亲自去使用产品请记录你自己的产品使用频率。在理想的使用情景下，日常的平均使用次数是多少；据此来调整期望值。记住，我们的重点关注的是用户的行为，以及你提供的哪些类型的服务导致用户习惯的变化。专注于个人用户以及他们行为，并评估其是否养成了使用该产品的习惯。全体用户中活跃用户所占比率是不可预测的；这是就他们实际上正在做的事情，也是应该重点考虑的问题。在产品发布之后产品发布后，你需要开始收集和分析与用户习惯有关的各种数据。间隔一段时间，测量有多少用户真正满足你设置的基准线定义，然后在发布后的不同的时间段内都去测量（每个月，每一季度，每六个月）一次。·谁将其弃之不顾，为什么会这样了解谁会使用你的产品，谁又会弃之于不顾。试着用用户体验的方法去揭示其内在原因。查看用户数据和模式，然后看你有多少用户真正满足你最初设定的期望值。如果没有人按照你预期的方式在使用产品，那么去观察用户群体，看他们在做什么，随着时间的推移其行为又有变化（监测工具可以考虑使用下列几个，包括Flurry,Localytics,GoogleAnalytics,ClickTales等等然后再去做决定。测量用户行为是一个纵向工作，因为你没有办法让时间加速。最好的结果是长期测量，在这期间任何个事情都会改变——所以要一直保持住。这也是一个缓慢的开端。没有神奇的百分比数据可以评估你的产品是否创造了一种用户习惯。实际用户行为模式是最可能的是对最终习惯的预期。通过产品来检测用户的操作行为，与他们保持联系（例如进行访谈和评估），并继续观察和深入了解用户行为。进化，而不是革新迭代作为一种学习方法，即使在产品发布后依旧要继续下去，并通过大量的反映产品实际使用情况的用户数据来支持（或反驳）后续工作。你需要吸收这些知识并继续优化你的设计，但是请记住，在这阶段你要做的是进化而不是革新。你不必从根本上改变你的设计方法，而是基于你对用户的需求和习惯全新的认识水平来调整和完善设计，如图7所示。图7.继续深入了解和迭代更新观察产品的早期使用者观察产品的早期采用设计方案将允许你确定对于用户来说产品的真正价值在哪里，帮助你以一种全新的或意想不到的方法来塑造产品。Twitter的创始人EvanWilliams，曾做过一次伟大的TED演讲，揭示了如何观察产品的早期使用者来帮助自己发现产品的隐藏价值，这在创新过程中是难以想象的。在这次演讲中，他讲述说Twitter创建的初衷是一个广播媒体。是用户现在的这种使用方式才促进了他的演化；例如，@这种处理方式的使用就来自用户想呼喊他们认识的人加入到吸引人的讨论当中发展而来的；它并不是最初设计的一部分。同样，用于寻找项目等内容的井号标签[#]在最初设计时也没有使用，而是由第三方供应商创建的，随着服务的增长和发展，将其作为一种搜寻内容的方法。Twitter购买了这种服务，井号并成为所有帖子间定位内容的一种十分宝贵的方式。习惯性的用户是什么样的？一旦产品已经发布，你需要确定用户行为，从所有用户中区分出习惯性用户，并试图找出引爆点，把普通用户转化成习惯用户。这将超出统计数据能揭示的答案，这一点对你后续接触用户揭开“为什么”的原因十分有帮助。你走出去观察用户之前，检查你的数据，制定一个与他们的使用有关的假设，也可以假设他们为什么会采取某种途径，而其他用