1700424350
1700424351
1700424352
1700424353
1700424354
必须要同时考虑五个层面的全部因素，这对于创建成功的用户体验是至关重要的。有专人分头来负起责任固然重要，但更重要的是要保证所有的用户体验要素都被关注。
1700424355
1700424356
你一定会惊讶于有多少组成用户设计开发过程的细微决定完全是不自觉地产生的。大部分时候，关于用户体验的决策总会体现在以下这些场景之中：
1700424357
1700424358
▼由现状决定的设计（design by default）。这发生在当用户体验的结构遵循其背后的技术，或企业的结构时。将客户的定单记录和消费信息分别保存在独立的数据库中，也许对于你现有的技术系统是合理的，但是这并不意味着把它们从用户体验中分开也同样是一个好主意。相似地，来自企业内部不同部门的内容，也只有在放到一起而不是保持独立的时候才会更好地服务于用户。
1700424359
1700424360
▼由模仿决定的设计（design by mimicry）。这发生在当用户体验依靠于来自其他产品、公共刊物或软件应用程序的相似情况时，不管这些情况对你的用户（或甚至对网站）来讲是否确实合适。
1700424361
1700424362
▼由领导决定的设计（design by fiat）。这发生在当用户体验由个人喜好代替了用户需求或产品目标驱动体验决策的时候。如果由于某个高级副总裁很喜欢橙色，配色方案中橙色就占了主导地位，或者由于研发工程师的领导喜欢下拉菜单，结果导航元素就变成了下拉菜单的话，你可能已经忽略了应该用于驱动你所做出的决策的战略目标。
1700424363
1700424364
1700424365
1700424366
1700424367
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422513]
1700424368
用户体验要素：以用户为中心的产品设计（原书第2版） 提出正确的问题
1700424369
1700424370
面对那些设计用户体验时需要解决的纠缠不清的小问题，有时会是一件令人气馁的事情。有时某一个问题的解决办法会让你不得不重新思考你认为已经解决的其他问题。很多时候，你必须在不同的做法之间做出妥协并评估利弊和进行取舍。当你夹在不得不做出此类决定的中间左右为难的时候，不管你是否采取了正确的做法，都很容易变得沮丧和怀疑。正确的做法是，将每一个决定都建立在对其背后议题的理解之上。与用户体验有关的第一个问题恐怕是问你自己的（这也是你应该回答的第一个问题）：你为什么要这么做？
1700424371
1700424372
对于你即将面临的问题抱有一种正确的心态是最重要的。每一个用户体验的设计过程的其他方面都有可能导致调整，以适应时间、金钱和为你工作的人员。没有时间去收集你的用户数据？也许你能找到办法去看看已经拿到手的信息，比如客服的日志或反馈消息，去找到用户需求的一些感觉。负担不起租用可用性实验室的费用？那就找几个朋友、家人或同事来做一些非正式的测试。
1700424373
1700424374
不要以“节省项目时间或金钱”的名义对用户体验问题敷衍了事。在某些项目中，一些人会自作聪明地在这个过程的最末尾添加“用户体验评估”—在应该提出这些问题的时机已经过去很久以后。当发布日期确定后，你告诉自己“比赛开始以后不要顾虑太多”，这看上去好像是一个不错的主意，但这样最后很可能得到的是一个满足所有技术需求却恰恰对你的用户毫无用处的产品。甚至更糟的是，通过在结束时附加的用户体验评估，最后你可能会发布一个明知道已经被损坏却没有机会（或多余的金钱）去修复的产品。
1700424375
1700424376
一些企业很喜欢这种做法，称之为“用户接受度测试”，“接受度（acceptance）”这个词在这里的意思非常明显—问题不是说他们是否会喜欢或是否会使用这个产品，而是他们是否能接受它。这种类型的测试往往发生在整个流程的最后，在那个时候无数的假设已经在没有经过任何检查的情况下进入形成用户体验的过程中了。想在已完成的产品中通过用户测试中揭露出这些假设是极度困难的，因为它们藏在了界面和交互的外衣下面。
1700424377
1700424378
很多人提倡将用户测试作为确保良好的用户体验的一个主要手段。这种思路看上去是你应该做一些事，将它们摆到一些人的面前，来看看他们有多喜欢它，然后无论他们抱怨什么都将其修正。但是测试永远无法取代一个考虑周密的、准备充分的用户体验设计过程。
1700424379
1700424380
询问你的用户关于产品的某个具体元素的问题，能帮助你收集来自用户的更多相关信息。没有着眼于用户体验的用户测试，很可能以提出错误的问题而告终，这相反又会导致你得到错误的答案。例如，在测试原型的时候，知道要在调查中列出哪些问题是展示出你的测试主题的关键，经验是“不要用不相关的内容来把事情搞得更混乱”。导航条的问题真的只是跟颜色有关吗？还是用户对导航所使用词汇有所微辞？
1700424381
1700424382
你不能简单地依赖你的用户来阐明自己的需求。不管创建什么样的用户体验，其最大的挑战是“比用户自己更准确地去理解他们的需求”。测试可以帮助你了解用户的需求，但是它只是能达到同样的目的的许多工具之一。
1700424383
1700424384
1700424385
1700424386
1700424387
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422514]
1700424388
用户体验要素：以用户为中心的产品设计（原书第2版） 马拉松和短跑
1700424389
1700424390
就如同不应该拿用户体验的任何一部分来碰运气一样，你也不应该靠运气来完成自己的开发过程。企业中永远处在紧急情况下的开发团队太多了。每一个项目都被看成是对某些被察觉到的危机的回应，同时，这样的结果就是，每一个项目在它刚刚开始的时候就已经落后于计划了。
1700424391
1700424392
当我向客户描述问题的时候，我常常使用一个比喻来形容用户体验开发过程：它是一场“马拉松”而不是“短跑”。了解你所参加的比赛类型才能用适合的方式去参赛。
1700424393
1700424394
短跑比赛是短距离的比赛。短跑运动员必须在发令枪响起的那一刻聚集起所有储备的能量—而且他们必须要在那几分钟内迸发出所有的能量。在离开起跑线的一瞬间，短跑运动员就必须尽可能快地跑起来，并且尽可能地保持这种奔跑速度直到他到达终点线。
1700424395
1700424396
马拉松是长距离的比赛。马拉松运动员需要和短跑运动员一样的能量，但它们的使用方式是完全不同的。成功的马拉松取决于运动员如何有效地控制自己的步伐。在其他所有因素相同的情况下，运动员知道“何时加速”以及“何时减速”才更有可能赢得比赛—或者甚至彻底结束这场比赛。
1700424397
1700424398
短跑的战略（从开始到结束都要尽可能快地奔跑）显然是在这样的比赛中唯一最明智的做法。看上去你应该可以进行一场马拉松比赛，把它当成一系列全速冲刺的组合—但是这种方法是行不通的。行不通的部分原因是因为人类身体的耐力极限。这里还有另外一个因素：为了适应这个极限，马拉松运动员需要持续地监控自己的表现，密切注意哪些可行哪些不可行，并且适时地调整自己的方式。
1700424399