案例研究：烹饪食谱应用程序

我们已经到达了用户体验流程的最后一部分，现在让我们看一个开发食谱应用程序的案例研究。

游戏名称

应用程序背后最初的想法是创建一个数字版本的珍贵的家庭食谱剪贴簿，用来维护家庭的历史和传统。这就促成了这个名字的出现——家庭的最爱，就像在图9中的线框图所示——这个名字我们是用了很长一段时间。

图9. 私人化，但缺少的标志性内容

在我们的用户体验过程中，情景研究和用户交互是突出的两个关键环节。他们分别是：

美食客

未婚或无子女的已婚人士;热衷于分享，准备以及饱含对所有美食的爱!乐意花很多钱去购买原料和食材，感觉没有什么比周末与朋友在一起聚会烹饪更美好的事了

居家主厨

育有子女的已婚人士;曾经住过的尽享美食的生活，但现在的重点在家庭上，他们对食物热爱因日常生活的忙碌和杂乱而被搁置一旁;快节奏和单调是每天的主旋律

在概念和设计阶段研究发现，美食客感觉这款应该程序的名字将他们这群人排除在外了。因此，我们不得不重新考虑新的名字，来吸引更多的受众群体。

我们希望这个名字能够代表我们的应用程序为用户提供的功能。应用程序的主要目的是促进珍贵食谱的创建和存储，从而使你能够与朋友共享美味。

最终，我们把关注的重点集中在两种选择上：大厨和菜谱互换。我们当初定下大厨这一名称的想法是，如果交换功能将成为应用主要的卖点话，我们能够未雨绸缪。但我们发现一旦应用程序在野外使用的话，这个功能就没什么用了，所以这个名字可能会限制应用程序的长期使用。

我们也希望这个名字反映去创造菜谱并分享、使用它们这一本质。大厨更加包罗万象，涵盖与烹饪相关的一切。所以，就定大厨这个名字了。

命名惯例

你有没有给产品命过名呢?你经历了什么样的过程?

你是如何做最后选择的?

在哪里开始和结束?

在食谱应用项目的初期，我们拟定的目标是6周内完成最终产品。

项目开始后，进行到了前期调研和概念阶段时期，这时，我们开始进一步考虑——像我们以前很多时候做的那样——我们创造的是什么，我们需要提供哪些特点和功能。

不再重点关注任意时间框架，而是把注意力集中到得到应用程序合理使用的细节上。对于应用必须具备的核心功能的交互方式探索，令我们获得了一个新的挑战，就是如何实现产品增值。如此看来，这又要花多长时间才能切实做到最终产品定型呢。

我们初步设定的时间在逐渐增加，从我们所认为的快速启动——6周——增加到了一个更长的20周的产品开发周期。

设计过程回顾

应用除了有创建和管理用户最喜爱的食谱的功能外，更主要的特点是其社交属性。大厨允许用户邀请朋友来访问他们的内容，他们可以查看好友的食谱并将其添加到自己的食谱中，而且最重要的是，用户间能够评论彼此的食谱。

增加社交功能可能我们在概念创建和设计阶段需要解决的最大的挑战。优雅地处理通知和评论的任务比之前更加艰巨，主要是因为应用程序设计的前提是围绕着菜谱展开的;逻辑上没有真正的中心区域去处理一条消息评论或者内容更新消息。图10显示了现有的设计中定位消息内容的限制。

图10 给大厨设定限制网格

我们试图将评论放在工作台顶端，然后研究了菜谱中“活动”的各种消息类型。我们最终决定将更新列表放在在个人菜谱的前面(前几页)，出现在他们翻阅到食谱内容之前。当用户翻阅菜谱的时候，会有一个清晰的活动消息，甚至在进入应用后，活动消息依旧可见，如图11中的设计所示。

图11.处理消息和社交元素

