第九章
- 最显而易见的方法：找出实际用户并向他们提问。这其实并没有多少效果。原因是问题的受害者不会自动知道解决问题的方法。实际用户是宝贵的资源，我们应该在他们身上多花些精力，但是不要让用户直接影响解决方案。
- 如果想让一种产品满足广大用户，逻辑告诉我们应该在产品中提供很多功能。然而这种逻辑是错误的。实际上，只为一个人设计的产品成功机会要大得多。比如为很多人设计一种汽车。住在郊区的妈妈期望拥有一辆空间和车门足够大，安全、稳定的车。木匠期望拥有一辆结实耐用的车，有足够的空间运载梯子、木材和工具。年轻主管期望拥有一辆动力强劲，悬挂系统坚韧，顶篷可移动，够两人乘坐即可的跑车。合乎逻辑的解决方案是满足每类用户需求的结合体：一个可以移动的顶篷，供孩子活动的封闭空间，还有堆放杂物的开放空间。多么愚蠢，多么不可思议的车呀。即使有人生产出来也没人要。正确的做法是，为妈妈设计一辆微型面包车，为木匠设计一辆轻型卡车，为主管设计一辆跑车。
- 开发三种软件产品要比制作三种汽车要容易得多。但一种软件通过配置就可以看起来像三种不同的产品，不过要注意别把配置工作推给用户。
- 每一次为另外一些用户添加功能，就相当于为其他用户设置了障碍。你会发现，让一些用户喜爱的功能对其他用户没有什么帮助。帮让更多用户喜爱的结果可能会将一个潜在的好产品置于死地。然而，如果将设计目标锁定在一个角色，那么这个角色的人群会对你的产品相当满意。
- 目标用户越多，偏移目标的可能性越大。瞄准10%的市场，让他们成为产品的狂热追随者，你能获得巨大的成功。这似乎有悖常理，但是只为一个人设计是让大众满意的最有效方法。
- 开心的用户是非常有效而有价值的资产。通过将目标聚集在一小群用户，你可以在目标市场中建立狂热的用户忠诚度。忠诚的客户不仅会跋山涉水来购买你的产品，他们还是最有力的营销工具。忠诚的客户会将你的产品介绍给他们的朋友。当你的产品开始走俏时，就可以靠它将产品延伸到别的市场。
- 让用户满意是我们的目标，但是“用户”一词会带来麻烦。由于它不够精确，不能用来设计，就像电锯虽然可以用来锯任何东西，但是我们不能用它来切除阑尾。我们需要更精确的设计工具。
- 为弹性用户设计等于给了程序员根据自己需要随意编程的许可。真正的用户不是弹性的。在我们的设计过程中，我们从不使用“用户”一词，我们用“人物角色”一词指定某个具体的人物。我们的人物角色越具体，它们作为工具就越有效。这是因为角色变得具体后就失去了弹性。
- 如果一个角色是护士，我会让她是女性而不是男性。这并不是因为没有男性护士，而是因为绝大多数护士是女性。如果一个角色是计算机技术人员，我们将把角色叫做Nick，23岁，脸上长着青春痘，在高中时代是视听俱乐部的成员，而不是叫做Hellene，一个5英尺11英寸，身材苗条，曾在好莱坞Beverly Hills高中念过书的女孩。我更侧重可信度，而不是多样性。
- 让人感觉真实，定义完整的用户角色是非常有力的工具。在用户得到精确地定义之前，程序员总是将自己想像成用户，或者让用户富有弹性。完整定义的角色，是抑制程序员曲解用户角色作用的关键所在。在远未开始编程之前，定义良好的用户角色就能成为交互设计非常有效的工具。
- 不要将精确的用户分类与真实人物混淆起来，真实人物带有干扰设计过程的不良嗜好和特殊行为，这些特点并不适用于同一类的其他人。比如总经理容易犯这样的错误，他不喜欢用键盘完成工作，于是要求自己公司制作的所有软件都只能通过鼠标来操作。只想用鼠标控制软件是合理的，但是排斥那些喜欢用键盘操作的人就有些不近情理了。
- 作为设计工具，让角色精确比让角色正确更为重要。就是说，详尽而具体地定义角色比让角色非常正确更为重要。例如我们要设计一个拉杆箱，三个人，A是波音747的机长（长途飞行），B是飞行学院学员（驾驶小飞机，天天飞行，但从不离家住宿），C是航空公司乘务员（长途飞行）。程序员非常关心边际状况，这会影响他们对角色的选择过程。他们会主张将B作为一个有效角色，因为他是飞行员。但从行李的角度看，B属于边缘状况。不管编程是不是在范例的边缘定义，而设计却是在中心定义的。如果怀疑一个角色与中心是否足够接近，这个角色就不应该放在考虑范围之内。
- 在定义角色时我们追求精确，但是我们要排除平均状况。例如平均每个家庭有2.3个孩子，但没有一家实际拥有2.3个孩子。更有用的表达式是：Samuel有两个孩子，或者Wells有三个孩子。Samuel是一个人，因而有用。对，他是假想人物，但是很具体。拥有2.3个孩子的父亲不可能具体，因为他不可能实际拥有2.3个孩子。
- 角色是我们最有力的设计工具。它是所有后续目标导向设计的基础。角色让我们看到设计问题的范围和性质。角色清晰地提示用户目标，因而我闪能看到产品必须做的事情，同时我们也清楚产品不该做什么。精确定义的角色准确地告诉我们用户的电脑操作水平，因而我们不会在为专家设计还是为新手设计的抉择之间犹豫不决。
- 角色的真正价值之一，是它让电脑操作水平的讨论有了现实意义。用户操作水平的范围很宽，角色让操作水平变得很具体。
- 让设计团队的每一个人都熟悉每一个角色非常重要，还应该让每一个角色有很强的真实感，真实得就像开发团队的一个成员。
- 程序员：“如果用户想打印这个怎么办？”经理：“我觉得我们真的不需要在第一个版本中加入打印功能。”程序员：“但是有人可能要打印这个。”经理：“嗯，是，不过我们就不能推迟打印功能的加入吗？”经理无法说服程序员，因为他没有给出充分的理由。程序员的“事情有可能发生”的逻辑是不可抗拒的。
- 程序员：“如果用户想打印这个怎么办？”交互设计师：“Rosemary对打印这东西不感兴趣。”程序员：“但是有人可能想打印。”交互设计师：“可我们是为Rosemary设计的，而不是某人。”在此，双方不分胜负。程序员还在使用“用户”一词，依旧在可能性世界里思考。然而，我们的Rosemary角色不是随便设置的。她是具有一定技能和目标的具体人物。我们终于有了具有说服力的论据。
- 我们的设计师在表达设计思想时坚定地使用角色名称。我们绝不使用“用户”这样通用名称。我们不让程序员或其他任何人使用“用户”一词。经过一段时间的坚持，我们会有收获，程序员们开始接受角色并使用角色名称。一旦程序员们开始自愿使用角色名称，设计师与程序员之间的协作的性质就发生了根本性的变化。
- 程序员：“Rosemary会想打印这个吗？”交互设计师：“不，不过Jacob需要一个季度打印一次报告。”程序员：“那好，既然他们很少打印，让我们节省一些时间和精力。让我们购买现成的商业打印程序许可，不要去编写花哨的打印功能。”经理：“那我们的计划可以缩减两个星期了。”以前他们陷入无休止的功能争吵，一些似乎已经解决的问题，会在每两周内提出来重新讨论。过后，设计问题会再度提起，再度回答，然后忽视。 现在，问题解决了。
- 在信息技术领域，负责购买产品的IT经理很少是实际使用产品的人。在电脑领域，为购买者设计是常犯的错误。虽然我们不应该忽视IT经理的需要，但如果产品能让实际使用者高兴，IT经理会更高兴。毕竟，实际使用者高兴而且提高工作效率，意味着IT经理的成功。
- 每份角色表至少有一个首要人物角色。首要人物角色是设计为之服务的中心人物，这个角色的目标必须得到满足，但是不能通过为其他角色设计的界面来满足。首要角色应该有专门为他设计的操作界面。在编制角色表时，确定首要角色是非常重要的一步。每一个首要角色需要独立的操作界面。如果有两个首要角色，我们将会设计两个操作界面。如果有三个首要角色，我们将会设计三个操作界面。如果有四个首要角色，我们将会面临巨大的困难。如果首要人物角色超过三个，就意味着我们的问题过于庞大，我们在试图一下子完成太多的事情。创建角色可以限制我们实际为他们进行设计的用户类别。如果角色过多，我们引入角色的意义也就失去了。
- 有良好的设计，但是不用角色表达的做法是不可取的。人们太容易回到“用户”这个词语的使用，并将关注点从特定类型的用户移开。