?

根據自己多年的B端/G端數據可視化項目設計經驗，總結了這篇數據可視化項目如何做設計評審的文章。內容側重于數據可視化項目，但對于非可視化項目的設計評審也是通用的。文中介紹的流程和方法，尤其是通過STAR法則來闡述自己設計思路的創意，是我在實際工作中一直使用、并受益良多的技巧；文章中也提到了很多只有經過實戰打磨才能發掘的一些細節的問題和處理方式，希望所有這些積累和沉淀能給大家帶來幫助和啟發，期待大家喜歡這篇文章，后續我每月至少更新一篇經驗文章，歡迎各位設計小伙伴關注和交流~

?

01-前言

如下思維導圖，我按個人工作經驗梳理了數據可視化項目的核心交付流程，從流程圖中我們可以看到：設計評審是設計執行與設計迭代之間的關鍵環節，設計評審為設計迭代提供了科學的依據。從整個項目交付的角度來看，在數據可視化項目中，設計評審最根本的目的是對設計與需求的匹配性進行系統的評估和反饋，并針對技術落地的可行性與實施成本進行適當的評估和確認。設計評審是需求相關方對設計質量和效果的確認，是設計進入開發前必須經過的關鍵節點。

我在自己的社群和公司可視化項目設計環節也發現了一些比較有共性的問題，比如：開發對設計還原的效果比較粗糙、還原不到位；一些比較有特色的交互或動效落地困難或后期開發時被砍掉；設計提出的一些優化需求被延期或擱置；由于開發還原不到位導致項目交付效果差然而客戶吐槽或投訴設計質量；等等，以上問題有諸多因素，但我認為有一個很重要的點就是設計師沒有在適合時間點拉起設計評審，大家對于設計稿的效果并沒有達成廣泛的共識，所以一些設計想法會被其它開發或同事認為這只是設計師自己的想法而不是規范的項目需求。所以設計評審讓設計工作在過程和形式上表現的更加專業和正式，設計師的想法也可以通過設計評審環節給各方有一個充分的表達，而通過了設計評審的設計稿（包含交互、體驗、視覺等）就不再是設計師自己的產出，而是整個項目團隊共同的作品，是項目交付的“關鍵文檔”，在這種情況下，設計師就可以爭取到包括項目經理、產品經理、開發負責人等在內的需求相關方一起推動設計的落地和還原，如此，在后期的拉扯和推進中就不再是單打獨斗，而是有合作有隊友。

02-評審流程

設計評審的流程不同公司或許不同，但我總結了下大體上就是這5個流程，我們知道整個全局的流程之后，在發起設計評審時就可以按照每個流程的要點去準備和完成對應的內容，這樣整個評審流程就會有條不紊、高效可執行！這5個流程是前后依賴的遞進關系，其中有些同學會把“演示階段”的工作當做設計評審的全部內容而忽視了其它幾個部分，最終導致設計評審結果不理想或后續設計落地仍然存在很多固有的問題，所以我會把這幾個部分分開，給大家把每個節點該做什么、重點是哪些、都做一次比較詳細的梳理，通過這次閱讀，我們就可以帶著目標和方法進行設計評審，當我們掌握一個比較專業科學的評審流程后，我相信在后續項目中進行設計評審會更加高效、愉悅、有質量！

?

03-準備階段

一般情況下，在完成需求評審，進入設計階段時，設計負責人首先會對整個項目相關的設計任務進行細分和評估，定義幾個關鍵的設計交付節點，并明確每個節點交付的內容，同時與項目負責人就設計交付節點和內容達成一致。因此，設計評審在一個項目的支持周期內，可能會進行幾次，每次評審的流程和內容相似，但是參與評審的人員可能不同。

在設計評審準備階段，設計師首先需要明確本次評審的設計內容，并準備好相關設計稿，以及與設計稿對應的需求文檔或原型，如果有交互的演示需要確保演示順暢、鏈接可正常打開等：如有動效演示需準備相關視頻文件。我個人以figma為主力設計工具，所以需求原型的截圖會跟設計稿放在同一個頁面，設計稿下方放原型截圖，設計稿與原型一一對應；動效相關的演示視頻也會嵌入導Figma中；對于一些比較大的視頻文件及設計稿圖片會提前導出放到一個文件夾，規范命名，然后在邀請階段發送給相關同事。

