过去常常被问到一个类似的问题：「有没有UX设计的SOP? 我们想要导入一套像IDEO一样，那么完整的设计流程」。每回听到这样的大哉问，我都不太好意思直接泼对方冷水，毕竟会提出这样的问题，必定是对于使用经验有一定的追求与憧憬。不过，很实际的状况是，大多数公司都不需要「完整的」设计流程;相反地，大家真正需要的是，一个「有效而且弹性的」设计流程。

话说，世界上并不是没有整套规划详尽的UCD (User-Centered Design)设计流程，事实上多得是，而且写得超完整。下图UPA的Typical UCD Process就是一个很好的範例参考 。我还记得第一次看到这张设计流程图的时候，曾惊嘆地发出啊的一声，然后心裡想着：怎么可能从头到尾，全部都跑过一次啊?是的，每个案子都可以这样跑才有鬼。当各公司的UX team都在追求更多的时间、更多的资源，并且说服公司老闆要导入完整的设计流程的同时，基本上我的实务经验是：很难跑完所谓完整的设计流程，而且就算跑完了，通常这个设计专案也会以失败收场。

失败?真的吗?UCD设计流程看起来都很合理而且严谨啊，怎么会不成功呢?

UPA Typical UCD Process， 能够真的都跑完才有鬼

地球是圆的，而且不停快速转动

UCD流程其实没有错，每一个设计专案，基本上都必须要从理解使用者开始，经过user profile以及scenario的分析，找到潜在的问题与机会点，然后逐步发展概念、验证，并且走向细部设计。这个基本塬则跟人需要吃饭喝水一样自然，不需要再多做解释。

只不过，在业界根本没有那么多时间，可以等繁复精準的研究报告，世界上也没有那么乖巧的竞争对手跟消费者，会动也不动地等在哪裡，让你把市场慢慢研究透彻，然后再花6-12个月的时间把产品设计验证到位。

举个例，我曾经歷过好几个创新产品的研发，研究团队个别花了2-3个月去做缜密的使用者访谈、脉络分析，最后产出了几篇掷地有声的使用者研究报告，不仅点出了几项具体的使用者需求，而且也提供了好几个可能的设计脉络。在那个当下，研究报告的价值是很高的。不过随着时间过去，几週后，竞争对手的新产品推出，一下子满足了其中几项设计需求;两个月后，新技术的出现，又消除了几个问题点;半年后，消费者对于该议题的热度开始明显降温。至此，虽然这些创新产品已经投入了大量资源去设计研发，走向量产，但是价值却已经大减。

于是UX team会陷入一个无限迴圈，不断重复辛苦地发现需求，看着竞争对手跟上，然后留下「我们早在半年前就知道了」的遗憾。

拿出铅笔跟白纸，简化沟通，加快速度

被嫌速度太慢，花太多时间，几乎是每一个有组织、有流程、重品质的设计团队，会被其他部门围勦抱怨的共同问题。不讳言，我带过的每一个团队，在不同公司文化下，全都被嫌过这件事，哈哈。回头想想，UCD设计的速度能否再快一点?我自己试验的结果，很简单，只要把电脑关了，把铅笔跟白纸拿出来，就会看到效果。

铅笔跟白纸，是最省脑力，也是最有效的设计工具

首先，UCD首重理解使用者、釐清问题与需求。既然使用者不在电脑裡，把电脑关了，直接走到目标族群的场域，开始做隐身长时间地观察，必要时立刻做抽样访谈。并且逐日检讨、修正访谈方向与架构，直到找出脉络即可。这种弹性速成的作法，并没有办法达到无可挑剔的可信度，但是可以在较短的时间内，找到几个大的设计脉络，那也就够了。

再来，把铅笔跟白纸拿出来，这会有助于让设计师专注在解决「使用者的问题」，而非解决绘图工具的「操作问题」。不要小看铅笔跟纸，好的概念设计，用铅笔就可以勾勒出主要的架构跟轮廓，藉此做快速的发散跟收验。如果一个介面设计用铅笔画，用嘴巴沟通，在1分鐘内没有办法让人感受到价值，那么八成就可以先放在旁边，赶快想新的。至于绘图软体，在概念阶段能不用就不用吧。这么复杂又费神的工具，光是用它画条线、填个色，就会耗去很多时间跟脑力。头脑的资源很珍贵，用简单省力的工具就好。再说一次，我们要解决的是「使用者的问题」，而非解决绘图工具的「操作问题」。

然后是简化沟通。沟通的成本是很高的，尤其是公司内有MIS部门，会定期更新Exchange Server版本的大公司，沟通成本更是无法想像地高 (汗颜)。举个例，我过去每天平均要收120-150封信件，开4-5小时的会议，然后打5-10通电话。这些沟通有促进我们跟各部门的关係，有加快团队的设计速度跟品质吗?没有，老实说一点也没有。

要简化沟通、加快速度，最快的方法就是把RD、PM一起抓进来观察使用者，然后以极短的週期，不断地重复「发现问题、解决问题」的流程，直到产品到位。这样省了电话、信件，也省掉了精美PowerPoint，以及一堆没有人看的各式文件。省掉形式，简化沟通，把每一份力气都花在有效地产出，这是 Agile Development的精神，也唿应了最近开始崛起的Lean UX。

然而，只有设计可以加快速度吗?当然不是。如果你家的PM，拿着这篇文章来扣你帽子，请他们回头想清楚自己的工作裡，有多少比例是纯粹传递讯息，汇整意见，跟催进度等类行政工作。请他们也省点力气在无谓的事情上，多花点时间跟着研发团队一起规划产品、解决使用者的问题。UCD是每一个人的事，只有每个人都在意，都认同，才有可能看到成果。

照着上面说的做，就天下太平了吗?

产品开发有这么单纯就好了，嗬。

理想的UCD设计流程，会像是Bill Buxton在Sketching User Interfaces所提到的这张图。从左到右是一个逐渐收敛成形的过程，随着时间过去，从概念草图，逐渐形塑成设计塬型。中间会有不断的 iteration，但是设计方向会逐渐明确，设计部门投入的资源会越来越少。

理想中的Product Development Process

(Bill Buxton， Sketching User Interfaces)

但是实际状况比较像下图。资讯架构 (Information Architecture) 跟介面设计 (Design)除了在前半段投入大量心力外，在程式开发出第一个版本，以及产品上市前，通常至少都还会有两波高度忙碌期。这段期间的资源投入，理论上是不需要的，因为设计架构已经确定，产品开发的变数已经降到最低。然而，天有不测风云，人有旦夕祸福。产品开发中一定会遇到各种状况，像是开发平台更新 SDK、老闆要求加新功能、零组件供应商倒了，什么事都有可能，突发状况永远比你预想的还多。

实际上会遇到的 Product Development Process

所以，一定要让自己的设计流程更加「有效而且弹性」，并且常保一颗乐观、有幽默感的心。现在就把电脑关了、拿出铅笔跟白纸，换个方式来做设计。说不定，你会做的更愉快，更有成就感也说不定。

文章来源：handyui.com