如何解析產品原型

語言: CN / TW / HK

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端產品的體量和非常規的互動方式,很多操作不好記憶。單純按照原型施工,難以保障易用性。作為設計師的一個關鍵職責,便是將產品操作邏輯翻譯成簡明易懂的頁面和圖形,儘可能鋪平體驗的道路。

注1:文章示意圖內容由於脫敏需要進行了處理,實際設計時請記得儘量使用真實欄位內容。

2:本文主要 介紹流程處理 為避免繁瑣略去了一些視覺設計點,想要了解更多可以參考上一篇文章《引起舒適!什麼是好用的介面》。