本节书摘来自异步社区《可用性测试手册（第2版）》一书中的第1章，第1.2节，作者【美】Jeffrey Rubin（鲁宾） , Dana Chisnell（切斯尼尔），更多章节内容可以访问云栖社区“异步社区”公众号查看
究竟是什么原因导致许多高科技产品如此难用？
接下来，我们将研究这个主题，讨论这个现象存在的原因，并全面研究问题的对策。书中很多案例不仅仅涉及消费类硬件、软件、网站，还包括用户使用手册和内嵌的电子帮助文档以及错误提示信息。解决方法一并适用于乐器、移动手机、游戏操控台，等等，甚至类似超声波影像操作平台或数码相机的用户手册都是本书涉及的范围。
导致产品可用性低下的五大原因对于当前从事产品研发的工作者，如工程师、用户界面设计师、技术协调员、培训专员、管理者等而言，导致产品或系统可用性低下的原因是如此惊人地相似。
聚焦于设备或系统的研发。目标受众的扩展与适应。可用性产品本身存在设计难点。团队内各专业人员缺乏协同。设计与技术实现的不匹配。原因一：聚焦于设备或系统的研发产品的设计和研发过程，只强调和关注设备或系统，而非最终用户。图1-1清晰地展示了用户行为的通用模型。
贝利用户行为模型指出任何类型的用户行为都由以下三大因素构成。
人群环境活动因为系统或产品的研发的目的是提升人类某个领域的表现，设计师应该在设计过程中纳入对这三个因素的思考。三个因素都将最终影响人们最终的表现。可惜，设计师、工程师、程序员只习惯聚焦在活动这个因素上，而往往不够重视人群和环境的因素。同时也忽略了三个因素相互之间的关系。出现这种不平衡的状态可能有以下原因。
一种基本的假设是因为人类与生俱来的灵活性和适应性，所以人们更容易适应设备，而反过来让设备适应人是行不通的。开发工程师历来更适应看上去“非黑即白”绝对化的、科学化的、抽象联系的系统工作。而人类的问题是灰色的、混乱而模糊的。开发工程师被任用和奖励的原因历来不是因为他们通晓人性，而是他们具备解决技术问题的能力。人的需求成为忽略因素最重要的原因是，设计师以往设计的产品面向的最终用户与他们自己非常相近。这自然没有理由去研究一个跟自己相近的人群。让我们接下来看第二个原因。原因二：目标受众的扩展与适应随着技术渗透了主流消费市场，目标受众不断壮大并持续演变。开发团队无法快速顺应这种进化。
早期数字化产品的用户（早期的尝鲜者）热衷于计算机专业知识，热爱科技、沉醉于修修补补，为自己能搞定任何问题而骄傲。这些数字化产品的开发者有着相似的特质。本质上，用户和开发者是一体的。正因为这种相似性，开发者只需要为“邻座”设计，其实就是为你身边的人做设计。毫无疑问，这种方法相对成功，用户也几乎不曾抱怨过使用障碍。
这些用户怎么可能抱怨呢？很多用户享受使用产品过程中需要付出的修补和调整。狂热的用户会因为他们能搞定复杂的产品功能而无比自豪。因此，“设备导向”或“系统导向”的方式自然而然地成为了研发标准。
而今，一切都发生了改变。用户往往对计算机和机械设备知之甚少，对购买的产品缺乏调教的耐心，已经完全与产品设计师的设想脱节。更重要的是，现在的用户远远无法毗及设计师，包括技能、资质、期望或伴随设计过程需要的任何特质。在过去，公司可能需要聘请化学博士操作他们的产品，现在他们会找高中毕业生来完成同样的操作。显然，“邻座”设计方法在面临用户和设计师之间巨大差距时荡然失效。一些忽略趋势的公司继续秉承这一策略，将持续生产出可用性低下的产品。
设计师也不再是爱好驱动的狂热份子。大多数设计师接受过专业的人机交互、工业设计、人因工程学、计算机科学或混合型学科的教育。那些曾经让不谙技术的人望而却步的电子化或数字化设备，而今却不可避免地被普通用户在工作或生活中接触和使用。那些无论是在工作，还是生活中举足轻重的大众化产品，如手机、数码录像机、网站或精密的测试仪器，他们的用户都不具备技术素养。当今的用户需要的是一个工具而非一种爱好。
原因三：可用性产品本身存在设计难点尽管很多组织将设计可用的系统视为“常识”，但它的困难却难以预测。
虽然有很多著作提及可用性的方法论，但对于不具有行为学和社会学背景的人而言，却是难以参透的概念。可用性定义以及如何获得可用性，既是艺术问题，也是科学问题。似乎每个人对于可用性都有一个概念和实施方法。直到可用性可被衡量，才跳出了概念的范畴（这需要可执行的定义和精确的测量）。
比起抛弃可用性原则的设计师而言，轻视可用性原则更加危险，因为这会招至更坏的结果。正如Will Rogers所说：“产生问题的原因不是你无知的部分，而是你以为自己知道的部分。”很多组织已然将可用性工程漠视为“常识”。
本书在1994年首次出版时，没多少系统设计者和开发者了解以用户为 中心的设计原则。现在，多数设计师或多或少了解以用户为中心的设计原则，至少是有所耳闻。然而，认知和实践之间仍然存在着鸿沟。可用性准则不够 明晰，依然需要教育、辅助设备和系统化方法来共同运用设计过程中这所谓的“常识”。
原因四：团队内专业人员缺乏协同组织招聘专业化团队完成产品和系统的研发，却忽视了成员间的相互协同。
出于提升效率的目的，很多组织将生产流程拆分成相互独立运作的系统元素。例如，软件开发的组成要素包括用户界面、帮助系统和书面文档。诚然，这些要素由独立的个人或团队研发。专业化分工本身没有问题。问题在于独立要素之间缺乏协同融合，不同研发团队间沟通不足。
通常产品研发在独立拆分的部门之间推进。在外界看来，研发的结果会被感知成图1-2所示的结果。
每个研发组像地窖一般独立运作，最终的产品也反映了这个过程。帮助中心不能给到用户界面这一层足够的支持，甚至与用户界面设计背道而驰。用户帮助文档因为缺乏交叉索引而出奇地冗长。亦或文档呈现的内容已与最新版用户界面脱节。这些都可想而知。
产品发布后问题产生了。最终用户面对新产品时，期望它作为一个整体工作。如图1-3所示。用户不会刻意区分这三个部分。用户预期产品的每个部分都应该紧密配合在一起。即便产品有诸多专业化的优势，也会因为无法满足用户预期而失败。
有意思的是，组织在不经意间加剧了割裂的状态。他们将产品的各个要素独立进行可用性测试。用户文档独立于用户界面作测试，用户界面也独立于帮助测试。这个方法最终将无济于事，因为自身可用并不意味什么。只有产品的各要素配合良好，才能真正满足用户需求。
所幸，近年研发方法体系有了长足的进步，开始不断强调设计迭代和团队跨学科构成。此外，大量以可用性理念指导下产生的无边界的产品和服务案例，在市场上获得了巨大的成功，如Netflix、eBay、Yahoo！、iPod及iPhone、Whirlpool（惠而浦）家用电器最新产品线。它们成功的最大因素是协同研发。
原因五：团队内专业人员缺乏协同用户页面的设计和技术实现是两种不同的活动，需要截然不同的技能。现今人们更强调和需要设计技能，而技术实现需要另一种思维模式和技术模式为主导。
设计关注产品沟通方式，技术实现则关注产品运作方式。早期设计和开发的分歧还罕为人知。早期，工程师和设计师被雇佣都是因为他们的技术专长（编程和机器导向的思维）而非设计专长（信息沟通和用户导向的思维）。这是因为早期利用计算机编程语言完成产品设计是项很大的挑战，所以情有可原。当然，优雅沟通可以带来更好的效果，但它不是当时的最高指导原则。
随着新一代编程语言的发展以及自动化编程工具的产生，技术实现的挑战骤然减小。而为了满足日益增长的用户规模，适应他们经验不足、对可用性期待较高的特质，设计的挑战陡然增加。就拿计算机做类比，工作的焦点已经从设备内部（机器如何运行）转移至外围的最终用户（如何与产品交互）。
工作焦点的转移也趋使设计师技能的变化。设计将逐渐从技术实现中脱离出来。或许有一天，在设计用户界面时将完全不需要编写代码。
上述 5 个原因只不过初略地阐释了缺乏可用性的产品和系统不断出现的原因。更重要的是，这些问题和误区背后有着共同的主题：过于强调产品本身而忽视了产品本身应该实现的预期效果。尤其当开发周期变得愈发短促而忙乱，对用户的关注和理解就更愈发少了。
设计师容易对产品设计的本质失察，同时更容易忘记他们正在创建一种产品与人的关系。此外，为了设计这种关系，设计师必须允许用户专注于手头的任务，帮助他们达成目标而不是让用户关注完成任务的方法。设计师同时需要设计各个产品相互配合的关系。这意味着设计的实体之间可以无间地沟通，同时需要扩大体验维度，卷入产品的整个使用周期或工作场景。曾经的工作模式已经无法适应当今的用户和技术了。
我们需要新的方法和技术，帮助设计师转变视角和方法。这种由外及内的，适应最终用户的需求和能力的工作方法，就是以用户为中心的设计方法。基于以用户为中心的前提，可用性测试才体现价值并得以发展。后面会更详尽地探讨关于以用户为中心的理念。
相关资源：敏捷开发V1.0.pptx