--------------------
第一章：目标导向设计
--------------------
我们的书有一个简单的前提，如果我们把达到用户的目标作为设计过程的基础，用户就会满意并快乐。如果用户快乐，他就会乐于付给我们钱（并且推荐其他人这么作），这样我们就会事业有成。
从表面上看，这个假设实在是显而易见甚至有些直白：让用户快乐，你的产品就会成功。那为什么还有这么多的数字产品如此的难用和讨厌呢？为什么我们并不全都是快乐、或者成功的，或者既快乐又成功呢？
---------------------------
数字产品需要更好的设计方法
---------------------------
现在的很多数字产品从开发流程中产生的方式就像是妖怪从溢着泡沫的桶中出现一样。开发者，代替他们的用户在脑子里进行计划和假想运行的方式，最终在他们终于可以有一点控制里的技术上形成一个解决方案。就像是疯狂的科学家一样，他们失败因为他们没有在创造物中注入人性。
设计，按照工业设计家Victor Papanek的定义，是有意或直觉的努力以改进有意义的顺序。作者准备了一个更加仔细的定义：
●理解用户的希望、需要、动机和上下文
●理解商业、技术和问题领域的需求和约束
●在商业可行性和技术可行性的基础上，把前两点的知识转换成为产品计划（或者产品本书），使产品的形式，内容和行为有用、可用而且赏心悦目
这些要求对于所有的设计学科都是适用的，尽管对于不同的设计学科更加关注外观还是内容还是行为会有所不同。
当采用恰当的方法，设计可以给技术产品提供目前所缺失的人性交流。但是显而易见，现在进行数字产品的方法或者无法实行或者无法达到宣称的效果。
-----------------------------
目前的数字产品设计
-----------------------------
大部分的数字产品都是以工程师的视角进行构建的。的确，市场人员有时候会提供需求，但是他们很少去研究用户实际的需要，而更多的是与竞争对手攀比着将特性列表提供给IT人员，或者在用户调查或客户希望列表的基础上进行猜测。这些方法都无助于系统的构造产品以达到用户的目标。下面我们将讨论为什么目标如此的重要。
开发人员和用户有着完全不同的，以技术和工程方法为中心的价值观。而同时，市场人员关注的是那些可以引起注意的事情，特性列表，和人们说他们会买的功能。用户，如果你问和他们正在使用的产品直接相关的问题，一般关注的是低层面的任务——与你猜测的相反，很少有用户确切的知道并清楚的表达他们的目标。
这样作的结果是，很不幸，软件扰乱并减少生产力，无法满足用户的需求。图1-1显示了软件开发过程的演变，并且包括了演变最终完善时设计的参与。大部分的数字产品的开发还在第一个、或第二、三个柱状图所表现的步骤，这时候设计并没有扮演实际的角色或者只是在一个糟糕的交互上作些表面文章——用作者的一个客户的话来说，就象“猪嘴上的口红”。我们将会讨论，设计过程，应该在编码和测试前就确认产品的确满足了用户的要求。
软件开发过程的演变
1，最初，程序员作所有的事：
在软件产业的最初的日子，聪明的程序员空想出有用的软件并编写它，然后甚至自己测试它。但是随着商业化增长，软件商业和软件生产变得更加复杂。
2，经理带来秩序：
不可避免的，专业的经理人产生了。优秀的产品经理理解市场和竞争者。他们通过建立需求文档定义软件产品。不过，一般来说需求文档都不比一个特性列表更多什么内容，而且经理发现他们不得不为了赶上进度放弃特性。
3，测试和设计成为独立的步骤：
随着产业的成熟，测试成为了独立的学科和过程中的独立步骤。在从命令行方式向图形用户界面的转化中，设计和可用性业被包括在过程中，虽然经常仅仅事在过程的结尾，并且经常只对外观起作用。现在，通常的实践包括同时进行的编码和设计以及后续的bug和用户测试与修正。
4，设计必须在编程开始前进行：
目标驱动方式的软件开发意味着，所有的决定都出自正式定义的用户和他/她的目标。定义用户和用户目标事设计者的责任——因而设计必须在程序编写前进行。
图1-1：软件开发过程的演变。现在，设计往往是补救手段。它应该在编码和测试前就进行。
下面是一些例子用来说明为什么仅仅关注于技术、市场和任务（而非为用户和用户的目标进行设计）导致我们都觉得不满（？）的软件产生。
软件是粗鲁的
软件经常粗鲁的对待用户。它因为用户犯了错责备他们，这些错误并非由于用户的过失而造成，或者根本不应该因为用户的过失而发生。象图1-2那样的消息框如同丧服一样的跳出来，宣告用户又一次失败了。而且这个消息还需要用户承认他的失败，用OK来表示赞同。
图1-2：多谢通知我。可是为什么程序不通知库？它希望通知库什么？它为什么不告诉我们？我们为什么要关心这个？而且为什么我们要OK？程序失败一点也不OK！
软件常常审问用户，用户并不希望回答也没有准备回答的语焉不详的问题：“你把文件藏在哪里？”；居高临下的问题比如“你确定么？”和“你真的想删除这个文件么，或者你还有一些其他的按Delete键的理由？”同辣椒水一样灌给用户，将他们摆在不平等的被贬低的位置。
软件作出无根据的猜测
软件还经常假设它的用户都是电脑专家。比如，当一个用户编辑完一个文档关闭它的时候，程序会问是否他想要保存文件。关于这个问题的技术并不简单。对于CPU可以直接访问的RAM不得不作这项工作，但是电脑的初级用户又怎么能知道呢？
软件是晦涩难懂的
软件常常是晦涩的，对用户隐藏它的用意、目的和动作。程序经常用普通用户根本不能理解的行话表达自己，比如“结束位是多少？”（How many stop bits?）有时候甚至是更加专业的“请指定IRQ.”。
特性隐藏在菜单对话框和窗口的遮蔽之下。用户怎么能知道在帮助系统中能找到答案？如果他连帮助系统都找不到。就算用户找到了正确的对话框，他会发现在上面排放的净是语焉不详的缩写，晦涩的命令和难以捉摸的图标。
比你猜想的还要多的是，软件要求用户回答难以选择的问题，却不先告诉他们作不同回答的效果是什么。比如，用户怎么可能决定是完全安装、定制安装还是膝上电脑型安装，在不告诉他不同的选择在功能和硬盘空间上的区别的时候？
软件举止不当
如果一个10岁的儿童象有的软件那么做事，他肯定会被关在房间里不许吃晚饭。程序忘记随手关门，把鞋子丢在房子中间，记不住你在5分钟前告诉他的话。比如，如果你保存一个Word文档，打印它，然后关闭，程序会再次问你是否要保存！很明显，打印这个动作让程序认为文档被改变了就算它其实并没有变化。哦对不起，妈妈，我没听见你说什么？
程序经常要我们停下主要的任务流程，去完成一些本来就应该手头就能得到功能。
危险的命令却经常被摆在最前面，毫无戒心的用户一不小心就可能触发它们。很多程序的整体外观都过分的复杂和混乱，让人难以理出头绪进行理解。
那么，这是不是的确存在问题呢？为什么技术产业在交互产品的设计上有这样的问题呢？
我们对用户一无所知
非常不幸的现实是数字技术产业对怎么取悦用户并没有什么理解。事实上，大部分的技术产品都是在对用户没有什么理解的基础上构建的。也许，市场部门会对用户进行划分，他们挣多少钱，他们在周末花多少钱，他们买什么款型的车。也许我们还会对他们作什么样的工作和他们经常性的主要任务有一个模糊的概念。但是，这所有的一切是否告诉了我们怎么让他们开心？是否告诉我们他们会怎么样实际的使用我们构建的产品？是否告诉我们为什么他们需要我们的产品去作一些事，为什么他们选择了我们的产品而不是我们的竞争对手的，或者，我们怎么样才能让他们选择我们的产品？很不幸，我们得不到这些答案。
我们后面将会讨论理解客户以及他们使用产品的行为。
我们有着利益冲突
其次，造成供应商和厂商不能取悦客户的一个问题是，在数字产品的开发世界中有着严重的利益冲突：程序员，构建产品的人，一般也是设计产品的人。程序员往往需要在方便编码还是方便使用之间进行选择。而程序员的工作成果一般是由有效率的编码并赶上不可思议的紧迫的最后期限来判断的，那么不难得出大部分的软件产品是如何取舍的了。就像我们永远也不会允许一个人去审批涉及他自己的案件，我们也应该确保设计产品和建造的不是相同的人。让程序员同时兼顾用户、商业和技术显然是不可能的。
我们缺乏过程
最后，数字技术产业不能产生成功的产品是因为没有可靠的流程去生成产品。更确切的说，没有完整的流程。工程人员遵循（或者说应该遵循）严格的工程方法来保证技术上的可行性和质量。同样，市场、销售和其他商业人员按照他们的制订好的方法确保新产品商业上的活力。缺乏的是一个可重复、可分析的过程，把对用户的理解转换到产品中用来满足用户的需求并激发他们的想象。
当我们想到复杂的机械设备的时候，我们会发现它们在工程设计的基础上仔细的为使用进行过设计。大部分的人造物品是简单的，就算是复杂的机械产品于大部分的软件或软件操作的产品相比较也是很简单的，很多软件可以无节制的扩充到百万行代码（与之相比较，一个无法想象的复杂的机械产品，比如航天飞机，也只有250,000个部件，其中只有很小的一部分是可动部件）。以用户为中心的严格设计方法是不能接受大部分的软件的。
目前决定软件作什么和它如何与用户交互的过程是和软件构建紧密相关的。深现在算法和代码的思考中的程序员，“设计”用户界面的方法，就和矿工“设计”矿坑以及废土堆的形状一样。软件界面设计的过程不是根本不存在就是意外进行的。
现在的很多程序员都抱有这样的观点，让用户经常性的，每周一次——或者更加频繁的每天直接参与到编程过程中，可以解决设计问题。通过与用户分担设计的责任的确可以有好的效果，不过这种做法有着重要的方法学纰漏：在设计领域知识的混淆。用户，虽然他们可以说出一个交互中的问题，但未必有能力指出解决的方法。设计是一项专门的技术，就像编程一样。程序员绝对不会要求用户来帮他编码的，设计也应该如此。
要了解如何创建可行的用户为中心的软件设计过程，我们需要了解一些制造业设计的历史，以及交互产品在设计方面面临什么完全不同的挑战。