为了当用户进入应用时，通知能够起到警告作用，我们将工作台顶部线性排列的菜谱改成了堆栈的方式。用户进入后，堆栈内容可以在页面顶部扩展开来，优雅地将上一次登录至今的活动消息合并显示出来。

通知展开后，用户可以在他朋友们的菜谱之间切换，看看有什么新内容。这些菜谱可以切换显示那些已经更新的内容，或者用户可以从A到Z的顺序浏览他们的菜谱列表。有新的内容的书籍以照片形式标示出来，如图12所示。

图12 你收到了……新消息!

每当我们遇到艰巨的设计问题要解决的时候，我们不得不提醒自己，这一切都是以“用户的菜谱”为主的，并恢复到无论我们感觉最好的解决方案是什么，这种隐喻一定要保存下来的认知状态。

当进入开发阶段时，困扰我们的一个微细节就是，就是用户和朋友之间菜谱的切换方式。我们希望这个手势操作成为一个重要的交互方式。

当用户从当前菜谱切换到另一本时，会有一个明显的受阻的感受;同时，我们希望工作台顶部转换操作时，有一种非常轻微反方向的回弹动效，营造一种视觉上的动感。这会是一个“哇哦”时刻吗?我们是这么认为的。

这些操作需要自定义代码，而我们的开发人员花了几周的时间来完善这一做法——但他们搞定了。那是多么幸福的一天!

随着设计细节的深入，我们开始重新考虑如何去管理“好友”。不像其他应用那样使用浮层遮盖或单独设置一个区域显示，我们决定选择一个在工作台上放置一个地址簿，可以提示用户关注新用户——或者邀请新用户。这种设计意味着我们可能会推荐一些有名的厨师或餐厅/咖啡厅让用户去“关注”，强化预期用户行为的发生。

从行为设计的角度来看，这也意味着菜谱里的活动会吸引用户不断去查看，厨师可能会比一般的用户更频繁地上传的食谱;毕竟，我们需要一个理由来让用户不断回访查看来帮助创造一种习惯。图13显示了我们在工作台上的地址簿。

图13. 好的地址簿以及关注的厨师

我们觉得应该设计一种好的方法来保留这个关注和邀请优先推荐新用户的想法;不是隐藏联系区域，而是将其展露出来——为胜利而设计!很突然地，我们对开发人员说，我们希望用户在当前好友菜谱的列表和地址簿之间的相互切换过程具有同样的操作权重。

额…问题来了。

我们的开发人员花了三周时间试图创建自定义代码来解决这问题(但是失败了)，随后建议我们尝试一些代码写起来更容易的设计方案。

这并不是唯一迫使我们重新审视最终设计的问题，但它体现了连续的设计和开发过程，这是用户体验设计过程的最后阶段的典型特征。

用户体验和敏捷开发…是的!起作用了

正如我们在本章前面所提到的，有很多的争论是围绕着是否敏捷开发和用户体验设计能否协同工作展开的;该项目使用了这两种方法并且现在看来结果很成功。

想要得到成功的输出成果，有几点需要考虑，他们是：

团队构成

我们有设计师，开发人员，用户体验设计师和研究人员，整个项目过程中我们都在同一个房间里工作。这是必要的，因为不同的技能所承担的问题不同。

研究和洞察先机

情境研究推进了我们的设计进程，调研结果被引入概念设计阶段。概念设计阶段我们了创建原型，从可点击或有热点的交互线框图绘制，直接跳转到代码开发阶段(开始编码然后精炼我们的进展)。设计和开发的探索对我们来说是并行发生的，这种效果很好，因为从设计角度出发，自定义动画往往意味在什么能做到和什么做不到之间往复循环。

并行研究

我们用户体验研究和用户参活动与设计和开发进程是并行展开的;这意味着用户反馈收集结果会反复不断地输送进设计和开发进程中。

我们的研究意味着对产品功能特征和优先级等这些重点问题的沟通发生在了设计和开发的前面，然后在整个开发过程可以不断提醒自己该如何做，从而避免问题积压现象发生。