就我個人而言，在準備階段，我會為本次設計評審設計一個簡單的封面、一個目錄；目錄主要體現了本次評審的內容、這樣即方便相關人員全面了解評審內容也可以在演示階段通過目錄提醒自己，避免在評審中遺漏某些評審要點、或者節奏過于拖沓。

?

04-邀請階段

#邀請人員和范圍

準備好相關設計稿和演示素材，確認評審內容后，就需要邀請需求相關方來參與設計評審了。被邀請參加設計評審的同事需要滿足兩個條件，首先被邀請同事是本次設計利益相關方，常見的有需求發起方、頁面實現的開發人員、負責數據準備的同事等；其次，被邀請同事應該有一定的決策權，設計評審中需要對視覺效果、交互形式、實現方式等進行討論和決策，所以被邀請的同事應該能夠對設計中與自己負責的相關需求或模塊可以做出直接的決策：即可以或者不可以！如果被邀請方無法對設計內容做出決策，那一定會有后續二次甚至三次的溝通，這樣的溝通一方面效率低下，另一方面存在很多不確定性，會導致評審的不斷延續以及后續信息與其它方的斷層。所以應該盡可能邀請有決策權的相關方參與。

另一個需要注意的點是：控制參與設計評審的人數！一般應該邀請最關鍵的相關方參與，且在角色齊全的前提下人數越少越好。這樣做，一方面可以節省不相關同事的時間，同時也可以提高評審的質量和效率！參與設計評審的同事在7人及以上時，往往評審的效率會比較低，人數越多并不會收到更多有效的反饋，往往會收獲更多無效的吐槽，設計評審本質上是對設計的方方面面進行確認和決策的過程，因而只邀請決策相關者參加可以很好的提升設計評審的體驗和效率！

#邀請方式

一般邀請前先與參與方溝通好時間，然后正式邀請以發送郵件的方式比較合適，郵件里面可以附上相關設計稿（準備階段設計的目錄）、設計文件鏈接、動效演示附件等，簡要說明評審時間、地點、評審方式、內容等。 對于一些有內部辦公軟件的團隊，比如字節的飛書、京東的京Me。阿里的釘釘等，在預約會議時可以直接選擇相關參與方，并抄送郵件和會議材料給對方，相對來說會更方便。如果辦公軟件有創建日程的功能，也可以創建日程并共享給大家。

需要注意的是： 1、設計評審的邀請要提前發出。按本人工作習慣，評審邀請會提前3天以上發出，非緊急情況盡可能避免臨時的邀約，因為臨時邀約大家的時間不好協調，而且準備倉促也影響評審質量，如果頻繁的發生臨時的會議也會使得大家覺得設計師工作沒有計劃、比較隨意，長此以往影響大家對設計師專業力的判斷。尤其是在團隊規模比較大或者邀約人中有比較高級的經理或者老板時，大家日程通常都會排的比較滿，因而提前溝通提前發起評審計劃也是對其他同事有更好的體驗，這也是職場基本禮儀以及設計師同理心的體現。 2、不要在微信群等信息流更新頻繁的各類群內發起邀請，因為信息流內消息多且更新快，極有可能部分同事收不到邀請而導致正式評審時缺席或遲到。

05-演示階段

演示階段主要面向需求方展示UI界面、功能和交互等，對于數據可視化項目，尤其是大屏可視化項目，一般都有比較豐富的動效設計，所以也需要向業務方展示動畫效果、以及動效觸發條件和交互邏輯。設計師是設計評審的發起者，所以設計評審會議設計師是主持人也是主講人，所以如果是線下會議，設計師應該提前到場，調試設備、測試投屏、麥克風以及打開設計稿看看演示是否流暢、正常；如果是線上會議也需要提前進入會議，測試投屏、麥克風等。

