如果你是組件設計師，一定會對組件設計完成之后的評審過程深有體會。很早之前我在負責我們團隊的組件庫建設工作時就經歷過這樣的事情：

每次我把組件的設計方案和使用規范全部制定好后，在設計師組內開“組件設計評審會”，大家通常都會因為方案和規范的細節吵得不可開交，各執一詞。經常是定不下來最終方案，好幾個組件不了了之。

后來我總結出了幾個實用經驗，不僅讓組件評審順暢進行，也能讓設計結論快速敲定。這些經驗不僅可以用在組件的設計評審上，還可以用在其它設計稿的評審中。希望對你有幫助。

更多干貨：

一、為什么組件設計難以評審？

在我剛做組件那幾年，發現組件設計的評審會通常會比普通的業務設計稿評審會難搞得多。分析下原因，大概是以下幾點：

1. 參會對象

參會的人員全是設計師，有時也會視情況叫上一到兩名前端開發。在大多數都是通曉設計理論并將“用戶體驗”牢記于心的設計師面前，涉及到專業領域相關的討論內容，大家就更習慣于錙銖必較，對細節嚴格要求。

2. 設計前提

組件的設計方案本來就不存在絕對的最優解。組件是要為業務服務的，所以不能脫離業務場景空談組件的質量和解決方案。因此組件設計師經常需要解決業務需求和組件本身的設計體驗之間如何平衡的問題，同時還要考慮到多場景的通用性。這是大部分的業務設計師都不了解的組件設計前提。

3. 使用方式

做好后的組件會變成其他設計師未來做業務需求設計時要用到的提效工具，所以一些業務設計師是有那么一點“私心”的，比如總希望這個組件可以更貼合自己負責的業務場景，這樣在做需求設計時就可以付出更小的改動成本，開箱即用。

以上幾個方面都會讓組件的設計評審變得更加冗長和復雜。

二、組件評審的幾個技巧

經過很長時間的“摸爬滾打”之后，我總結出來了幾條實用經驗，分享給你：

1. 建立組件的評判標準。

這里要涉及到的是你在做組件設計時的價值觀和基本原則：組件在設計過程中要注重哪些規則、符合哪些標準；如果這些規則和標準如果相互沖突時，應該按照什么順序進行遵守。

在組件庫建設的初期，先確立這類設計原則很重要，團隊中的其它使用組件的設計師也要先對于這些基本規則達成一致。我在文章：如何判斷一個組件設計的“好”與“壞”中，也提到過一些衡量標準，可以參考。

這樣，當你在評審時遇到其他設計師提出的設計建議和修改要求時，可以先判斷是否符合既定的設計標準，如果不符合，可以憑此原因拒絕修改建議。

2. 設計和規范有依據支撐。

你的設計角度要客觀，要有依據、有來源。各位設計師會產生爭論的原因，也可能在于沒有一個能夠完全占據“壓倒性優勢”的證據或依據可以說服所有人。

當然，這種“壓倒性優勢”的證據其實很難找，所以你在評審時可以采用 “積少成多”的方法，也即將“很多條小證據累加起來“的方法，一條小證據可能不足以支撐你的設計成果，但 3、4、5 條小證據疊加在一起，就足以構成 “壓倒性優勢”。

設計師之間的交流需要有充分的證據和邏輯，所以組件設計的推理和分析過程很重要，一定要保留并在評審時有所呈現。評審時可以先給大家講解下你的組件設計思考和分析過程，讓大家既能夠了解你的設計思路、理解你的設計產出，也能夠感受到你對于組件設計工作的投入和付出。

3. 找有決策權的人來支持。

你可以在評審之前，先將方案拿給團隊中最有設計公信力、話語權和決策權的領導看看，聽聽 Ta 建議、獲得 Ta 對方案的認可。

在評審時如果最終實在無法說服其他設計師，或者無法選擇出一個最優解，也可以根據領導的意見來做決策，一錘定音。畢竟不倫怎樣都先確定出一個方案，在實際使用的過程中才可以更精準地檢驗方案的優劣。再正確的組件也不可能萬年不變，如果發現問題，及時優化即可。

4. 疑難問題會后單獨溝通。

如果有些問題實在討論不出結果，也沒有必要立即拿個定論，你就需要在大家僵持不下的時候先控場，將問題記錄成待定項，往下進行其他會議內容。

在會后，你可以單獨找到每一個相關方，確認方案的可行性。這樣看上去是“復雜工序”，實際上卻比群體討論拿結果要快得多。等結論確定之后，可以在工作群里、月報或是日常組件的發布會中將結論進行全員發布。

歡迎關注作者微信公眾號：「長弓小子」