当我们的概念设计原型演变为开发的解决方案时，每个决定都受到最初想法在技术上是否可行的现实的影响。当两件事情前后发生时，必要时我们需要改变方法，不要在类似事情上浪费太多的时间。

总的来说，这两个设计和技术可以相处地很好;但是，我觉得这取决于你的团队构成。我们的团队是主要的用户体验设计师和研究人员，这意味着在设计阶段忽略用户是不可能的事情。

聚焦“哇哦”时刻

用户将在厨房做饭时使用我们的应用程序，我们在前期研究和随后的分析过程中对功能做了一些扩展延伸，以优化应用的功能实用性，同时也展现其在发展理念上的独特性。我们研究分两点：

用户使用的设备必须保持解锁状态才能阅读内容(不知道是否有解锁设置可以用来防止此类事情发生)。

做饭时那些用户会担心沾满食材的双手会弄脏设备(例如，用他们干净一点的指关节去小心翼翼的翻页)。

我们要确保设计克服了这些情况，所以技术开发研究过程接踵而至。第一个无意的锁屏问题很容易解决。

另一种情况需要手势研究介入，目的是找到用户可以刷手掌或移动自己的手臂等交互式手势而无需去触摸他们的设备。

这两点都不是和设计直接相关的;然而，对我们的开发人员有利的是，当我们继续为应用的其他细节设计时，开发人员可以继续研究这种手势操作如何能实现。

我们觉得当用户使用大厨时，这个菜谱间的手势翻页或滚动行为会成为那些让用户“哇哦”惊叫的微细节之一。

应用测试

在我们基于用户的测试周期的迭代完成后，我们将邀请我们的测试组测试，以便我们能在较长的一段时间内获得应用程序的详细反馈。

这一步我们基本上用了两种方法，下面我会为你详细介绍一下：

第一组是专家组用户(开发人员，设计师，同行和朋友)。这些用户与设计接触了一个月的时间，这样他们可以给我们提供反馈信息，帮助我们确定哪些元素需要更多关注。测试过程中提供协助的开发人员进行一些通用功能和错误测试，也包括一些边缘情况的测试。

另一个是研究用户组(从我们的研究和迭代测试过程中抽取的两个用户)。在测试进行的同时，我们给每个用户一台iPad也来测试应用程序。这使我们能够看到一些普通用户对应用的热爱或憎恨程度，并帮助我们对这些改进点进行优先级排序，然后进行最后的设计调整。

测试过程如何?有哪些好处?

使用两个测试组的效果非常好，我建议你也试试。这个过程我们遵循了以下几点：

两组测试者起初都充满激情，渴望测试开始。我们建立了两个不同的Yammer小组，这样就可以进行一对一的在线聊天或小组间的讨论。我们觉得他们的话题应该不同，所以两组讨论的重点不一样。

正如本章前面所描述的，专家组的注意力和聚焦集中度在整个过程中降低了，而用户组则不同——这段时间我们向他们支付现金奖励。这帮助我们保持用户的参与度，并意味着在延长的时间框架下他们更能严肃对待眼前的任务。

至少，每一组每周都会提出一个关键问题。这里面也有一些其它形式的日常接触，因为我们在设计和编码过程中的一些问题，通常需要和测试组进行确认。

每两周一次的测试过程中会与用户进行两次行为访谈。这让我们能就用户的体验以及他们普遍认为的一些想法进行面对面的讨论。

这些访谈都很像探索性用户测试。我们可以通过应用程序来观察用户，以及他们对一些设计特征和设计要素的使用方式，以此了解他们为什么这么认为或感觉。访谈中所看所听的内容，为产品改进和更提供了一些很棒的想法。

访谈过程有点像日记研究——但使用的是真正的应用程序。用户的看法有助于应用的完善和调整，优化设计方案;这一进展甚至超出了正式的用户测试迭代过程结束时的成果。

