《交互设计之路》读书笔记

作者名为Alan Copper，被称为VB之父，是可视化编程思想的发明者。其将VB推荐给了Bill Gates。后其个人成立产品设计公司，专门为高科技产品公司进行产品设计。本文总结了一些Copper在交互设计之路一书的一些思想。如果不愿意精读这本书，理解这下面这段话即可。

软件产品要想成功，必须经过产品经理的市场调研，即商业可行性分析。在验证了商业可行之后，由设计师进行用户角色分析，找到用户角色表，并关注首要角色。在此基础上进行交互设计和视觉设计，同时在设计中协同研发人员确认设计的实现成本，并评估最佳的设计，输出生成高保真的产品原型，交由用户进行可用性测试并改进。经过几轮迭代，达到使用预期后，再付诸于软件开发。

第一篇

各种设备都开始集成计算机，然而很多产品在使用上并没有变得更智能，相反在易用性上更难使用，使得某些智能功能无法使用。例如 微波炉的加热方式，是选大火5分钟，还是小火10分钟？通常，多数人需要盯着炉内的食物，并随时打开炉门，不断的看食物是否热熟。然而，对于飞机或汽车自动导航等软件，某些易用性问题，可能导致重大的损失。

第二篇

1 软件系统的问题

1,1 软件健忘
  人会渐渐熟悉软件的使用，但软件反过来却无法学习使用者的习惯。目前基于推荐的Web具有一定的改善
1.2 软件懒惰
  多数软件不努力为使用者工作，而是按照程序员设定的方式去取悦使用者。如果让程序员努力做使用者真正要求的东西 ，则更容易让使用者成功。
1.3 软件吝于提供信息
  多数交互产品对于信息非常吝啬，导致用户通常无法确定系统的状态，直到突然出错使得整个事务失败。
1.4 软件系统不如人工系统灵活
  这点没什么好说的，人工可以随意的安排工作计划，但软件是固化的工作流，不会处理固化功能之外的东西。
1.5 软件出错直接报怨使用者
  同时不会补偿使用者，这与人之间的系统完全不同。
1.6 软件不用负责任
  当执行错误指令后，软件不需要负责任，而由操作者承担责任。而更好的作法是软件可以回退操作，从而承担责任。

2 软件产品的成功之路
  分析用户 期望 ，研发人员通过技术将期望变为 可能 ，销售人员将期望变为 可行。
  期望 不同于 需求，需求相对是刚性的，而期望是相对弱。但是，期望会影响人的长期行为模式，而需求会对人形成短期强烈影响。
  如果市场上有同类产品，则需求已经被满足了，后来的公司只能从设计上做的更好，满足用户的期望，才有可能取得成功，仓促及推出市场但设计不足，是不会占有市场的。

第三篇

Copper认为，是技术的使用过程导致产品没有人性，而并非技术导致了产品缺少人性。是不重视设计，由程序员做设计导致产品没有人性。

1 研发不能做设计
  作者把目前软件产品设计不足的问题归咎于开发人员占据了主导地位，并将之描述为由精神病人管理着的精神病院。
  这种主导地位的出现，是由于过去软件成本远高于人使用成本，而在目前软件成本大幅下降的情况下，产品更好用则意味着成本更低。
  由于研发人员的方法、训练、天性不适合做设计工作，更被束缚在 满足用户需求和 让编程更容易的矛盾中。开发人员长时间的与计算机交互，在技术上为功能做设计，但为人做设计却需要完全不同的理念。
  而作为交互设计师，不仅要理解用户的心理，也要了解程序员的心理。

2 程序员的心理
2.1 牺牲简单换取控制权。
  程序员更满足于控制复杂的计算机而不是人。获取控制权是目标，而掌握复杂性是代价。对于普通人，简单是目标，他们愿意放弃控制权。

2.2 牺牲成功换取认知
  程序员为了能理解复杂事物的内部机制，愿意接受失败的结果。小孩折手表便是这种模式的先奏。更严重的，程序员将其他人不愿意理解复杂视为无能。

2.3 只关心可能性而不考虑概率
  在程序的编写中，无论事件发生的概率有多小，都会充分考虑并解决。可正确运行两次的代码和运行两亿次的代码需要相同的正确性。对于交互性的影响就是导致出现过多没有必要的选项及功能。例如要求用户选择存储复本的数量。

2.4 以智商定高下
程序员通常以智力为标准来衡量其他人，在其领域内，其他没有竞争力的人都不会被接受，他们不会顾及到能力不及他们的人的感受和其他长处。例如不同语言之争体现的就是这种问题。但这种以智力为标准的歧视或控制能力居然被社会认同，人们可以嘲笑不会使用计算机的人。(因而管理程序员必须熟知和尊重程序员)

