先研究、再设计的方式将被一个新方式取代:先设计、再研究,它可靠吗？

有多少次你为了能在项目最开始就进行实地研究与观察而奋战？有多少次你耐心地解释初期研发花费的时间会使产品更快地进入市场？又有多少次你是成功的？在人机交互行业（HCI community），长期以来总在抱怨没有从仔细的观察开始来进行产品开发。

我越想越认为是我们这些人机交互专家错了。犯错的也包括我，因为我长期以来都拥护“先研究、再设计”。现在，我对许多项目建议的顺序是“先设计、再研究”。

让我们面对现实：一旦一个项目被确定下来，再来研究它应该是什么就太晚了。如果你想做创新性研究，必须在项目上马之前进行。首先，你得在作项目决策的团队中谋得一席之地——这意味着你必须是管理层中的一员。（人机交互界的毛病之一：很少有人是管理者。）

而且，既然大多数项目都是由既有项目推进，那为什么我们要重新研究用户？我们不是应该在整个决策过程中一直研究他们吗？一旦项目开始就为时已晚了。好好想想这一点。

然而，也请大家注意到这个矛盾：我们所有的可用性理论家长期以来都赞成迭代设计（iterative design），试图摆脱冗长、僵化的线性项目时间表，因为那妨碍了弹性与变化，使得项目进程减缓。我们拥护的迭代设计则具有频繁而迅捷的原型（prototyping）与测试。

其实，我们不断强调的先期用户研究、实地观察及对用户真实需求的发现是不进反退之举：它们是插到设计与编码阶段之前的一个线性、僵化步骤。我们为自己鼓吹的是一种瀑布开发方法（waterfall method：试图在一开始就找出所有需求，然后顺序地完成整个项目）。是的，当我们说需要时间来进行所谓的实地研究、仔细观察之际，我们正在与自己所声称要提倡的方法相抵触。

编程人员长期以来困扰于类似的问题。他们也试图消灭冗长、僵化、拖慢进程的线性项目时间表。他们正在尝试敏捷方法（Agile）与极限编程（Extreme Programming，XP）等许多新的快速的迭代编程方法。

始于冗长的目标设置，然后设计，编程，再测试的线性项目流程（即“瀑布方法”）已经完蛋了。谢天谢地。新的编程方法涉及迭代设计与多学科团队合作等每一件我们想要争取的东西。现在是时候让用户界面设计圈跟随他们的步伐了——来做我们自己一直在宣传的事。

实地研究、用户观察、情境分析（contextual analyses）及其他所有致力于找出真实人类需求的程序和以往任何时候一样重要——但它们应该在产品流程之外完成。这是决定建造什么样的产品所必需的信息，而整个项目正是基于此上。不要在项目启动以后坚持做这些事，那时已经太晚了，你只会拖累每个人。

一旦项目开始，它就将严格受制于时间与资源。这是无法改变的事实：所有的产品团队都能感受到这种约束。我们的目标是在多学科团队中工作，来快速高效地制造出有效而讨人喜欢的设计。如果可以，先设计，然后回顾，测试，再设计。让开发与营销团队知道产品看上去将是什么样的，并且在项目一开始就这样行动。相信我们具有迅速设计出精致、易懂界面而无需（冗长）研究的能力。成为团队的重要部分，这样我们的成果才能与所有其他人的同时推出。幸运的是，这是新开发方法的一部分。

所以让我们将实地调查、观察研究与概念设计工作同来自真正产品项目的需求分析区分开来。我们必须在项目开始之前就发现用户需要什么，因为一旦开始，方向就已经被决定了。使用快速、迭代的方法迫在眉睫，这些新方法最好的地方在于为我们提供了空间：它们明确地知道人机交互设计的重要性。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号