1993年由克萊頓.劉易斯和約翰.黎曼提出了“以任務為中心”的設計模型（Task-Centered System Design，TCSD）中，設計過程分為了四個階段——

第一階段，識別用戶和任務，即通過用戶訪談和自然觀察等手段確認任務，然后形成任務描述文檔，最后驗證任務并進行反饋修改； 第二階段，以任務為中心的需求分析，即確定系統支持的用戶類型和任務類型；

第三階段，基于情景的界面設計，即構思一個情景，設計系統界面，要求反映用戶的真實需要； 第四階段，通過以任務為中心的遍歷評估界面設計，包括情景和角色扮演，情景又同系統界面和用戶任務描述相關。 不難看出，以“任務為中心”的設計模型是“以用戶為中心”設計模型的基礎，不足的是它過于重視產品或系統的功能任務，追求用戶的實際目標，卻基本沒有關注用戶的情感化、易用性等方面的個人目標及體驗目標

良好的交互設計應該是讓用戶在達成他們階段性的目標的時候，不影響他們終極的目標。目標不是任務，目標是終結條件，而任務是達到目標所需要的中間過程。目標是穩定的，任務是易變的。很顯然，應該為目標進行設計，而不應該為任務設計

如果我們只是為了完成某個任務而且做設計，就會把設計變成如下這樣子：

用戶模型中的概念和行為完全屬于用戶的問題領域或任務領域，而技術模型則位于技術解決方案領域

設計師簡單的把功能架構落實到任務流程中，技術人員用復雜的技術去實現設計師的設計，會導致產品的任務流程非常的復雜，而用戶在使用產品的時候也是會繞著這個流程走不少的彎路最后才能達到自己的目的

如支付寶的登陸密碼、支付密碼、數字證書、綁定手機、選擇銀行卡…在技術上是一個復雜的實現過程，在設計上也是N條必須走的路線，表現在用戶使用產品上，就是要完成N個任務，勢必會有各種誤操作，怨聲連天

一些技術出身的朋友更是喜歡步入這種誤區，在一個表格里梳理出我們能給用戶提供的各種可能的功能，最后按照實現可能性分期去做，這樣就忽略了用戶所需要的功能，往往導致產品臃腫，用戶不買賬

而好的設計師會把復雜留給技術人員，把簡單還給用戶，如下圖：

一般來說，用戶模型和技術模型差別很大，并且越是復雜的產品，差別越大。因為是對于問題或任務領域，用戶模型是產品設計人員無法輕易改變的，而技術模型則依賴于當時的技術水平，在一定時期內也很難有大的變化，唯有設計師模型具有極大的可塑性，是產品設計人員可以通過努力來改變的

因為用戶的最終目的很明確，所以完成這個目標的中間環節，如果可以靠復雜的技術在后臺實現，那么就不要讓用戶來承擔這種復雜操作的痛苦

還是拿支付寶舉例，用戶的最終目的不外乎是為了支付，那么各種數字證書、各種不同的密碼、各種手機驗證都不是用戶所必須經歷的流程，這些流程按照任務分析邏輯可能是存在的，但是如果可以后臺完成的話就不需要讓用戶去執行，否則就會出現我曾經遇到過的尷尬——“給手機充值需要手機接收驗證碼，可是我正是因為手機停機了才會需要給手機充值，所以無法接受到驗證碼，導致無法給手機充值”

還有朋友遇到的——

“我的數字證書綁定的手機號碼是135xxx已停用，現在使用186xxx，當前電腦里面沒有安裝證書。需求：安裝數字證書。結果：安裝證書時，要求短信驗證。我看是135的號碼，點擊修改手機連接，進入修改頁面，告訴我修改手機必須先安裝證書。如是循環…”

不要給用戶太多的選擇，如果用戶核心目標是為了搜索，他就不介意自己搜的是wap還是web，是用google還是用Baidu…

設計師模型總是分布于用戶模型和技術模型兩者之間的某一點，如下圖——

設計模型越是接近用戶模型，用戶需要學習和記憶產品如何使用的地方就越少，這是因為實際產品和用戶期望很接近，這樣的產品就很容易被使用。反之，如果設計師模型接近技術實現模型，用戶就需要走很多彎路，做很多選擇，記憶很多位置，產品嚴重的操作疲勞和記憶負擔，而正是這樣操作疲勞和記憶負擔使人們覺得產品難以使用并重重挫傷了產品的用戶體驗。

所以我們需要首先通過有效的用戶研究手段，收集并分析出如下有關目標用戶的信息——

動機-是什么需要驅使用戶來使用這個產品； 情景-用戶在什么情況(外在、內在因素)下進行操作； 目標-用戶最終想要得到什么； 習慣-用戶一般的操作或使用習慣，比如左右手操作、閱讀習慣等； 期望-操作前或操作不能滿足后的期望； 最后，提煉出用戶的終極目標，按照這個最終的需求，去為用戶提供最優的設計。而這個設計不是以任務為中心的，是以用戶需求為中心的。

復雜的技術+簡潔的表現層+用戶的終極需求=好的產品