3 程序员文化

3.1 看重研发价值

  认为代码重用的价值高于实现用户功能，而且程度员的文化在所有地方都是共同的，比如看不起非程序员，如产品、设计，甚至看不起使用更低级语言的人。

3.2 文化分隔性
  由于分工的不同，研发、产品和技术支持面对的客户是不同的。通常，技术支持对用户的理解最正确，但研发和产品却对设计具有更大的控制权。有点像盲人摸象。大部分公司都存在着所谓的工程师文化或产品文化，然而这两者是严重割裂的。

3.3 责任重大

   编程是一种需要集中精力和时间才能做好的事情，同时理解别人的代码花的时间可能比编写代码花的时间还多。因而老板虽然要求质量，却很难投入时间去检查质量。最终导致程序员要对产品的成败全权负责。
   对于有责任心的程序员，渐渐便会生成较为独立的意识。通常如果由非开发人员提出的意见，程序员都会提出质疑，因为如果因为接受其建议而最终产品失败，承担责任也只有程序员。
   要改变程序员的行为，必须先改变程序员的认识。不能要求，也不能请求，必须由拥有利害关系的人提出，并且提供合理而有根据的理由。

3.4  易陷入稀缺性思维

  由于摩尔定律的作用，硬件速度每18个月就会提升一倍，但研发人员通常仍会陷于稀缺性思维。做出对CPU友好，对用户残忍的功能（当然，这也是由于无法预知程序将在何种类型的设备上运行而导致的，在2013年里Android开发便会遇到这种情况，需要适配各种性能和大小的手持设备）。

第四篇 交互设计

1 定义人物角色
   通过人物角色，精确描述用户和用户想要完成的事，技巧在于如何确定和使用这些描述。(其实在RUP中，早已有使用用例和用户角色来描述相同的概念；同样在Scrum中，也必须先定义用户角色，才有用户故事)。需要注意的是角色的精确度比正确更重要。
  只为一个用户设计，而不是将不同用户的需求混合在一个产品中。不要使用用户来定义需求，用户是弹性的，而人物角色不是弹性的。精确的定义用户角色是抑制程序员曲解用户角色的关键，也是交互设计的有效工具。
  确定首要用户角色是非常重要的，通常每个首要角色需要独立的操作界面。
  注意，我们应该重视用户，但不要让用户直接影响解决方案。

2 定义角色目标

 

   良好交互设计的本质是，设计的交互能力可以支持使用者达到实际目标，但不影响个人目标。

   首先，需要区分的是目标和任务，目标是终极的，而任务是为了达成目标而需要解决的问题。通常目标具有令人愉悦的属性，而任务则会随着技术的发展而变化。例如从北京到上海，目标是快速到达。在古代任务是骑马狂奔，而现在则需要去机场坐飞机。由于目标需要通过任务来达成，在软件中就是通过程序代码来实现，因而程序员考虑问题的角度就是从任务出发。我们需要交互设计师从目标出发，做出不同的，但更令人满意的设计。

  其次，需要区分个人目标和实际目标。实际目标是最终目标，而个人目标则是在完成最终目标过程中，个人追求的另外一些内容，如乐趣、快感等。比如健身是最终目标，而在健身过程中是享受还是遭罪，则会影响个人目标的达成。

   个人目标包含以下内容：不觉得让人愚蠢（浪费时间）、不出现差错、不乏味、完成适量的工作。
   企业目标是企业对软件的要求。包含以下内容：增加利润、增加市场份额、击败对手、更多的职员、更多的产品和服务、上市等。
   实际目标是各个企业员工工作要达成的目标。包含以下内容：避免会议、完成工作任务。
   企业目标和实际目标都要通过人来实现，因而个人目标会起主导作用。通常程序员会着力创建完成实际的软件，但却不能满足个人目标。相反如果只满足个人目标，但不能满足实际目标，软件就变成游戏了。

   程序员可能基于下面的错误目标来构建程序：节省内存、减少击键次数、在浏览器中运行、容易学习、保证数据完整性、提高录入速度、提高程序执行效率、增强美感、在多平台间保持一致。

3 为人而设计

为礼貌而设计，交互要对人尊重，宽厚，富有帮助，也就是要懂礼貌，这样使用者才会喜欢这个软件。
礼貌的软件包含以下特性：

