下手前的第一步當然是要先搞明白使用場景和功能用途，這個太基礎了，想必大家都懂。具體到這個項目來說，它是一個用于數據分析的服務，后臺有一個信息量很大的數據庫，通過前臺進行條件過濾后即可得到一張數據表。
看到原型我的第一反應是：該從哪里開始操作？頁面功能的終點在哪？原因在于，頁面中有三個主按鈕“生成表格”，“預覽”和“應用條件”，且視覺結構基本扁平。和產品溝通后了解到，當前的邏輯是先選擇指標，給指標排序后就可以生成表格了，針對表格可以再應用條件篩選，最終形成的表格可以導出。
二、結構梳理
2.1 拆分重組功能
設計改造一般從大到小作調整。先優化整體結構，盡可能讓功能分區更明確。理解了原型后不難看出，頁面的配置項分的很開，先在左邊欄加指標，再在內容去上方排序，生成表格后再去右邊欄條件篩選。這種需要用戶點來點去的結構顯然不太友好，而且細碎的分割消耗了大量的空間。
該頁面功能大概分為配置和數據展示兩大部分，不妨從這個角度重組頁面功能。配置生成類頁面有這樣幾種常見交互形式：一，分兩步，先配置再生成；二，模態浮層，通過彈窗或者抽屜配置；三，非模態，用工具欄或抽屜容納配置項目。為了便于比對或調整配置項，非模態的抽屜更適合操作場景。
功能結構的優化得到了如下的改進：
- 易于統一卷展配置抽屜，避免了各個面板獨立控制和空間浪費。
- 減少了配置時的操作步驟，選好配置項即可一鍵生成。
- 分區明顯，一邊操作另一邊展示，各司其職。
2.2 方案對比測試
對比測試方案的目的是盡可能考慮全各種設計方案，確定出一個最符合使用習慣和操作流程的布置。不論是手畫草圖還是用電腦畫線框圖都可以，期間多和產品或業務討論，可以讓對方理解整個的推導過程。
不過溝通中有兩點需要注意，首先討論方案前先過濾掉從設計的角度看明顯不合理的，評審的目的是通過多方意見調解讓方案達到最優，而不是展示工作量。其次是結構和視覺方案盡量分開評估，否則對方會收到海量排列組合后的設計方案，評起來抓不住重點。下面是當時和產品一塊研討的三個方案：
- 方案一：指標一列，過濾條件一列。其中指標可以通過頁簽切換全部和已選。
- 方案二：同方案一，但全部指標和已選指標上下顯示。
- 方案三：全部指標單占一列，已選指標和過濾條件單占一列。
最終選定了方案三，綜合來看有如下原因：用戶添加條件篩選的頻次低，所以沒有單放一列并且可單獨卷展；并且方案三的布局在語義上更容易被理解為“庫和待應用項”，提供更典型的心理暗示。
過濾條件的結構做了一些特定的優化：一，新增功能保持在頭部，避免被擠下去；二，條件關系配置直接外露，減少點擊的同時也沒有占用更多空間；三，條件卡片增加了。
至此，需求頁面的結構已經定了下來，之后就是常規意義上的視覺處理了。因為這部分比較細碎，單獨來講可能缺乏普適性，所以下面一章總結了一些常見且通用的設計點供大家參考，最后再提供頁面的最終視覺效果供大家參考。
三、視覺效果構建
3.1 內容元素的背景色
盡量讓內容和表單展示在白色卡片上。大部分基礎組件樣式是按白色底色的場景來做的，放在其他顏色的背景上很容易出問題，比如表單的禁用態或者標簽的顏色和底色融為一體時，可讀性很差，而且有一種不干凈的感覺。當然這一條不絕對，如果深度定制了基礎組件的樣式，或是結構功能簡單，背景采用其他顏色也是沒問題的。
3.2 陰影和描邊
陰影分割是一種常見的視覺表達手法，然而B端用戶的顯示器普遍比較糟糕，分辨率低且色域小，太輕的陰影效果不如描邊，有時甚至會讓圖形邊緣看起來很模糊。擔心顯示效果的話，實際上可以看一看 macOS 窗口的陰影尺寸和透明度。B端工具設計中，功能性比美觀度重要的多。
3.3 易讀性與復雜度
下次去宜家的時候可以觀察下結賬的柜員機，你會震驚地看到里面仍然顯示著擬物化界面。元素的質感對現代界面設計來說可能是增加了頁面復雜度，然而放到具體的操作場景中，擬物化界面可以給高速操作的收銀員提供更佳的功能可見性，有益于培養肌肉記憶。所以頁面易讀性與復雜度之間的平衡，取決于用戶在場景中的操作方式。
3.4 功能顏色的數量
功能顏色讓用戶不閱讀內容就可以初步感知數據狀態，比如警告色，標識色等等。數量太多時用戶會記不住映射關系，顏色就失去了功能性。一個常見的錯誤是標簽的配色，假如一個系統里有十種標簽，千萬不要設計十種配色，不僅區分度低而且視覺上很混亂，盡可能先歸類再配色。再舉審核狀態的例子，除了成功失敗之外，審核流程還有各式各樣的中間態，需要異化表現時，不妨嘗試通過圖形視覺信號區分，比如增加圖標。
3.5 避免攤大餅
非必要不攤餅。隨著層級增多，用戶對層級歸屬的感知逐漸變差，內容區也越來越窄，視覺效果難以把控。當然，在B端系統設計中沒有什么完全不可打破規則，實在避免不了的話，可以著重突出頂層內容或動態提示用戶當前聚焦的層級。比如鼠標懸停時高亮層級關系，類似編譯器的代碼區塊高亮功能。
3.6 數據與提示
- 用真實字段內容設計：視覺設計前找產品或者研發要一份內容字段樣本，有助于提高視覺保真度，同時避免開發上線后內容擠不下或大面積留白的情況。
- 表單項默認值：表單中可以通過感知預測填充內容，或設置常用的默認配置，提高表單的填寫效率，減少機械操作。
- 提示信息：提示信息的暴露程度取決于系統功能是否常規，以及目標用戶的理解能力。常用操作不提示，常用但晦澀的功能采用懸停提示，不常用且難懂的功能可以露出提示或幫助中心鏈接。
3.7 數據分析頁最終效果
經過以上粗略的講解，希望大家對頁面控件和整體的視覺處理有了一定了解。針對高度定制化的B端頁面，視覺的核心目的是提高功能可見性和操作易用性，不是單純地去套規范。
四、工期管理及研發對接
除了頁面的設計流程，項目管理則是另一個重點，B端項目經常會倒排工期，個別戰略導向型的需求更是火燒眉毛。毋庸置疑，兩天工期的設計質量多半是比不上一周工期的，下面講一講在時間緊張時如何保障輸出質量。
4.1 按需求表單規劃
開始設計前，根據 PRD 整理出一個任務表單，即當期需求覆蓋的功能范圍。遇到緊急需求時，可以按照拆分出來的功能模塊分批交付開發。B端模塊的設計時間很少會完全符合預期，比如在設計時發現了一個重大優化點，從構思概念方案到各方評估影響需要占用一部分工期，而通過模塊排期表可以更穩妥地評估突發事件對后續輸出的影響，幫助產品評估是否投入資源做優化。
4.2 先輸出核心頁面確認方向
先輸出關鍵頁面給產品和業務確認，一來讓研發心里有底，二來控制改稿成本。返工在 B 端項目中很常見，有時候我甚至會手畫草稿去找產品過方案，提前評估可行性，避免方案走了很遠再被駁回。切忌等到交稿節點給產品一個突然驚喜。
4.3 組件與組件狀態
B端原型通常看似只有一個頁面，而算上各種面板的打開和關閉，頁面操作狀態，彈窗，包括定制化組件樣式的說明，工作量并不小。組件狀態可以留到最后再補充，但務必和研發提前協商技術方案：首先確定常規功能能否用現成組件，采用哪款組件，這一部分之后就不再出交互視覺樣式了。其次和研發同事溝通非標組件的交互形式，這樣他們可以先寫框架最后再加樣式，不會出現研發空窗。
五、初步排錯
交付設計稿或者做用戶測試之前，還差一步驗證的工序。過濾掉明顯且粗粒度的問題，可以顯著提高后續的測試效率。客觀上驗證可用性，主觀上評估體驗。
5.1 小黃鴨調試法
小黃鴨調試法是一個工程師都知道，但設計師很少聽說的測試方法，本意是通過給桌上的橡皮鴨逐行解釋代碼來排查問題。驗證階段不妨也試試這個方法，給想象中的人物講講界面的使用方法和元素的設計原因，講都講不通的功能，想必也不會特別好用。（認識我的同事都知道我辦公桌上有張青年 Gary Anderson 給一個領導樣子的人解釋可回收標識設計的照片。我的講解對象就是這個領導樣子的人，他已經駁回了我的很多爛方案。）
5.2 走用戶流程
核對產品功能沒有缺漏后，就可以檢查用戶流程的流程度了。幾種常見的流程問題包括：不知從何下手；找不到功能入口；操作失誤難以補救；系統出錯原因不明。這些問題會突然地卡住用戶，感受上很糟糕。我們可以找出類似的卡點，提供適當的引導。假如從設計上找不到解決方案，則需要提供可檢索的幫助中心以便用戶自行查閱解決。
結語
B端產品一般會有詳細的文檔，或者培訓操作人員。然而以B端產品的體量和非常規的交互方式，很多操作不好記憶。單純按照原型施工，難以保障易用性。作為設計師的一個關鍵職責，便是將產品操作邏輯翻譯成簡明易懂的頁面和圖形，盡可能鋪平體驗的道路。
注1：文章示意圖內容由于脫敏需要進行了處理，實際設計時請記得盡量使用真實字段內容。
注2：本文主要介紹流程處理，為避免繁瑣略去了一些視覺設計點，想要了解更多可以參考上一篇文章《引起舒適！什么是好用的界面》。
作者：
轉載請注明：學UI網》如何解析產品原型
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.sdgs6788.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司