最初看闆Dashboard源于形容汽車儀表盤，恰如其分地擔當了浏覽和查看的任務。這幾年設計看闆項目不少，本篇文章聊聊如何設計一個好的設計看闆。

為什麼我們要自己設計看闆Dashboard？

其實我們打開CNCF Cloud Native的Landscape，各類各種開源工具玲琅滿目讓人眼花缭亂。

當我們按照CNCF的Trail Map再做劃分，就可以清晰看到他們的分類和路徑，在配置、存儲、安全、發布等諸多方面都有自己的工具。

其中隻看監控和分析Observability and Analysis部分，Prometheus、Fluentd、 Open Tracing和Jaeger都是大名鼎鼎的DevOps工具。

這些開源領域的大名鼎鼎的DevOps工具，打開後會變成什麼樣子呢？下圖是用Prometheus中對Stack的一些傳統監控指标，要不是專業運維工程師，一定一臉懵逼。

如果使用商業軟件的開源版本是不是會好理解點呢？業内翹楚Elastic公司開源的Kibana的Stack健康指标界面雖然交互結構清晰了許多，但是還是感覺很難用的樣子。

這樣的軟件可以為專業工程師所用，但還是存在一定的缺陷，比如針對普通用戶的交互視覺體驗感不佳，各個數據散布在不同的工具中難以規整統一查看，有些數據敏感有安全性的考量等等。

所以不管是想使用商業、開源軟件還是自研軟件，把看闆設計好都是有挑戰的事情。今天我會用原創設計稿 網絡素材的方式做一個小小分享， 從設計師角度簡單七步設計出一個可落地的看闆項目。

01 明确定義看闆的用戶群體和用途

首先，看闆的設計目的還是為用戶而生，所以定義用戶群體和他們核心所需非常重要。大多數看闆都以看為主，輔以功能控制，大體可分為監控類Operational Dashboard和數據分析類Analytical Dashboard。

淘寶賣家平台千牛就是監控類看闆的一種，賣家可以迅速看到當日浏覽數、交易量、交易額等核心數據，而這些展示會促使他迅速作出判斷，進行下一步行動。比如商家看到有未付款的商品，就會和客人積極溝通，促進下單成交，看到出現中差評，系統會預警賣家用以積極解決售後問題。

大多數産品的運維後台也屬于監控類看闆，運維工程師需要關注系統的穩定性和是否有異常情況等等，并作出反饋。

知乎和微信公衆号的看闆就偏重數據分析類，這類看闆對時間的敏感度比較低，更多地體現了曆史數據和總體趨勢。

02 定義大的交互闆式和内容表現的優先級

了解了看闆類型，我們可以看看這類設計的的交互結構。通常Web端和移動端都有看闆的存在，Web端的看闆比較常用左右結構，側邊欄承擔了菜單的功能。

為了給圖表更多展示空間，側邊菜單收起的樣式也很常見。

需要注意的是，設計時我們要考慮不同屏幕的自适應性，理想的話可以做到根據用戶的屏幕自适應排版。

在業務大屏項目中，曾要同時為ipad、大屏和pc上顯示看闆内容，此時的方案不僅要滿足多種平台的樣式，而且要能求同存異。因為大屏的部分可能會對外部客人展示，所以在功能上補充了單圖全屏和隐私功能，當點擊隐私功能按鈕，大屏畫面會切換成屏保，避免客人看到過多敏感數據。

03 按照邏輯分組數據并以此建立網格

當框架定好以後，我們可以開始關注展示内容，與業務&産品進行讨論。通常我和業務會将同類數據的内容盡量放在一起，比如典型的PV&UV、當日下單量&下單金額、曆史數據等等…按照優先級一一排列後，我們将所有的内容扔進了畫布中，再拼圖一般開始自由組合。

比如在溝通需求列表時，業務關注人數按照時間軸可分為今日 / 7日 / 15日/ 30日，前期我建議分開列好，最後設計時考慮合并在一張圖中表現，是設計師先發散再規整的過程。

同理運維數據中的響應時間和響應慢速比也可以放在一起展示。

在設計數據分組和展現方式時，也需要從技術上考慮數據獲取和統計分析的時效性和精确性，通常可以從以下幾個角度出發：

1. 實時性的處理方案