对使用者感兴趣，软件要建立使用者的统计模型，学习使用者的习惯
尊重使用者，主动提供帮助
拥有常识，常用和不常用的功能将分开使用
预知使用者的需要
反应敏捷
自己解决内部的问题，不把用户不关注的内部状态暴露出来
提供有用的信息
有洞察力
有自信，不需要人的重复确认，当在人真的出错时才确认，即使是错了，也可以恢复原来的状态。
专注
灵活应变
让人信任

4 场景

  在确定了用户角色和目标以后，我们加入场景，在场景中对任务进行检查，让角色在场景中表演。重点工作应该放在可以深化设计的场景，并避免陷入边缘状况。只需要编写日常场景和必要场景。

   日常场景最有用，也最重要。它们是使用者需要经常执行的主要任务。通常使用者只有有限的日常场景。这种场景由于经常使用，必须支持快捷的交互。
   必要场景是那些不常用，但必须有的场景。这些场景使用较少，即使复杂些用户也可以接受。
   边缘场景，那些很少出现的场景。设计可以忽视之。但程序实现必须做好。处理边缘场景的能力，决定了程序的成败；而处理日常场景和必要场景的能力，决定了产品的成败。

  使用曲折界面：通过将常用的操作放在显著位置，而将不常用的操作放在不显著的地方，可以改善拥有众多功能的界面。

   永久的中间用户：程序员通常设计给专家来使用，而销售人员则建议给初学者使用，这样大量处于中间地带的用户永远得不到关注。交互应该为中间/中级用户而设计。他们会每天重复使用相同的功能多次。

   使用魔法电脑。有时设计可能无法被开发人员所实现，但在思考设计时尽量不考虑技术实现，假设一台有魔法的电脑可以突破目前的限制，这样允许我们避开所假设条件，可以更清晰地看到角色和目标，以想像那些通过传统方式无法得到的解决方案。更多的时候，我们会发现限制是幻觉，是我们自己加上去的，只有我们绕过它们后才能看清楚这些。

第五篇

1 如果只有一部分

   作者认为，可用性测试就像砂纸，只能让做好的桌子更光滑。如果只在开发结束之后才关注可用性，就是希望让砂纸把一个板凳打磨成桌子，是不可能的事情。
 
   同时将各种角色，如用户、开发、设计师，简单的放到一个团队，并不能解决问题，大家关注点不同，如果不解决开发流程的问题，就解决不了用户目标这个根本问题。

 

   一些程序员会意识到设计的重要性，但多数是从设计人员会侵占开发的势力范围角度来考虑的，这部分人会认为，如果设计先于开发，那么程序员的重要性就会下降，如果由开发人员自己进行设计，那么就能巩固自己对最终产品的控制权。然而这种向设计的努力是注定不会有成效的，除非开发人员彻底放弃编程工作，由理性思维质变为的感性、想像等思维方式。

  

   如果软件只注重视觉方面的体验，会产生花哨的界面，不实用的功能，低效的交互性软件。

   迭代确实是良好设计的重要因素：不断改进，直到得到正确的结果。但很多产品经理和开发人员将其理解成，扔出一个版本，然后在黑暗中横冲直撞就能成功。现实中则是新版本收集了众多的用户需求，下个版本增加用户需求，不断打补丁，最终生成一个满足用户最低使用标准的版本。然后在此基础上再进行优化。作者认为，通过迭代永远无法创建出最优秀的产品。因为它需要消耗巨大的时间、金钱和人力，同时不断虐待使用电脑技术的人。

 2 管理开发过程

  首先，要倾听用户意见，但不要听从用户意见。听从用户会使得设计的概念完整性受损，使得一个愿景驱动的公司变成客户驱动公司，如同一个产品公司转变成服务公司。如果成为客户驱动的服务，短期内赚钱比较容易，但是会停止成长，等于放弃了未来。这在找工作时一样，你是出卖的解决问题的能力，还是出卖过去解决问题的经验。

  产品经理的职责就是保持技术领先，避免客户驱动死亡螺旋。必须像刚起步时一样，在内部寻找答案。这意味着远见、责任心、付出时间、进行控制。当然这几点都需要更高管理层的支持。

所谓远见，就是为了保持竞争力，必须不关注短期收益。远离一结利润很高的交易。
所谓责任，就是必须在第一天建立长期利益和短期利益的平衡，这将成为基因沉淀在新公司的文化中。否则后面就无法建立了。
时间付出，就是必须推迟产品的面市时间，在开发之前先完成设计，而不是为了节约人力，将设计和开发并行进行。作者认为前期设计工作的时间花费更值得，成本更小。中期大规模开发实现的成本将会大很多。
所谓控制，就是要从客户手中夺回开发过程的控制权，平衡长期和短期工作。

 
 最后，作者希望，由交互设计承担起产品成败的责任。