第章用户体验设计与实现

第19章　用户体验设计与实现　User Experience Design vs. Implementation

先定义用户体验再动手开发

在软件开发过程中，有很多工作可以同时进行。比如，我一直认为需求调研和产品设计（用户体验设计）是互相影响的，应该同步展开。我不喜欢老式的瀑布式开发模型，产品经理先完成需求调研，然后交给交互设计师设计。业界已经认识到这是一种陈旧的产品开发思路。

此外，多数软件开发团队已经尝到了开发与测试交叉进行的甜头，我认为这是巨大的进步。以前的做法是开发人员先编写代码，全部完成后再交给测试人员测试，不但耗费时间，而且可靠性差。

尽管如此，有些工作不能同步展开。许多团队把用户体验设计和软件开发放在一起进行，这是行不通的。原因如下。

1. 与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。因为开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发。前期架构决策极大地制约着后期的开发工作，事后修改软件架构，无异于推翻重来。另外，从心理上说，事后修改设计会打击开发人员的斗志，引发消极的心态。随着时间一分一秒过去，返工和波动会增加团队的压力。尽管敏捷方法提倡不断修改和完善，但并非所有的修改都受欢迎。

2. 用户体验设计要保证产品同时具备可用性和价值，任务很重。为了拿出既可用又具有价值的设计，必须尽早、反复地验证设计思路。有些人觉得可以等到每个迭代周期结束再观察设计思路是否合适，甚至等到产品公开测试时再收集用户反馈，这样低效的验证方法肯定是行不通的。优秀的用户体验设计师一两天内要尝试几十个点子，哪怕只是2~4周的迭代周期都会慢得让人无法忍受。

3. 我认为验证设计思路必须使用高保真原型。有人说，迭代结果和公开测试的产品可以当做原型。抛开要等很长时间不谈，这些开发中的产品与产品原型有很大的区别，不能混用。为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。

4. 尽管产品开发可以分成多次迭代（这样做可以降低风险，提高质量，便于产品集成），用户体验设计却不能拆分。设计师必须全面地、连贯地看待用户体验，考虑以往用户的使用习惯。让用户放弃不可用的软件很容易，要他们放弃使用习惯却很难。

5. 用户体验设计不一定是最费时间的工作（像软件开发一样，所需时间取决于具体的方法、特定的产品需求，以及从业者的技能和经验），但至少需要一两周时间。

如果产品设计和开发同步展开，那么多半会出现这样的情况：一方面，开发人员等着设计师的设计结果无事可做；另一方面，设计师饱受压力，要在几天内完成原本需要几周完成的工作。为了应付差事，设计师只好不情愿地拿出仓促完成的设计交给开发人员。开发人员一边开发，设计师一边修改设计。等设计师最终完成设计，为时已晚，开发人员会说：“等下一轮再修改吧。”但下一轮又有下一轮的重点。设计师对产品不满意，用户更不会喜欢这个结果。

如果我遇到这种情况，肯定会辞职，到一家看重用户体验的公司去谋职。

还好，这个问题不难解决，关键是确定先后顺序。虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进行，但是用户体验设计应该在软件开发前完成。

敏捷方法里有个概念叫“第零次迭代（sprint zero）”，产品经理和用户体验设计师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发。这需要更详细地定义待开发任务（backlog），但团队工作会更愉快，产品也会更好。

只有在开发人员要开发大量后台基础软件的情况下，用户体验设计和软件开发才能并行展开。在这种情况下，开发团队可以利用设计师设计产品的时间完成这部分工作。虽然双方的工作会有一些依赖关系，但可以解决。多给设计师一些时间定义详细的待开发任务。

请注意，尽管我提倡需求调研和产品设计都要在软件开发前完成，但是在此期间至少应该邀请一位软件开发人员检查设计工作，他可以协助你评估设计的可行性和成本，作出更明智的决策。别忘了，我们的目标是打造有价值的、可用的、可行的产品。

许多产品团队在尝试敏捷方法的时候，出现了设计上的混乱。这实在是可惜，因为只要稍作说明和调整，敏捷方法相对于传统的瀑布式开发方法来说是巨大的进步。我在第26章会讲述出现混乱的原因，以及如何合理利用敏捷方法。