与用户体验有关的第一个问题：你为什么要这么做？

今天为大家更新《用户体验要素》最后一章的最后两小结——提出正确的问题

本小结关键词：提出正确的问题

主要观点：面对用户体验的设计纠结时，正确的做法是，将每一个决定都建立在对其背后议题的理解之上。

---

提出正确的问题

面对那些设计用户体验时需要解决的纠缠不清的小问题，有时会是一件令人气馁的事情。有1时某一个问题的解决办法会让你不得不重新思考你认为已经解决的其他问题。很多时候，你必须在不同的做法之间做出妥协并评估利弊和进行取舍。当你夹在不得不做出此类决定的中间左右为难的时候，不管你是否采取了正确的做法，都很容易变得沮丧和怀疑。正确的做法是，将每一个决定都建立在对其背后议题的理解之上。 与用户体验有关的第一个问题恐怕是问你自己的（这也是你应该回答的第一个问题）：你为什么要这么做？

对于你即将面临的问题抱有一种正确的心态是最重要的。每一个用户体验的设计过程的其他方面都有可能导致调整，以适应时间、金钱和为你工作的人员。没有时间去收集你的用户数据？也许你能找到办法去看看已经拿到手的信息，比如客服的日志或反馈消息，去找到用户需求的一些感觉。负担不起租用可用性实验室的费用？那就找几个朋友、家人或同事来做一些非正式的测试。

不要以“节省项目时间或金钱”的名义对用户体验问题敷衍了事。在某些项目中，一些人会自作聪明地在这个过程的最末尾添加“用户体验评估”——在应该提出这些问题的时机已经过去很久以后。当发布日期确定后，你告诉自己“比赛开始以后不要顾虑太多”，这看上去好像是一个不错的主意，但这样最后很可能得到的是一个满足所有技术需求却恰恰对你的用户毫无用处的产品。甚至更糟的是，通过在结束时附加的用户体验评估，最后你可能会发布一个明知道已经被损坏却没有机会（或多余的金钱）去修复的产品。

一些企业很喜欢这种做法，称之为“用户接受度测试”，“接受度 （acceptance）”这个词在这里的意思非常明显——问题不是说他们是否会喜欢或是否会使用这个产品，而是他们是否能接受它。这种类型的测试往往发生在整个流程的最后，在那个时候无数的假设已经在没有经过任何检查的情况下进入形成用户体验的过程中了。想在已完成的产品中通过用户测试中揭露出这些假设是极度困难的，因为它们藏在了界面和交互的外衣下面。

很多人提倡将用户测试作为确保良好的用户体验的一个主要手段。

这种思路看上去是你应该做一些事，将它们摆到一些人的面前，来看看他们有多喜欢它，然后无论他们抱怨什么都将其修正。但是测试永远无法取代一个考虑周密的、准备充分的用户体验设计过程。

询问你的用户关于产品的某个具体元素的问题，能帮助你收集来自用户的更多相关信息。没有着眼于用户体验的用户测试，很可能以提出错误的问题而告终，这相反又会导致你得到错误的答案。例如，在测试原型的时候，知道要在调查中列出哪些问题是展示出你的测试主题的关键，经验是“不要用不相关的内容来把事情搞得更混乱”。导航条的问题真的只是跟颜色有关吗？还是用户对导航所使用词汇有所微辞？

你不能简单地依赖你的用户来阐明自己的需求。不管创建什么样的用户体验，其最大的挑战是“比用户自己更准确地去理解他们的需求”。 测试可以帮助你了解用户的需求，但是它只是能达到同样的目的的许多工具之一。

马拉松和短跑

就如同不应该拿用户体验的任何一部分来碰运气一样，你也不应该靠运气来完成自己的开发过程。企业中永远处在紧急情况下的开发团队太多了。每一个项目都被看成是对某些被察觉到的危机的回应，同时， 这样的结果就是，每一个项目在它刚刚开始的时候就已经落后于计划了。

当我向客户描述问题的时候，我常常使用一个比喻来形容用户体验开发过程：它是一场“马拉松”而不是“短跑”。了解你所参加的比赛类型才能用适合的方式去参赛。

