对于产品设计团队来说，他们面临的最大问题是，经常将外观时髦的产品与功能优越的产品混为一谈，而且这种问题屡见不鲜。表面看来，这是一个微不足道的失误，但却会造成十分严重的后果：毕竟，如果用户玩不转你的产品，即便它们看上去再好，也没人买账。

我觉得，消除这种障碍的最佳途径是，采用一种以叙事为中心的设计手法。这种手法的核心理念是，针对产品提出一系列叙述性使用案例，从用户的角度出发，将产品设计的每一个步骤都描述清楚。我向大量创业公司推荐过这种设计手法，它总能让设计团队忽略表面文章，在用户真正关心的问题上做出更好的决定：即如何让产品最终做到物尽其用。

设计不应是蓝图

我注意到，一些团队在提出产品蓝图时，往往在UI(用户界面)设计上敷衍了事。每个屏幕会显示产品在不同情况下的外观，但这些屏幕并未以某种方式被联系起来。问题的症结就在于，当设计方案以这种方式呈现在大家面前时，用户只是对产品外观有大概的了解。

设计团队并没有将重点放在产品的工作机制上，也没有模拟客户如何与产品互动。所以，当一些团队片面地将设计视作产品蓝图的时候，他们全面推理产品互动性的能力便会严重受限。

最好的产品设计人员，往往精通以叙事为主的设计手法，而且将这种方法运用地炉火纯青。他们首先会构思几个故事，让客户明白如何与产品互动，只有在实现这一目标以后，他们才可以对屏幕进行设计，令其讲述一个产品互动的故事。

叙事为主的设计主线

在以叙事为主的设计流程中，设计团队首先要分析数十个按序列排序的模型，这些模型就像是幻灯片中的一幅幅画面。接着，他们要将客户读到的每个句子，他们做的每一个举动，整个系统回应产生的每一个屏幕，全部呈现出来。

从最初的触发事件，到完成一个目标，设计师都必须随时听取客户的建议，同时以实例展现整个过程中设计方案如何支持每一个步骤。我曾向许多创业公司推荐过这种以叙事为主的设计手法，这些手法适用于移动应用、营销网站、数据分析、企业IT部门等各类业务。

对工程师来说，这个设计流程应该很熟悉。以叙事为主的设计核心，类似于测试驱动(test-driven)的开发过程。只不过，我们并不是利用测试来核对代码，相反，我们只是通过构思故事来检验设计方案。就像测试驱动的开发流程一样，叙事为主的设计流程能够对团队的执行力和产品质量产生惊人的影响。

层层递进讲故事

1、白板故事

设计方案开始之初，设计师要在白板上写清楚，如何让客户与团队互动。首先，在白板上画一大堆1平方英尺大小的盒子，然后，在盒子中填写客户与产品互动的每一个小案例，并将每个重要部分连在一起。最后，勾勒出用户将要触碰或点击的每一个地方。这个步骤会花上很长一段时间，不过一旦整个团队在故事核心上达成一致，完成剩下的步骤就会快得多，浪费的时间会更少。

2、更换工具

大多数设计工具都是用来制作海报或图书的，所以，设计人员在设计充斥着大量框架的互动故事时，它们根本排不上用场。因此，尽早放弃Photoshop，选择Keynote、OmniGraffle或Fireworks这样的工具，此类工具支持多页面设计，帮助设计人员专注于打造端对端信息流。

3、从不评价单一屏幕

如果有人将一两个模型发过来评测，这时一定要小心了。应该确保你的团队始终在评测完整的故事。如果你是亲自提交设计方案，请将每一个屏幕打印在纸上，张贴在房间的每个角落。如此一来，所有人都能看到每个屏幕上的综览与细节。如果必须通过电子邮件发送设计方案，一定要拍下截屏，捕捉将各个屏幕合并成为完整故事的全过程。

叙事为主的设计流程为何表现如此高效

模拟用户体验。叙事为主的设计手法，会迫使我们在整个设计流程的每一个环节，都以客户体验为出发点。这样，从设计师、工程师到CEO，整个团队就会拥有一个完备的系统，可以根据人们体验产品的具体感受来做出设计决定。

提前发现问题。由于叙事性增加了一个时间维度，各类设计失误就会很突出，如果团队将产品看作是一堆堆屏幕时，他们往往不会注意到这些失误。叙事性还能让团队更容易注意到，何时未达到理想的预期。同时，他们还会发现一些多余且完全行不通的UI环节，并更为快速地解决。所有这些看似微不足道的细节，最终都能提升产品的实用性和互动性。

预先确定设计目标。当团队以构思故事的方式拉开产品设计的序幕时，每个人在解决具体细节之前，就必须在设计目标上达成一致。这对于产品设计工作大有裨益，因为在设计人员耗时数小时研究详细的UI模型后，评判的范围往往会缩小至一个问题，即设计方案是否达到预先设定的目标。

更加科学。仔细回想客户从最初的触发事件(如电子邮件或信息推送)到最终完成目标，我们会发现整个过程其实与“求助福克博士”(Dr. BJ Fogg)倡导的行为模式极为吻合，即触发、激励和能力等三个因素同时发生，缺一不可。以叙事为主的设计方案，让我们易于核对上述三个元素是否全部到位，从而可以鼓励用户行为。

加速整个设计流程。部分故事能够在团队的其他工作中被重复利用。那些为展示故事性而创建的模型，可以变成快速、可点击的产品原型，用于研究用户行为。同样的故事还可以用来构建渠道分析，帮助揭开一个问题的答案，即用户是否正在现实产品中实践这一故事。质量保证(QA)团队还可以全面筛选重要故事，确保每一款新产品的合理性。

本文编译自Gigaom