1993年由克莱顿.刘易斯和约翰.黎曼提出了“以任务为中心”的设计模型（Task-Centered-System-Design，TCSD）中，设计过程分为了四个阶段——

• 第一阶段，识别用户和任务，即通过用户访谈和自然观察等手段确认任务，然后形成任务描述文档，最后验证任务并进行反馈修改；
• 第二阶段，以任务为中心的需求分析，即确定系统支持的用户类型和任务类型；

• 第三阶段，基于情景的界面设计，即构思一个情景，设计系统界面，要求反映用户的真实需要；
• 第四阶段，通过以任务为中心的遍历评估界面设计，包括情景和角色扮演，情景又同系统界面和用户任务描述相关。

不难看出，以“任务为中心”的设计模型是“以用户为中心”设计模型的基础，不足的是它过于重视产品或系统的功能任务，追求用户的实际目标，却基本没有关注用户的情感化、易用性等方面的个人目标及体验目标。

良好的交互设计应该是让用户在达成他们阶段性的目标的时候，不影响他们终极的目标。目标不是任务，目标是终结条件，而任务是达到目标所需要的中间过程。目标是稳定的，任务是易变的。很显然，应该为目标进行设计，而不应该为任务设计。

如果我们只是为了完成某个任务而且做设计，就会把设计变成如下这样子：

用户模型中的概念和行为完全属于用户的问题领域或任务领域，而技术模型则位于技术解决方案领域。

设计师简单的把功能架构落实到任务流程中，技术人员用复杂的技术去实现设计师的设计，会导致产品的任务流程非常的复杂，而用户在使用产品的时候也是会绕着这个流程走不少的弯路最后才能达到自己的目的。

如支付宝的登陆密码、支付密码、数字证书、绑定手机、选择银行卡…在技术上是一个复杂的实现过程，在设计上也是N条必须走的路线，表现在用户使用产品上，就是要完成N个任务，势必会有各种误操作，怨声连天。

一些技术出身的朋友更是喜欢步入这种误区，在一个表格里梳理出我们能给用户提供的各种可能的功能，最后按照实现可能性分期去做，这样就忽略了用户所需要的功能，往往导致产品臃肿，用户不买账。

而好的设计师会把复杂留给技术人员，把简单还给用户，如下图：

一般来说，用户模型和技术模型差别很大，并且越是复杂的产品，差别越大。因为是对于问题或任务领域，用户模型是产品设计人员无法轻易改变的，而技术模型则依赖于当时的技术水平，在一定时期内也很难有大的变化，唯有设计师模型具有极大的可塑性，是产品设计人员可以通过努力来改变的。

因为用户的最终目的很明确，所以完成这个目标的中间环节，如果可以靠复杂的技术在后台实现，那么就不要让用户来承担这种复杂操作的痛苦。

还是拿支付宝举例，用户的最终目的不外乎是为了支付，那么各种数字证书、各种不同的密码、各种手机验证都不是用户所必须经历的流程，这些流程按照任务分析逻辑可能是存在的，但是如果可以后台完成的话就不需要让用户去执行，否则就会出现我曾经遇到过的尴尬——

“给手机充值需要手机接收验证码，可是我正是因为手机停机了才会需要给手机充值，所以无法接受到验证码，导致无法给手机充值”

还有朋友遇到的——

“我的数字证书绑定的手机号码是135xxx已停用，现在使用186xxx，当前电脑里面没有安装证书。需求：安装数字证书。结果：安装证书时，要求短信验证。我看是135的号码，点击修改手机连接，进入修改页面，告诉我修改手机必须先安装证书。如是循环…”

不要给用户太多的选择，如果用户核心目标是为了搜索，他就不介意自己搜的是wap还是web，是用google还是用Baidu…

设计师模型总是分布于用户模型和技术模型两者之间的某一点，如下图——

设计模型越是接近用户模型，用户需要学习和记忆产品如何使用的地方就越少，这是因为实际产品和用户期望很接近，这样的产品就很容易被使用。反之，如果设计师模型接近技术实现模型，用户就需要走很多弯路，做很多选择，记忆很多位置，产品严重的操作疲劳和记忆负担，而正是这样操作疲劳和记忆负担使人们觉得产品难以使用并重重挫伤了产品的用户体验。

所以我们需要首先通过有效的用户研究手段，收集并分析出如下有关目标用户的信息——

• 动机-是什么需要驱使用户来使用这个产品；
• 情景-用户在什么情况(外在、内在因素)下进行操作；
• 目标-用户最终想要得到什么；
• 习惯-用户一般的操作或使用习惯，比如左右手操作、阅读习惯等；
• 期望-操作前或操作不能满足后的期望；

最后，提炼出用户的终极目标，按照这个最终的需求，去为用户提供最优的设计。而这个设计不是以任务为中心的，是以用户需求为中心的。

复杂的技术+简洁的表现层+用户的终极需求=好的产品