用户体验在产品发展过程中所扮演的角色

谁都不愿意只身一人呆在山间小屋或孤零零地下室里埋头工作。创建产品的过程中，我们每个人都需要与他人合作。良好的合作是保证你的用户体验解决方案能够提升产品价值并获得成功的关键特征。合作会更加有效，但是最重要的是，这可以确保你的设计能够同时满足用户和客户的需求。

就像那些已经在用户体验这个领域工作了数十年的人一样，我受到过六种开发方法的训练，完成了150多个敏捷项目，但这些天有一样东西令我很困惑，就是术语瀑布。在前敏捷时代，我从未在声称过自己正在做瀑布开发的机构里工作过。如果我当时听到某个团队是“将设计投到墙上”时，现在我也会做出和他们当初一样的做法，一定要嘲弄回来吧。产品开发——至少对于那些任何人都期望其成功的产品——总是在重复，增值，协作。

没有瀑布

传统的软件发展方法不是逐步地或是封闭的。甚至是在最糟糕的开发过程中，人们也不是将他们自己锁进分开的房间独自完成工作，然后通过墙上的狭槽把完全成型、未经改动的文件递出来。就像Phillip G. Armour在他的《软件商业：评价不是恶魔》一文中写到的：

“瀑布模式不是真正的工作方法。它不是类似允许在一个简化系统的基础上追踪项目的管理模型那样的开发模型。几乎从来不会在一个明确的日期完成工作，然而大多数先前定义的需求会在后期进行明确，与简单模型假设相冲突从而进行必要的修正，这一过程贯穿设计生命周期的始终。”

这也是我的经验。只有糟糕的团队才不会合作。即使一些聪明的经理雄心勃勃,试图让团队每个人放弃最优的选择，不同的学科背景的成员将秘密地满足和协调他们各自的活动。每个人都在不断地重复。例如，螺旋只是一个更老的开发方法，其目的是提高产品整个开发生命周期。图1说明了螺旋发展是如何工作的。

图1—螺旋发展的生命周期

其他开发过程往往是相似的。即使存在不同的阶段,每个人——包括那些最终将维护系统的人——都将被邀请，甚至要求直接参与项目。另外，因为几乎没人能独自搞定一个设计项目，所以许多阶段有所重叠或人们继续以监控者的身份工作。

他们将用户体验集合成这些过程。我认为这样的过程十分轻松和自然。当严谨的的软件开发人员或架构师提到设计时，他们通常指的是软件设计、数据库设计、或其他技术类设计工作。虽然如今的团队经常对这样的工作漠不关心，但是这些工作对于建立一个可靠的满足预期的产品来说是至关重要的。

量化用户需求

这种混淆的术语可能会出现问题。如果我们各自想要设计出不同的事物，那么我们该如何一起工作呢？好吧，我不认为我们想要不同的东西。用户体验设计也是与建立系统有关。我们只是把用户当作是系统的一部分并且承认他们有可量化的需求和约束。

关键是要尽可能地将用户定义得宽泛一些。用户不仅仅包括那些将会使用你产品的最终用户，应包括像管理员、内容创建者和负责系统维护的这些内部使用者在内。无论你是将遗留系统移植到新的平台还是从头创建除数字技术以外的全新技术，你还需要解决商业流程和目标。

当你以这种方式看待用户体验时，忽然商业项目中的每个人——甚至可能是工程团队——会发现你所扮演的角色是有意义并且有价值的。如果当你作为用户体验设计师，也花时间来了解技术约束并且同时考虑客户需求和用户需求时，你会发现这个观点尤为正确。如果你那么做了，你的设计工作将自然而然的地与技术规范同步。由于我们工作分析的本质，用户体验专业人士可能成为他们团队早期最有价值的成员。总之，这时就是做我们的工作最简单的时候。

用户体验和开发过程

那么，唯一的挑战就是开发过程本身。在过去的一周里，我了解到敏捷专家完全不懂用户体验设计是干什么的。甚至在我多次解释了用户体验的作用之后，他们仍然坚持认为我们是在任务流程设立之后进行用户界面（UI）设计的。他们甚至认为在第一轮功能方面的开发完成之后，我们只要清理UI就好了。更糟糕的是，如果我们事先做一些整体的、敌对的设计，他们就会认为我们破坏了他们的进程，因此最终认定我们：不合作。

这是不久前在Twitter上的一次交谈，Brian Rieger对我的微博回应如下：

“我发现‘敏捷设计’的讨论让我最好奇的是我从未意识到设计（我曾经学到的）绝不是敏捷设计。”

除了一些强烈提出质疑的经理、过程教练以及开发人员，大多数项目团队至少会给你一些余地，来解释作为一个用户体验专业人员，你会为这个项目做些什么。那么，你能做些什么来克服这些偏见呢？

通常，这时候我会说我是一个生态系统设计师。我的工作是发现、整合和平衡所有的需求和限制，如表1所示。

表1—平衡需求和限制

我们如何做到呢？如果我们必须通过定义一些关键的指导方针来将其明确，那么我会说：

第一，不要画出来 收集并且理解 首先设计生态系统 保持，看，轻敲，连接 注释，描述并且解释 评估和验证

在我对他们每个进行讨论之前，我想强调一下，他们真的不是设计过程中的步骤。而是，在整个项目中你会反复运用甚至是一直要用的行动或行为。这些是你反复在做的事情。例如，你就要开始做这些事情的时候，不只是当你第一次接手一个新项目的时候，而是无论何时只要新的信息出现，你就该这么做。

第一，不要画出来

我不是通过哲学反思来了解到用户体验在开发过程中的作用的，而是失败教会了我这些。从本质上说，我不是“天才设计师”，决策类型和得到好的结果依赖于直觉和丰富的经验——虽然我讨厌这个名词的一些含义。事实上，我过去常常打断顾客对他们需求的解释并且在几分钟内在白板上想出很棒的解决方案。但在十年前，当我为Sprint网站彻底重做时，出现了紧急情况。

我创建了一个非常高级的网站地图——在信息架构（IA）这一术语在我大脑中形成之前——以及一组很好地遵循了品牌和最好的实践原则的页面模板。然后一个非常优秀的项目经理把我们和每个产品拥有者轮流安排在一个房间。和他们工作六个月，有时一天工作16个小时，把网站的几百个网页的每一页都画在模板的打印纸上—用铅笔一部分一部分地画，如图2所示。

然后我把这些画变成图像处理的实物原型。几个星期后，进入到了进程的这一部分，很明显这个方法是很疯狂的，一旦我完成了，我就开始寻找一种更好的方法。这些都是发生在以用户为中心的设计折线图和直方图存在之前。所以，我没有可以参照的对象。图2展示的是我以前的方法，独立地、一页一页来设计每个部分。

图2—我以前用的用户体验设计方法