具體的時效要求要精确到秒/分鐘/小時/天/周/月中的哪個粒度，如果是實時流數據，通常可以引入實時計算的引擎和方法，如storm/spark streaming等進行計算；如果是非實時數據，可以通過小時表/天表等方式提前跑出離線數據結果，以便統計分析。

2. 前後端功能解耦，各司其職，前端負責展示邏輯，數據處理邏輯由後端完成

前端直接面向用戶，需要敏捷開發，小步快跑，對用戶的需求快速做出反饋，因此不能加入過重的業務和數據處理邏輯，要做到所見即所得，後端返回的數據，前端直接展示。

後端作為看闆的基礎，負責代碼控制和數據處理，需要做到穩定高效，具備異常處理，水平擴容，支持多數據源的特點，同時要做到API化，即每個前端的參數都可以通過API接口獲取，且具有一定含義，如/api/dashboard/visitors/pv，做到一目了然。

3. 數據格式的保留

一般看闆展示時，會涉及到的數據格式有整型、浮點數、布爾型、字符串等數據類型，通常需要後端程序在處理時進行統一規劃，進行舍五入，以免數據溢出或類型異常。

說起來，業務需求和數據常常變化，我們在設計時，也需要考慮1-2個版本疊代後的整體效果。通常我會将固定信息排列在一起，尺寸保持統一，而把非固定展示的内容占滿一行，這樣如果此欄目下架可以直接去掉該樓層，不影響整體布局。

04 選擇正确的數據圖形化表現方式

拟好了框架，又确定了數據内容，我們可以考慮數據圖形化inforgraphic的設計部分啦。

在實際落地項目中，開發通常會使用開源代碼 自定義修改的方式。比如Echart就是我們常用的開源代碼，設計師在有迹可循的情況下，多考慮數據适合的圖表樣式和配色即可。

選擇圖表的大原則是使複雜的信息易于理解，界面簡單明了，最大限度的減少用戶的認知負擔。餅圖、折線圖和柱狀圖等都是常見又直觀的表現形式。

有些圖比如雷達圖、風玫瑰和環形分布圖雖然看似酷炫，但是其實閱讀性性不高，要根據展示内容有所取舍。柱狀圖、折線圖和k線圖都帶有多項維度比較的性質。而針對時間變化的數據内容，我們可以選擇固态或者動态展現。

用戶即可以選擇左右滑動查看記錄，也可以選擇擴大時間線查看細節數據，Google Finance Analysis也使用了這樣的設計。

很多開源軟件也會自帶一些小小的動畫效果和交互表現，靈活運用會讓你的畫面更有趣和更好用。

實際開發上，設計師還需要注意數據表現的落地效果，比如餅圖和柱狀圖的極值情況和坐标軸的定義等等。比如運維數據App用戶通過率的展現中，大多數情況下通過率都很高，所以坐标軸基準就可以從96.0%起。

說到餅圖，當數據是40%和60%時畫面又美又和諧，但是現實是骨感的，數據也會出現95%、3%、1%和1%的極值情況。通常我會和開發讨論後，定義一個大約3%的百分比，當數據小于3%時，餅圖上始終留一窄條顔色的顯示，這樣并非完全真實的數據呈現，卻讓用戶的視覺感受更好，柱狀圖也可以一樣處理。

05 色彩的選擇和特殊情況的補充

圖表顔色和整體配色息息相關，看闆常規會使用深色或淺色背景。我個人偏好深色，感覺沉浸感更加明顯一些。loading.io Colors 就提供了API上圖表的預覽功能，Adobe的Kuler也很好用，可以為圖标的配色做參考。

當選擇深色背景後，高飽和度的顔色用在圖表上更加出彩。P站和dribble上已有很多佳作可以參考。很多圖表在細節上可以依靠漸變讓畫面更豐富，文字的陰影細節也會讓整體的視覺質感更好。

而因為圖表衆多，重要的數據展示字體要分開設計，并且可以搭配亮色圖标畫龍點睛。看闆會被用戶頻繁使用，一些常用圖标的運用會縮短用戶的理解時間，讓用戶效率更高。

視覺圖形表現上，我們也可以運用High Data-Ink原則，數據圖形化的書《The Visual Display of Quantitative Information》中提到圖标的兩種表現形式，數據筆墨Data-ink和非數據筆墨Non-data-ink。