专家研究小组：团队!

当可操作的原型完成的时候，团队成员第一时间就将其下载到了自己的iPad上亲身体验试用。

每一次新的开发更新版本都会从开发人员那里发送到团队每个人手里，使用整体的方法改进设计，并让每个人都参与到这一过程中。

这使我们能专注于不同步骤序列和设计功能的改进和完善。反过来，我们也能够评估什么会给应用程序带来“哇哦”的时刻，有一些是真正的“哇哦”的时刻，有一些仍然需要继续设计开发。它也帮助我们在官方正式发布前想象一下可能形成的用户习惯会是怎样的。

什么文档才有用?

应用的设计和原型形成了各自的文件。考虑到整个团队的规模，没有必要制作正式文档。然而，我们过去这样做是为了留下经验指导，因此我们的文档风格、交互和其它设计内容都必须有一个明确的参考，并为项目中所有新加入和已经退出的设计师提供官方的共享内容。

当我们把过去某一阶段的原型重新提出来时，原型本身就变成了一种工作模式，这也意味着代码开发的最终敲定也需要同时进行。

因为我们的团队规模很小，大家天天在一起，所以几乎没必要为了将整体意图传达给新加入或者缺席成员而专门去开会沟通。

应用程序的发布许可

应用发布最后的障碍是提交给苹果应用商店后等待批准。如今，这个过程通常需要七到十天，但也可能需要更长的时间。

在过去的几个月里，我们收到了来自苹果官方的反馈建议，然后我们调整和完善了设计;这意味着苹果官方现在对我们这款应用程序的整体概念已经很熟悉了。

获得苹果商店的批准后，应用程序就可以自动发布，或等待我们提出的发布日期再发布。我们的目标是制作一些特别的东西让我们的产品在应用商店中脱颖而出。让产品拥有更多的曝光量，这对我们的应用来说是一个良好的开端。

应用程序总体体验概览

从一开始，我们就试图为我们的应用设想一个更广泛的用户体验，而不仅仅只是一个iPad应用程序。

我们相信应用程序应该是具有吸引力的，为用户创建一种习惯，因此我们需要确保以下几方面：简单，社交和鼓励用户习惯。我们的应用在简单化和社交方面都有涉及，但是鼓励用户习惯形成是很难的。什么才能让用户立即想到上传一个食谱到我们的应用上，并花费时间去做这些呢?这与他们目前的做法冲突吗?

这个应用是能够长久保存个人专有食谱的数字商店。对原始菜谱的拍照上传的功能，或快速创建一个菜谱合集，将是应用的关键所在。然而，我们认为与线下世界联系起来才能真正驱动和鼓励用户的使用行为。

我们想要确定应用的一个功能就是预订和购买菜谱，并作为副本复制下来，以便用户可以发送给家人和朋友，或只是自己留存。

人们喜爱书的有形性，而且翻书浏览的触觉对于找灵感来说感觉很棒。产品发布后，我们需要等待和观察用户是如何使用产品的，并计划发布一个预告片，告诉用户如果存储了足够的菜谱后，他们可以做些什么，并鼓励他们利用应用做一些充满创意的事情。

书籍打印研究

目前，我们正在研究打印操作选项和不同设计风格的菜谱。这就意味着，只要用户选择该选项，这本实体的菜谱将拥有一个与应用中原布局和设计类似但略有不同的外观。我们要确保用户收到他们的这本菜谱后，不同的视觉外观能够给用户带来一次额外的“哇哦”的时刻。

我们也希望本书的打开外部包装时提供一个“哇哦”的时刻，因此每本书提供一个不同的厨房用具的想法(如一个勺子，茶巾，搅拌器等)的包装研究也正在进行中。

这些项目将在未来发布的版本中出现，一旦用户已经能够积累菜谱信息，我们就有机会观察他们平均倾向于使用多少本食谱。