我們在準備階段已經準備好了演示階段要評審的內容目錄，如下圖，所以評審會議開始后，簡單給大家介紹下本次會議的目標和背景就可以按照目錄內的內容進行逐項的評審。

一般為了避免混亂和提高評審效率，我們每個時間段只評審一個主要方向點，作為設計評審的發起者，設計師在這個環節即是講解者也是評審會議的主持人，因而需要有意識的把控會議節奏和引導大家圍繞既定議題討論，避免過度發散和拖沓。 因此，會議開始后，應該給大家說明白自己評審演示的順序和討論發問的規則及時間限制，對于大多數人來講，相比漫無目的沒有節制的討論，其實大家更期望一個有強力的控場和明確目標、規則的會議，所以不要擔心有人會不同意或破壞規則，大膽的說出自己的秩序并以主持人的角度做出應有的執行和維護！

項目初次評審，首先應該給大家整體講解同步設計思路，設計思路：即基于當前的需求背景和用戶使用場景，采用了哪些設計方法產出了怎么的設計效果滿足了哪些業務的需求。我一般習慣將設計思路歸納為幾個設計關鍵詞，每個關鍵詞闡釋對設計某個角度的理解，然后通過關鍵詞將自己的設計理念或者設計思路同步給需求方。

向大家講解設計思路有助于讓評審各方從更全局的角度理解設計師的想法，有利于設計思路的落地以及后續設計細節的講解。

設計理念主要闡述了設計方法論，設計對需求、對用戶場景以及現有技術的了解和響應。具體到頁面設計細節的講解，我們一般從“形、色、字、質、構、動、音、視”八個角度去闡釋大屏可視化項目的設計細節。雖然不同數據可視化項目的頁面呈現、交互邏輯等都會有些許差異，但設計最底層的要素歸納起來就是上述8個方向，從這八個方向闡述自己的設計細節：一方面可以讓自己講解的更有條理、另一方面也可以讓評審各方更容易理解設計底層的邏輯和層次，把那些我們精心雕琢但用戶往往不易察覺的設計有效的傳達給需求各方。

“形、色、字、質、構、動、音、視”八個設計要素在我自己的數據可視化項目中已經形成了固定的模版，每個新的項目設計評審我都會從這8個角度去講述自己設計的細節，通過不斷地講解和反復的宣貫，時間久了相關協作方也就熟悉了這些流程和方法，也算是我們對非設計專業的同事完成一些培訓和分享，這樣后續項目的評審就會更加順利流暢。當然并不是每次設計評審都要從這8個方向講解，對于跟設計師已經熟悉的業務方或者某些非重點的設計細節，我們簡略的闡述即可；那些影響設計效果、或者需要開發等相關同事強力配合才能落地的設計細節可以更重點的闡述。對于““動、音、視”三個方向的細節，最好準備可以交互的demo或者能夠演示的視頻，以便更準確的闡述設計效果讓大家更清晰的理解設計結果。

06-反饋階段

反饋階段是穿插在演示階段內的，在設計演示階段，我們主要按照準備階段規劃好的目錄，按模塊向需求方演示設計效果。通常為了保證評審效率，我們在每個模塊的講解演示結束后，再進行集中的討論和反饋。按照本人主持設計評審的經驗，在演示結束再進行討論反饋往往會更高效，而在演示過程中被反復打斷、提問會使整體評審體驗和效率降低，因為演示過程中的提問很可能在之后的展示中馬上就會講到，中途頻繁的提問也會使演示的節奏拖沓。所以評審會前跟大家約定好評審的規則、提問的時機也很重要。

每個模塊演示結束后，大家針對該模塊的設計展開討論和交流，反饋內容基本上分為兩大類：疑問和建議；每條反饋盡可能在評審現場有明確的結論或結果，對于現場不能決策的反饋，需要作為行動點整理在后續的評審紀要中，并在評審會上與大家明確行動點的跟進者以及完成的時間。

