有这样一个团队，数月来他们一直在困境中挣扎。这和通常所说的“我们拼尽全力并最终搞定”的这种困难不一样——这种困难早就过去了。

是的，这是另一种类型的困境。我们姑且把它叫做“推出之后才发现公司有了大麻烦”的困境。

该团队冒险尝试了一个全新的——可以显著提升顾客体验——的设计，这个设计被赋予厚望。然而事与愿违，他们自吞苦果。

失败注定有百害而无一利？

马后炮谁不会呢——他们应当不惜一切避免失败的。毕竟，缩在餐厅一角，听着“这个家伙就是那群窝囊废中的一个”式的冷嘲热讽，谁愿意自己成为这样的人呢。

但如果你回首一个世纪以来的所有伟大革新和发明，你会发现：失败不可或缺。我们需要通过失败去吸取经验。

当成功来临，我们通常只知其然不知其所以然？哪一步或者什么事情是导致成功的关键呢？这些是成功本身无法告诉我们的。

相对于成功而言，失败的经历更有助于积累经验。失败后——我们花时间从失败身上吸取教训——我们发现其中的缺陷暴露无遗。常言道：没有最好，只有更好。

我们需要失败。我们只是想要通过它，从而把风险降到最低。

稳扎稳打，步步为营

亚马逊网最近对其系统进行了一次很大的调整，同样也很可能是一次在无法控制风险之下产生灾难性后果的调整。亚马逊网每年销售额接近120亿美元，一次设计改版的失败，哪怕就短短一天，也将对他们造成数以百万计的损失。

去年夏天，当亚马逊网的设计师们决定使用新的导航系统（舍弃从网站建立之初到现在的标签设计）时，他们慎之又慎。所有人都盯着他们，没人希望看到一个所谓的“改进”最后却毁了整个网站。

呈现在众人面前的最终结果是其中一个最稳妥的设计方案。一切先从挑选“最没风险”的顾客开始，从非注册用户中选择测试对象，判断标准是他们是否留有网站的Cookie文件。（有Cookies文件的亚马逊网用户会收到个性化信息。）

当调整即将发布时，被挑选出的临时游客中依然只有一小部分被允许看到新的导航栏。一旦这些人感觉不错并适应了这种设计，测试名额将慢慢逐渐放开，更多的临时游客将看到这些新设计的导航栏。

在数周的临时游客开放试行后，亚马逊网才慢慢让网站的回头客（和注册用户）也使用新的导航，但即使到了这一步，他们也没有急于求成，而是同样用了好几个星期才完成所有的转换工作。

降低风险

尽管时间上长了一些，但是亚马逊网的设计团队使得新的导航尽可能平缓地公之于众。如果结局是败笔，他们也可尽早的从容应对。直到导航让人觉得很顺手了，他们才将其开放给更多用户。

平稳过渡是降低风险的一种方法。此外，不乏其他同样行之有效的方法。

例如，（纸上）简易原型就是一种很棒的方法。在纸上勾勒出交互行为，并将其试用于潜在客户，你会很快的搜集到关于该设计的一套可靠反馈。在这种情况下，风险只是存在于纸上，或是，把时间浪费在功能建设上也无关紧要了。

还有一种方法可以降低风险——快速迭代。当一切都顺利完成，每一次迭代所产生的关于用户以及用户需求的信息，都将被团队应用到下一版本的设计中。迭代循环得越快，设计就会越快的被完善，直至用户满意。

对失败的常见误解

“正确的判断从经验中来，而经验从糟糕的判断中来。”

“人人都把自己的错误美其名曰的称为经验。”

在研究各团队设计实践时，我们总结了其中一些常有的——因为做或没做，从而让失败变得毫无意义的——错误做法。

错误1：忘了“磨刀不误砍柴工”。如果团队一开始就仓促上阵，那么他们自然很难发现什么时候出错了。先确定一个清晰统一的思路，团队中的每个人都可以迅速找出错误，并将其改正使得一切恢复正轨。

错误2：从不“返躬内省”。有些不好的事情发生后，人们总是想尽快翻过这一页。说真的，先别急着翻页，停下来扪心自问“刚才怎么了？”和“我们可以从中学到什么？”对于团队而言更重要。

错误3：默默地跌倒爬起，而不相互沟通。在大型团队中，小错误（或者更大一些的）有可能被团队中没有直接参与其中的成员忽视。在失败中得来教训要在团队中充分沟通，这很关键。跌倒后也要喊出来，不然其他人怎么知道你在哪里摔倒的。

错误4：从没想过要迭代试验。“早知如此何必当初”，这种话多说无益。从没考虑过失败了要怎么处理的，这种盲目乐观的结果通常都是，该团队发现自己被逼进死胡同。正如在亚马逊网的所做的那样，留点时间去做迭代试验，结局完美。

错误5：无法灵活扩展的平台。我们经常听到人们为自己辩解，诸如“我们是很想去试试啦，但是你知道的，我们的CMS平台做不到。”团队是被缺乏可扩展性的平台禁锢住了，应对失败的来临——这种平台一点办法也没有。基于可扩展性平台（并且掌握了充分利用这种可扩展性技巧）的团队却可以从容应对失败。

错误6：反馈周期内的工作过犹不及。条条框框太多反而让团队缩手缩脚。优秀的团队利用各种快速原型工具尽早处理反馈。而不是一直等到海量的用户反馈搜集齐之后才开始处理，这时候已经很难回头了。

错误7：没对设计进行代入式演算评估。许多团队没有想过一旦设计推出之后会是怎样一个状况。他们没经过适当的估量就把设计推出去了。优秀的团队在项目伊始就构建好了设计将会有的演算结果，我们所见的不过是他们预料之中的一部分。

错误8：反馈信息都是“食之无味，弃之可惜”的鸡肋。“这有用么？有/没有”这类问题看上去挺有意思，但它能告诉你什么？如果大部分答案是“没有”，你下一步又要怎么做呢？优秀的团队会确保他们从用户那里得到更深入的反馈信息。（例如，经过严密的可用性测试，Netflix公司合并了A、B两个站点，我们可以同时从定量和定性的这两个角度来看设计问题。）

橘生于南则为橘,橘生于北则为枳

我们的研究表明，公司文化，是处理失败中最关键的一环。把失败当做是成长的一部分，为从失败中学得更多经验而高兴的达观态度远比逃避主义好得多。公司的管理和奖励机制中应当写进这样一句话——失败是可以接受的。往好处想，至少风险没了，正所谓吃一堑长一智。

我们的字典没有“失败糟糕透了”这样的说法。所有的团队都应该在日常工作中更好的把失败转化为积极的一面。

分享你的想法

你所在的公司是如何看待失败的？来UIE Brain Sparks的博客里和我们分享你的故事和看法吧，我们洗耳恭听。

打印  |  相关话题：产品设计团队协作 UCD翻译小组   |  类别：设计之外  |  源地址