好的設計不僅能滿足用戶需求、提升易用性，還能彌補技術上的短板。在經過一個產品從0到1的實現后，對這一點感受的尤其深刻。下面列出幾個我產品設計中的教訓和收獲。

一、實現模型和心理模型

所謂實現模型，是指從開發人員角度出發，頁面的每一個功能點都與后臺代碼模塊邏輯一致的模型。這種模型的好處是每一個按鈕和數據的輸入字段都體現了工程上的基礎構造，方便研發人員針對性的調整。但缺點是這種模型下的“設計”并非“用戶導向”的，容易讓用戶產生迷惑感，最典型的是我們經?？吹降摹板e誤404”。

對于大部分軟件產品而言，后臺實現模型復雜而難以理解，而且了解其對幫助大部分用戶如何更好的使用產品并無實質性幫助?！督换ピO計精髓》提到“人們使用產品時，不需要了解復雜機制工作原理的所有細節，因此可創造出一種快捷的認知方式來解釋復雜的機制。這種方式足以應付人們與產品的交互，但不一定能夠反映產品實際的內部工作機制?！苯⒁粋€以用戶為導向的“心理模型”（mental model）或者“概念模型”（conceptual model）顯得格外必要。

首先，心理模型實質上提供了一個用戶按照產品機制和規則進行操作的理由。哈佛社會心理學家艾倫蘭格（Ellen Langer）曾做過一個實現：

圖書館打印插隊如果不給出理由則此行為被接受的概率為60%；如果給出一個理解則此行為被接受的概率為94%；甚至在解釋原因時只提供“因為”而無實質原因的情況下，此行為被接受的概率竟然為“93%”。足見，“人就是單純地喜歡做事有個理由”。那么，產品與用戶“交流”時，就需要有個“理由”讓用戶看到自己行為操作與產品回應之間的解釋，從而順應操作規則從而更好的使用產品。

其次，心理模型解決了部分用戶“好奇心”問題。每個人都有好奇心，用戶并不關心后臺情況如何，它真正關心的是這段時間機器在做什么，很好地解決了用戶的好奇心可以讓用戶快速了解產品，降低學習成本和記憶成本，將更多的注意力放在更重要的操作層面，更好地使用產品。

比如，我們研發的產品有一個批量添加企業名稱的功能（300家企業/次），這個功能上傳到后臺需要進行一系列處理從而實現其他核心功能，整體耗時較長，經過后臺性能測試耗時情況如下：

后臺性能統計情

從上表可知，添加企業數目與耗時之間成正相關，由此推算用戶一次添加300家企業等待時間過長，用戶和系統都有隨時崩潰的危險。為了優化用戶體驗，我提出三個方案：

• 方案一：直接降低用戶等待時間，具體實現方式為優先上傳響應，核心功能后臺運轉實現；
• 方案二：讓用戶感覺等待時間短，具體實現方式包括游戲等分散注意力；
• 方案三：讓用戶獲得等待理由，具體實現方式是心理模型。

經過對客戶使用場景分析，客戶往往在添加完企業以后會產生即刻查看企業信息的行為，最終采用方案三，交互設計通過滾動條的形式實現，詳情見下圖：

上傳進度條圖片：用戶可以獲知后臺這段時間在做什么，但實際情況并不一定如此。

告訴用戶一個合理的理由，他們就會耐心的等待。在后續的客戶反饋中，這個批量上傳功能從未收到抱怨，而且好評不斷。

與以上類似的心智模型還有Foxmail收取郵件時的效果：點擊收取郵件，會彈出對話框進度條，進度條上的文字會從正在驗證、正在檢查郵件列表、到任務成功完成逐漸變化，告知用戶后臺機器運轉邏輯。

正在驗證

正在檢查郵件列表

任務成功完成

二、用戶是設計的基礎和來源

剛開始做交互設計工作時，經常產生在需求和設計稿之間卡住的情況。后來發現，大腦之所以產生這種“撕裂和痛苦”感，因為自己在交互設計之前跳過了非常關鍵的步驟：用戶調研！在產品設計的時候需要考慮兩方面的內容，分別是功能和數據。而每一方面的設計都來源于用戶。這一點在我從0到1的產品設計中體會最為深刻。

