互動設計：“認知模型”vs.“工程實現模型”
舉個小例子：
如果我們要去超市買一把雞毛撣子，我們會去哪個櫃檯區域？
雞毛撣子在哪兒買？
如果我們在“日用百貨”區域找不到它，反而在“肉類生鮮”櫃檯旁找到了它，當你詢問工作人員原因，超市工作人員振振有詞地告訴你：“因為雞毛撣子和雞肉是從同一個生產廠家進貨的，都是雞的周邊產品，所以要擺在一起”時，相信你的表情，一定是抓狂的吧。
不要跟我講大道理
上面這個例子如果是發生在生活中，可能會讓我們感覺很荒謬，而事實是，這樣的事情日復一日地發生在網際網路產品的設計過程中。那些網際網路產品的製造者們，以產品的“工程實現模型”直接呈現給使用者，卻對使用者的不理解和迷惑熟視無睹，彷彿本應如此。
例如需要為客服人員展示一張使用者日程列表，產品經理給出的方案如下：
使用者日程列表
產品經理因為不瞭解客服人員需要哪些資料，也沒有意願去了解，所以就簡單地把資料庫表裡的欄位一股腦兒地給搬了過來，其大致意思就是“總有一款適合你”，至於哪一個欄位適合你，你自己慢慢找吧。
這樣做當然不會遺漏資訊，但造成了很大的資訊噪音，讓客服人員無法專注於有用欄位，造成了很大的易用性問題。
最後解決的辦法就是和客服人員深入討論，發現降序排列的序號是完全沒必要的，流水號是基於單號的擴充套件和細化，所以可以去掉流水號，最後做出了合理取捨。
以前在OTA公司工作時還曾經遇到過一個歐洲四國通票預訂的產品設計，設計需求是這樣子的，歐洲鐵路公司一般都是商業公司，各鐵路公司之間有協議，所以可以購買一種一次可以遊覽四個毗鄰國家的鐵路通票，但購買完成後需要選擇即將出行的四個毗鄰城市。
歐洲鐵路線路圖
最初的設計是產品經理根據工程實現模型直接把後臺邏輯關係照搬到了前臺：
歐鐵四國通票選擇
使用者在看到這四個下拉選單時，根本無法直觀感受到這個產品的邏輯關係，使用者不能理解為什麼第一個選單選中某個國家之後，後面的三個下拉選單為什麼選擇範圍就變得越來越窄，甚至存在沒有選擇的情況？所以使用者在這個環節的投訴率和出錯率很高。
後來從使用者的認知模型出發，把所有國家選單一次性地抽象出來放在一個介面上完成，變成了一個選擇選單的四個選擇步驟，因為這種展示和選擇方式基本符合了使用者的認知模型，所以這次使用者的理解完全沒有問題了。
把所有國家抽象化到一個介面上
如果使用者選擇了某個國家，可選擇範圍收窄，使用者的直觀感受是因為我選擇了某個國家，所以只有毗鄰國家可選擇，使用者是可以理解事件發生的原因的，所以使用者的可操控感增強了，而非減弱了：
選擇一個國家後，毗鄰國家高亮待選
這個設計據後期的調研顯示，使用者在這個介面上基本沒有碰到理解和認知的問題，而且這個介面互動設計方式我們申請了專利。後期本來預備把這個展示方式做進一步的優化，根據真實地理位置把國家做成六邊形來以期更加符合使用者認知模型，不過後來因為離開了那家公司所以沒有實現。
通過以上的幾個例子，可以發現， 只有從使用者的認知模型出發，儘量貼合用戶的認知模型去做設計，而不是照搬產品的工程實現模型，才能保證產品的易用性和使用者體驗。
畢竟，我們設計一款產品的目標物件，是使用者而非我們自己。