設計稿是設計師針對業務需求結合用戶使用場景、用戶習慣等要素綜合考量后進行的有意識有目標的設計產出，但是不管是面向業務需求方還是普通用戶，設計稿呈現在他們眼前更多的是直觀的視覺效果，視覺不像代碼或者算法邏輯在認知上存在一定的門檻和專業基礎要求，所以每個人都可以基于自己的理解和審美對設計師產出的設計稿進行評價和反饋，所以為了聚集大家的關注點，盡量引導大家在“正確”的方向討論就非常關鍵，而這正是我們在演示階段通過設計關鍵詞進行設計理念宣講的目的！

對于數據可視化項目，尤其是大屏項目，往往比傳統網頁或者APP項目有更高的落地門檻，因此在反饋階段要針對演示階段展示的效果與開發相關同學進行針對性的討論和溝通，設計稿還原不僅與開發的技術水平相關，其實也與項目實施的成本相關。所以演示階段展示的越細致，反饋階段大家對相關效果的實施技術、實施成本的評估也就更客觀可行。

反饋階段產生的需要技術驗證的效果或者待決定的決策，需要由技術負責人跟進或指定相關同事跟進，并且也需要有明確的完成時間點。

當然，各方對于設計的反饋也不一定是在演示之后，我個人會在邀請階段通過Figma將相關設計稿鏈接發給需求各方，如果大家有時間，就可以在評審正式開始之前，通過評論的功能對設計進行反饋。對于一些小規模或者小需求的設計，這樣的反饋方式顯然更加高效和輕量化。所以方法有很多，大家可以根據項目實際情況靈活選擇。

?

07-總結階段

總結階段最主要的工作就是匯總并梳理反饋階段收集的各類反饋信息，并以評審紀要的方式將相關信息以郵件或者其他比較正式的渠道同步給評審參與者及需要知曉此部分內容的相關同事。

如下圖，總結階段的內容我們大體上可以歸納為兩類：結論與任務項（行動點）。其中，結論部分是設計評審中大家達成一致的重要結論點，比如對于設計風格是否整體認可；交互動效、轉場過渡等效果是否得到需求方及研發的確認；此外還有后續開發及設計迭代的節奏與計劃等。重要的結論必須以文本的形式明確記錄，以防止后續針對該部分內容的拉扯和反復討論。

設計師作為設計評審的發起者，必須能夠準確記錄評審中形成的結論，對于有兩個以上設計師參與的設計評審，可以一個人負責展示和講解另一個負責記錄；對于僅一個設計師參與的評審可以采取現場確認現場記錄的方式進行，也可以現場確認會后記錄。 沒有會議紀要的評審，基本等于沒有評審，會議紀要是設計評審中最重要的產出！

任務項是指需要解決的問題或事項，一般來講，任務項由任務內容+執行人+完成時間三個要素組成。每個任務項建議僅指定一個人為負責人，對于需要多人完成的任務項由負責人自己分配和協調大家工作，負責人對結果和質量負責。任務項內容盡可能簡潔明確，一般一句話足以。

由于反饋階段形成的任務項不一定都是設計師負責，比如需要前端調研或驗證的技術、需要項目經理協調的資源等，所以任務項需要在反饋階段跟大家明確任務內容與負責人及完成時間。總結階段只是梳理并形成正式的評審紀要~

梳理完成的評審紀要一般以郵件的形式發送并同步內容到用于項目溝通的群聊等即時聊天軟件。設計師需要做好設計迭代及任務項進度跟進。對于周期較長的任務可每周同步進度，任務周期較短的任務項每日同步進度。 評審結束之后，各方都以紀要里面的任務項和結論點為依據，進行設計迭代、開發維護等。

?

08-評審內容

設計評審內容階段，最核心的工作就是設計師要通過有條理、清晰且易于理解的表達，將設計的思路和價值傳遞給需求方，并得到需求方反饋的過程。

從我的設計經驗來講，我推薦大家通過STAR法則來向大家闡述自己的設計細節和思路。

采用STAR法則首先可以梳理好我們設計師自己的思路，并且通過這種結構化的表達也能夠讓大家更好的理解你的設計意圖，同時。法則中結果部分也可以把大家的反饋部分作為對自己設計驗證的一環，采用這種表達方式反復練習，你會發現自己的表達越來越好，并且自己的設計也會越來越嚴謹，而這種表達的提升不僅能在設計評審環節展現你的優勢，在日常溝通匯報等方向也會讓你變得更強！