这些都是微细节，但会使应用的整体体验更加情感化，因此也会更加难忘。

聚焦行为设计

通过这本书，我希望让你记忆深刻的是，设计有能力改变人们的行为。这可能是你考虑设计工作的新方法——但也是一种关键的转变。

理解用户在使用产品时，哪些当前习惯需要改变是我们考虑解决如今所面临的设计问题的重要方法。所以，我们应该如何让应用来解决这些行为方面的问题呢?

解构菜谱应用的行为设计

应用程序本身是一个数字餐饮剪贴簿。如果有人下载了该应用程序，可以假设他们会为了这个目的去使用它。

这为我们其中一个最初的行为目标提供了支持：

用户将会在数字空间内创建和存储菜谱。

确保应用具有的社交属性会鼓励用户分享和邀请朋友和家人一同使用。

地址簿专门设计放置在工作台页面顶部，总是出现在用户书籍列表末尾。这样，可以促使用户邀请新朋友或关注我们推荐的该地区的厨师和餐馆。

我们还创建了一本有“特色”的书作为一个帮助我们捕捉用户的注意力的工具，即使他们不需要上传一个新的菜谱，也可以使他们回到应用程序上来。

这点为其它目标提供了支持：

用户将通过此处与其他人分享菜谱。

用户将邀请家人或朋友使用这个功能。

用户将会经常查看应用，并在这里与其他人交流。

研究中关注的一点是，用户没有把许多菜谱放到他们特殊的餐饮剪贴簿内，这是有很多原因的。首先，存储空间有限(我们希望数字菜谱能够克服这个缺点，鼓励大家使用);第二，用户对可以放进书里的菜谱很挑剔。

为了解决这最后一方面的问题，添加一个菜谱需要简单并且过程中要获得享受，我们必须保证将菜谱的数字副本与他人分享是有内在价值的。

这为以下的行为目标提供了支持：

用户将放弃使用纸和笔。

用户将会将每天的菜肴都存档，而不只是针对某些“特殊时刻”。

用户会感到自己是被迫将自己所有的烹饪经验存档在这里。

在大厨里将烹饪经验存档，其简单、易用性如图14所示。

图8.14.简单就是应用秘制的调料

有些用户行为需要在应用发布后，从用户的背景访谈中才能够观察到;现在，我们觉得已经解决了确保应用能够鼓励用户习惯养成的问题。

产品发布后的用户习惯和行为跟踪是一个纵向的工作，我们一直要做的就是去用户家中进行访谈，将数据分析和季度用户研究结合起来。这将使我们能够依据了解到的内容不断更新和调整应用的设计。

像往常一样，持续的设计过程仍在继续，但重点是依据了解的内容去推进产品进化，而不是彻底革新。现在，我们的应用程序是这样的，如图15所示。

图15.我们来使用大厨吧

总结思考

有时，当我们坐下来和探索我们所需的交互方式时，往往过于专注于设计对象而将用户的概念从思想中去除了。这可能会导致我们忽略更长远的目标。

Mark Weiser的伟大名言提醒我们，在做设计的时候，什么才是最重要的：

“最深刻的技术是看不见的。他们把自己融入到日常生活的方方面面，直到无法区分开来。”

——Mark Weiser

记住，你的设计将影响和塑造人们的生活方式。考虑一下用户本身，设计想要唤起的行为类型，用户与产品未来的交互方式，这些都是你在设计时需要尽所能去考虑的。

什么能帮助提醒你去这么做?

了解商业问题，重视可能被强加给的限制。利用用户观点解决设计问题;勾勒出你的想法，然后建立原型来帮助测试提出的假设，并以不同的方式探索问题解决方案。当你开始摒弃旧观念，寻求新的方法的时候，这说明你对产品的理解在不断成长和进化。

如果这个过程已成为你新的思维方式和做法的话，可以说你正在让技术令生活变得有些不同的道路上前行。