開始的時候，由于對客戶場景了解不夠透徹，在模塊構建的時候比較混亂。很容易產生各個功能之間斷裂感。隨著用戶調研和場景的明晰，流程圖的繪制，產品各個功能之間的模塊化聚合程度逐漸加強，再次進行設計和模塊劃分時就變得相對輕松和容易。比如，對于金融機構的信貸業務深入了解發現，其業務場景可分為貸前審查、貸后監控兩方面。知道這兩個場景以后，根據這2個場景再次細分，功能模塊也就清晰的浮出水面了。

再比如，產品beta1.0推出以后，一些用戶反饋在他們的電腦上不能正常使用。開始以為是個性問題。隨著用戶反饋增加，對這個問題開始重視起來。為此，我們針對用戶（銀行金融機構）使用瀏覽器進行了調研。

銀行金融機構瀏覽器調研使用情況

從調研結果可以發現：

1. 目標用戶電腦設備更新速度慢，部分常用瀏覽器仍為IE8.0
2. 部分用戶電腦不能上外網
3. 部分用戶安裝其他瀏覽器或者使用外網需要額外申請
4. 技術部分負責設備更新工作

然而，我們產品瀏覽器兼容的IE的版本為IE11.O及以上（見下圖）。由于瀏覽器版本問題，導致部分客戶在使用體驗上大打折扣。

產品適用瀏覽器及版本情況

所以說，在產品設計之初要對目標用戶進行詳實的調研和分析，以客戶為核心向外發散開來逐漸細化。以此產品的金融機構為例，需要詳細了解用戶基本情況（年齡、學歷、知識水平、性別、興趣愛好、家庭情況、工作時間、使用工具、操作系統、瀏覽器及版本號、操作習慣、操作時間和時長等）、用戶所在部門情況、用戶的領導及上下級關系、用戶所在組織機構情況、用戶的客戶情況等等。

正所謂“解鈴還須系鈴人”，用戶是設計的基礎和來源，當設計思路打結時，不妨擁抱用戶，你會發現驚喜。

三、設計原則：為常見的導航調整界面

在交互設計中，經常會遇到功能和部件擺放的問題。剛開始做的時候，我掉進了一個誤區，就是太過于害怕產品需求變更和技術實現問題：：產品經理是否還需要添加新的功能/部件，頁面布局時是否要考慮為新功能留出位置？ 如果再改頁面會不會涉及前端設計需求變更？

由于以上擔心，讓我的設計偏離了用戶，導致出現了將全部功能都隱藏起來的設計。

在獲得多個用戶的反饋和對后臺數據顯示的利用效率情況分析后，我開始反思：面臨這種問題，交互設計師不能憑空猜測，而是要深入用戶使用場景和流程之中，并通過調研最終確定。

《交互設計精髓》中曾提到，要為永遠的中級用戶設計。也就是說，在進行功能和部件設計時，要針對占絕大多數的中級用戶進行調研。調研內容包括：

1. 產品使用流程，重點關注和細化設計功能和部件的使用流程
2. 每個功能/部件使用頻率
3. 每個功能/部件使用場景

根據以上調研結果進行交互設計，確定各個功能/部件顯示或者隱藏的優先級，“將用戶經常使用的功能和部件放在最直接和便利的位置，比如工具條或組建箱。不太經常使用的功能則深藏在用戶不會踏足的界面深處。那些不太經常使用卻對用戶很重要的功能可以安全地隱藏在菜單、對話框或者抽屜里，只在需要的時候被提取。（來自《交互設計精髓》）”

而對于一開始的擔心，交互設計師應該一開始就和產品經理進行溝通，或者讓其給出產品規劃方案，確定大致的需求和產品流程。但無論產品如何規劃，作為一名“交互設計師”需要首先考慮的是用戶使用場景，而非需求和技術實現。只要設計是基于用戶使用場景和頻次，即便日后有再多的需求也不會變動過大。

本文由 @召陽大發 原創發布于人人都是產品經理。未經許可，禁止轉載。