?

09-視覺評審

我們在展示階段通過“形、色、字、質、構、動、音、視”8個要素來向大家闡述我們的設計細節及設計思路，實際上在視覺評審模塊與視覺相關的主要是“形、色、字、質、構”5個要素。

按照個人經驗，在設計稿展示之前，會先展示對應頁面的原型，通過原型帶領大家簡單回顧并說明原型上都有哪些業務需求點，然后再展示設計稿，這樣處理：一方面是想讓大家對原始需求有比較好的理解，另一方面是因為原型一般都較簡陋，而設計相對細致，對比之下也更容易突出設計的精美效果。視覺評審重點向大家講解通過哪些設計手段解決了哪些業務問題、完成了哪些業務需求點、以及通過哪些設計方法使這次設計呈現出了與同類項目相比具有特色的設計亮點。

當然倒也不必面面俱到，有亮點的地方著重講，普通設計要素點題即可！

?

10-交互評審

交互設計評審需要以業務方需求為依據，大體思路也是遵循STAR法則來向大家闡述，對于簡單的交互可以直接描述或者配合Figma的原型功能做一些簡單的交互效果，對于比較復雜的交互需要畫簡單的流程圖并輔助可交互的頁面來闡釋，交互評審最核心的是要說明交互設計的目的和交互邏輯，落腳點還是解決用戶的痛點和目的。

另外交互形式的可行性也是交互評審中需要關注的點，在闡述交互方案的過程中，要注意其它方反饋的關于交互設計可行性及開發所需時間等問題；容易遺漏的交互是一些特殊情景是否考慮完全：例如轉場、中間態、異常狀態、不同數據情況等。

?

11-動效評審

可視化大屏設計中適當的加入一些動效設計可以使數據的展示更加生動，此外，數據可視化大屏的一部分業務需求是公關展示，公關展示大屏特別強調設計效果和氣質，一般場景是面向媒體和公眾展示較多，因此適當的動效也可以提高大屏展示的效果，強化大屏某方面的特性，從而在公關展示的場景下取得更好的曝光和傳播。

動效評審需要說明動效的狀態和作用，對于那些交互行為觸發的動效，要向大家說清楚動效觸發的條件，持續的時長，結束的狀態和時機；對于非交互觸發的動效（動畫），需要說明動畫的場景和在頁面上的位置，同時要考慮動畫跟頁面整體風格的一致性，要與頁面整體具有比較好的連續性和敘事性。

對于一些比較復雜的動效，可以根據現場評審的反饋，簡單的講解下動效的原理和技術，方便開發更好的理解和實現動效開發。

?

12-適配規則評審

數據可視化大屏的適配一般主要有兩方面的適配內容：第一個是數據內容的適配，第二個是分辨率的適配。

數據內容適配是指大屏可以在一定程度上適配不同數量、不同類型的數據要素，比如在數據類型發生增減、單一數據極少或極多的情況下，大屏的組件和布局如何響應數據的變化，以使大屏整體始終有比較好的呈現質量。

分辨率適配是指大屏內容可以適應不同分辨率和比例的變化，數據可視化大屏一般都是定制化開發，在設計初期其實已經知道了交付現場的硬件規格，所以大部分情況下大屏的適配比較簡單，但是對于一些要面向多個不同場景交付的大屏，分辨率的適配就顯得比較重要，一般通用的適配方式有以下幾種，大家可以參考

?

13-結語與總結

本次分享主要基于本人日常工作經驗總結而來，雖然針對數據可視化項目撰寫，但其實具有很好的通用性，相關的評審流程和方法應用到其它非可視化的項目依然適用，如果大家對B端/G端數據可視化設計感興趣，歡迎與我有更多交流，后續也會按照每月至少一篇經驗分享文章的節奏，持續更新相關設計文章，感謝大家的耐心閱讀和支持。

我是BYMD，一個會寫詩的數據可視化設計師~

審核編輯 黃宇