短跑比赛是短距离的比赛。短跑运动员必须在发令枪响起的那一刻聚集起所有储备的能量—而且他们必须要在那几分钟内迸发出所有的能量。在离开起跑线的一瞬间，短跑运动员就必须尽可能快地跑起来，并且尽可能地保持这种奔跑速度直到他到达终点线。

马拉松是长距离的比赛。马拉松运动员需要和短跑运动员一样的能 量，但它们的使用方式是完全不同的。成功的马拉松取决于运动员如何有效地控制自己的步伐。在其他所有因素相同的情况下，运动员知道“何时加速”以及“何时减速”才更有可能赢得比赛—或者甚至彻底结束这场比赛。

短跑的战略（从开始到结束都要尽可能快地奔跑）显然是在这样的比赛中唯一最明智的做法。看上去你应该可以进行一场马拉松比赛，把它当成一系列全速冲刺的组合—但是这种方法是行不通的。行不通的部分原因是因为人类身体的耐力极限。这里还有另外一个因素：为了适应这个极限，马拉松运动员需要持续地监控自己的表现，密切注意哪些可行哪些不可行，并且适时地调整自己的方式。

产品开发很少是短跑比赛。更常见的是，有时候你会向前推进，建立原型和产生想法，然后随着时间推移，你再返回来，测试你所建立起来的东西，看看各个组成部分如何结合在一起，并且为这个项目提炼出一个综合的画面。有些任务需要重点承担速度；另一些则要求一个更加深思熟虑的方法。优秀的马拉松运动员知道哪些是哪些—所以你也应该。

经过深思熟虑的设计决策，可能会在短期内花费一定的时间，但是它们将在一个更长时期中节省更多的时间。设计师和开发者总是在他们的工作进行到某个阶段时，才后悔没有提前关注战略、范围和结构。我曾经参与了很多项目，在这些项目中有些用户体验工作总是处在有可能被取消的威胁之下。图形或一段代码产生了实际网站的组成部分，而对于那些没有产生可视化成果的任务，有些人会变得不耐烦。这些任务通常会在进程落后或预算超支的时候成为第一个被砍掉的项目。

但是这些包括了最初项目范围的任务，它们是稍后产生可交付成果的必要准备（这就是为什么五层模型应该从底部开始建立，每一层都是其上一层的基础）。当这些任务被取消之后，任务和可交付成果被一个更大的项目环境留在了不确定的项目日程中，似乎与其他的那些都脱节了。

当你最终完成时，你得到一个没有达到大家期望的产品。你不仅仅没有解决你原来的问题，事实上还给自己造成了新的问题，因为现在下一个刚刚冒出来的大项目正是你在上一个项目中试图去解决的一些缺陷。然后你又进入了另一次的恶性循环中。

以局外人的身份来看看这个产品（或者在第一次进入产品开发过程的时候）很容易在忽略靠近底部的那些要素的同时，把关注点放在五层模型中靠近顶部的、更显而易见的要素上。然而，具有讽刺意味的是， 那些最难被感知的要素（产品的战略层、范围层和结构层）在决定用户体验的最终成功或失败方面扮演了一个必不可少的角色。

在大多数情况下，在上一级层面中的错误有可能会削弱更低层面的正确决策。在视觉设计的上问题（看上去很杂乱或混淆的布局，不一致或不协调的色彩）会让用户很快离开，从而永远不会意识到你在导航或交互设计上做了很多聪明的选择。缺乏考虑的导航设计方法也可以使你在“创建的良好、灵活的信息架构”上的所有努力变成浪费时间。

相似地，如果那些在上一级层面上做出的正确决定是建立在低一级层面做出的错误决策的基础上的话，那些决定就没有任何意义。在网站历史中，一些网站之所以失败，是因为它们虽然很漂亮，却完全不可用。过于关注视觉设计，而排除其他的用户体验要素使得不止一个网站宣告破产，并使其他公司完全不明白为什么总是被网站问题所困扰。

这种糟糕的结果并不是必然的。如果你在网站开发的时候，始终从完整的用户体验出发，那么最后得到的网站就是一份有价值的资产，而不是无休无止的债务。每一件与网站的用户体验有关的事情都是有意识地、明确地决策的结果，只有这样你才能确保这个网站能同时满足你的战略目标和用户需求。