B端産品相對垂直，服務特定人群的特定需求，功能上會有與衆不同之處。單純按照慣性思維套殼隻能讓産品“能用”，其中缺少的是一步分析的過程，将功能翻譯成易于理解的視覺語言。這次通過一個實際項目中遇到的頁面，着重介紹“翻譯”的部分，講解下如何将晦澀難懂的操作流程用視覺語言表達出來。

1. 理解功能

下手前的第一步當然是要先搞明白使用場景和功能用途，這個太基礎了，想必大家都懂。具體到這個項目來說，它是一個用于數據分析的服務，後台有一個信息量很大的數據庫，通過前台進行條件過濾後即可得到一張數據表。

看到原型我的第一反應是：該從哪裡開始操作？頁面功能的終點在哪？原因在于，頁面中有三個主按鈕“生成表格”，“預覽”和“應用條件”，且視覺結構基本扁平。和産品溝通後了解到，當前的邏輯是先選擇指标，給指标排序後就可以生成表格了，針對表格可以再應用條件篩選，最終形成的表格可以導出。

2. 結構梳理

2.1 拆分重組功能

設計改造一般從大到小作調整。先優化整體結構，盡可能讓功能分區更明确。理解了原型後不難看出，頁面的配置項分的很開，先在左邊欄加指标，再在内容去上方排序，生成表格後再去右邊欄條件篩選。這種需要用戶點來點去的結構顯然不太友好，而且細碎的分割消耗了大量的空間。

該頁面功能大概分為配置和數據展示兩大部分，不妨從這個角度重組頁面功能。配置生成類頁面有這樣幾種常見交互形式：一，分兩步，先配置再生成；二，模态浮層，通過彈窗或者抽屜配置；三，非模态，用工具欄或抽屜容納配置項目。為了便于比對或調整配置項，非模态的抽屜更适合操作場景。

功能結構的優化得到了如下的改進：

• 易于統一卷展配置抽屜，避免了各個面闆獨立控制和空間浪費。
• 減少了配置時的操作步驟，選好配置項即可一鍵生成。
• 分區明顯，一邊操作另一邊展示，各司其職。

2.2 方案對比測試

對比測試方案的目的是盡可能考慮全各種設計方案，确定出一個最符合使用習慣和操作流程的布置。不論是手畫草圖還是用電腦畫線框圖都可以，期間多和産品或業務讨論，可以讓對方理解整個的推導過程。

不過溝通中有兩點需要注意，首先讨論方案前先過濾掉從設計的角度看明顯不合理的，評審的目的是通過多方意見調解讓方案達到最優，而不是展示工作量。其次是結構和視覺方案盡量分開評估，否則對方會收到海量排列組合後的設計方案，評起來抓不住重點。下面是當時和産品一塊研讨的三個方案：

• 方案一：指标一列，過濾條件一列。其中指标可以通過頁簽切換全部和已選。
• 方案二：同方案一，但全部指标和已選指标上下顯示。
• 方案三：全部指标單占一列，已選指标和過濾條件單占一列。

最終選定了方案三，綜合來看有如下原因：用戶添加條件篩選的頻次低，所以沒有單放一列并且可單獨卷展；并且方案三的布局在語義上更容易被理解為“庫和待應用項”，提供更典型的心理暗示。

過濾條件的結構做了一些特定的優化：一，新增功能保持在頭部，避免被擠下去；二，條件關系配置直接外露，減少點擊的同時也沒有占用更多空間；三，條件卡片增加了。

至此，需求頁面的結構已經定了下來，之後就是常規意義上的視覺處理了。因為這部分比較細碎，單獨來講可能缺乏普适性，所以下面一章總結了一些常見且通用的設計點供大家參考，最後再提供頁面的最終視覺效果供大家參考。

3. 視覺效果構建

3.1 内容元素的背景色

盡量讓内容和表單展示在白色卡片上。大部分基礎組件樣式是按白色底色的場景來做的，放在其他顔色的背景上很容易出問題，比如表單的禁用态或者标簽的顔色和底色融為一體時，可讀性很差，而且有一種不幹淨的感覺。當然這一條不絕對，如果深度定制了基礎組件的樣式，或是結構功能簡單，背景采用其他顔色也是沒問題的。

3.2 陰影和描邊

陰影分割是一種常見的視覺表達手法，然而B端用戶的顯示器普遍比較糟糕，分辨率低且色域小，太輕的陰影效果不如描邊，有時甚至會讓圖形邊緣看起來很模糊。擔心顯示效果的話，實際上可以看一看 macOS 窗口的陰影尺寸和透明度。B端工具設計中，功能性比美觀度重要的多。

3.3 易讀性與複雜度

下次去宜家的時候可以觀察下結賬的櫃員機，你會震驚地看到裡面仍然顯示着拟物化界面。元素的質感對現代界面設計來說可能是增加了頁面複雜度，然而放到具體的操作場景中，拟物化界面可以給高速操作的收銀員提供更佳的功能可見性，有益于培養肌肉記憶。所以頁面易讀性與複雜度之間的平衡，取決于用戶在場景中的操作方式。

-

3.4 功能顔色的數量