數據筆墨Data-ink指極簡化的數據，代表了圖表中的不可删除的部分，這些數據是可視化的核心。而非數據筆墨Non-data-ink代表了與數據沒有直接關系的部分，很多也是起到裝飾效果的部分。Data-Ink Ratio 數據筆墨比 = Data-Ink數據筆墨 / Total Ink總筆墨，理想情況下，圖标上的每一滴筆墨都應該有存在的意義，Data-Ink Ratio 數據筆墨比接近于1.0。

我覺得雖然這隻屬于一種數據圖形化流派的觀點，但當我們設計好圖标後，避免過多的裝飾元素讓用戶的注意力能集中在數據上的确是很好的檢視原則。

另外，我們也不要忘記對特殊情況進行補充設計，比如圖表在加載時或者刷新失敗的狀态。

06 給予用戶使用的靈活性和自定義的功能

當我們搞定了核心需求内容&交互邏輯，定下了核心頁面的視覺基調和關鍵頁，可以稍稍松口氣，除了補充賬戶登錄，如果開發人力盈餘，我們還可以看看有什麼錦上添花的内容可做。

一般使用看闆的人基本屬于專家性用戶，所以對自定義的需求會比普通C端用戶強烈許多，在項目資源允許的情況下，為用戶提供自定義功能就是個很好的交互方案。

比如設置中允許用戶調整圖表顯示的順序，圖表可以選擇增加或隐藏基準線做對比等等，我的其中一個項目中因為多國用戶會查看，還提供了中英文語言&金額顯示格式的切換功能。

千牛平台

看闆屬于前端系統，從技術角度考慮自定義功能的話，可以單獨開發一個後台管理頁面。用戶可以借此在後台管理頁面中單獨進行個性化設置，比如頁面布局，開關，排版等；同時和權限系統進行有機結合，添加适當安全審計和訪問控制功能。

07 上線後的的疊代

經曆了上述設計的打磨和讨論，終于看闆項目的第一版成功上線啦！通常0到1的過程是側重核心功能并帶着一點點簡陋的，因為開發工作會大量花費在賬号體系的建立、後端數據對接和前端數據反饋速度和刷新性能上。

從技術角度來看，上線後為确保系統穩定性，我們需要給看闆設計一個統一的兜底方案，避免前端産生空白頁或數據異常的效果。通常來說，看闆的數據源肯定不止一個，會有多個不同的數據源。當前端用戶刷新請求時，看闆的後端服務會從各數據源獲取數據，進行适當處理後最終返回給前端以供展示。

此時，為避免一個或多個數據源不可用或請求超時的情況，可以引入緩存機制，即把之前成功的請求結果在緩存中記錄一份，作為兜底數據。當發生數據源異常時，可從緩存中讀取數據，雖然犧牲時效性，但可以提升用戶體驗。

從設計上看，第一版為了追趕上線的日期，設計時間通常被壓縮的很緊。在設計第二版時，增加新的數據需求的同時，設計師會在疊代中為圖表增加下級詳情頁提高閱讀體驗；部分常用圖表組件化降低複用成本；增加微動畫讓整體交互體驗更好等等。

比如如果是業務類看闆，我們可以考慮增加公司目标系數設定，設定後可以在圖表中做同期對比目标和實際達成對比。

當項目疊代多個版本時，會需要整體布局，細化分出三級菜單，或者增加搜索功能。

通過以上七個步驟，大緻可以做出一份兼具美感和實用性的看闆。随着5G時代的到來，IOT，邊緣計算等等新的技術又會産生大量的新數據源，新一代的EdgeComputing的結構也呼之欲促，像EdgeX這樣的架構已經開始在工程項目上應用開來。

這些新的技術必然會給看闆設計帶來更多的挑戰：比如在多層次硬件數據結構上過濾出業務需要的數據，在數據并發出現時能有效捕捉Key Data并合理呈現等等。

綜上所述，設計數據圖形化看闆是最具沖擊力的視覺項目之一，産品、設計和開發都在用戶體驗和技術創新中尋找一個平衡點。我站在一個設計師的角度寫下了一些心得體會，希望對大家有所幫助。

最後，大力感謝後端運維工程師楊亞童鞋從技術角度對本文的補充，讓文章更豐富，也讓大家看到新的的角度。：）

作者：喵嗚不吃魚，公衆号：呼噜貓薄荷

本文由 @喵嗚不吃魚 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

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

查看全部