功能顔色讓用戶不閱讀内容就可以初步感知數據狀态，比如警告色，标識色等等。數量太多時用戶會記不住映射關系，顔色就失去了功能性。一個常見的錯誤是标簽的配色，假如一個系統裡有十種标簽，千萬不要設計十種配色，不僅區分度低而且視覺上很混亂，盡可能先歸類再配色。再舉審核狀态的例子，除了成功失敗之外，審核流程還有各式各樣的中間态，需要異化表現時，不妨嘗試通過圖形視覺信号區分，比如增加圖标。

-

3.5 避免攤大餅

非必要不攤餅。随着層級增多，用戶對層級歸屬的感知逐漸變差，内容區也越來越窄，視覺效果難以把控。當然，在B端系統設計中沒有什麼完全不可打破規則，實在避免不了的話，可以着重突出頂層内容或動态提示用戶當前聚焦的層級。比如鼠标懸停時高亮層級關系，類似編譯器的代碼區塊高亮功能。

-

3.6 數據與提示

• 用真實字段内容設計：視覺設計前找産品或者研發要一份内容字段樣本，有助于提高視覺保真度，同時避免開發上線後内容擠不下或大面積留白的情況。
• 表單項默認值：表單中可以通過感知預測填充内容，或設置常用的默認配置，提高表單的填寫效率，減少機械操作。
• 提示信息：提示信息的暴露程度取決于系統功能是否常規，以及目标用戶的理解能力。常用操作不提示，常用但晦澀的功能采用懸停提示，不常用且難懂的功能可以露出提示或幫助中心鍊接。

3.7 數據分析頁最終效果

經過以上粗略的講解，希望大家對頁面控件和整體的視覺處理有了一定了解。針對高度定制化的B端頁面，視覺的核心目的是提高功能可見性和操作易用性，不是單純地去套規範。

4. 工期管理及研發對接

除了頁面的設計流程，項目管理則是另一個重點，B端項目經常會倒排工期，個别戰略導向型的需求更是火燒眉毛。毋庸置疑，兩天工期的設計質量多半是比不上一周工期的，下面講一講在時間緊張時如何保障輸出質量。

4.1 按需求表單規劃

開始設計前，根據 PRD 整理出一個任務表單，即當期需求覆蓋的功能範圍。遇到緊急需求時，可以按照拆分出來的功能模塊分批交付開發。B端模塊的設計時間很少會完全符合預期，比如在設計時發現了一個重大優化點，從構思概念方案到各方評估影響需要占用一部分工期，而通過模塊排期表可以更穩妥地評估突發事件對後續輸出的影響，幫助産品評估是否投入資源做優化。

4.2 先輸出核心頁面确認方向

先輸出關鍵頁面給産品和業務确認，一來讓研發心裡有底，二來控制改稿成本。返工在 B 端項目中很常見，有時候我甚至會手畫草稿去找産品過方案，提前評估可行性，避免方案走了很遠再被駁回。切忌等到交稿節點給産品一個突然驚喜。

4.3 組件與組件狀态

B端原型通常看似隻有一個頁面，而算上各種面闆的打開和關閉，頁面操作狀态，彈窗，包括定制化組件樣式的說明，工作量并不小。組件狀态可以留到最後再補充，但務必和研發提前協商技術方案：首先确定常規功能能否用現成組件，采用哪款組件，這一部分之後就不再出交互視覺樣式了。其次和研發同事溝通非标組件的交互形式，這樣他們可以先寫框架最後再加樣式，不會出現研發空窗。

5. 初步排錯

交付設計稿或者做用戶測試之前，還差一步驗證的工序。過濾掉明顯且粗粒度的問題，可以顯著提高後續的測試效率。客觀上驗證可用性，主觀上評估體驗。

5.1 小黃鴨調試法

小黃鴨調試法是一個工程師都知道，但設計師很少聽說的測試方法，本意是通過給桌上的橡皮鴨逐行解釋代碼來排查問題。驗證階段不妨也試試這個方法，給想象中的人物講講界面的使用方法和元素的設計原因，講都講不通的功能，想必也不會特别好用。（認識我的同事都知道我辦公桌上有張青年 Gary Anderson 給一個領導樣子的人解釋可回收标識設計的照片。我的講解對象就是這個領導樣子的人，他已經駁回了我的很多爛方案。）

5.2 走用戶流程

核對産品功能沒有缺漏後，就可以檢查用戶流程的流程度了。幾種常見的流程問題包括：不知從何下手；找不到功能入口；操作失誤難以補救；系統出錯原因不明。這些問題會突然地卡住用戶，感受上很糟糕。我們可以找出類似的卡點，提供适當的引導。假如從設計上找不到解決方案，則需要提供可檢索的幫助中心以便用戶自行查閱解決。

-

------------------

-結語

B端産品一般會有詳細的文檔，或者培訓操作人員。然而以B端産品的體量和非常規的交互方式，很多操作不好記憶。單純按照原型施工，難以保障易用性。作為設計師的一個關鍵職責，便是将産品操作邏輯翻譯成簡明易懂的頁面和圖形，盡可能鋪平體驗的道路。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!