我們在評價一個作品的質量時評價的是它的結果質量，即視覺、交互、信息結構等等是不是足夠好、傳遞的品牌感是不是這個產品想傳遞的、有沒有幫助產品達到目標等等，這也是最能給自己帶來興奮感的地方，因此每一位設計師都在為了達到最好的結果質量而努力。但事實是我們通常無法直接控制結果質量（尤其在一個團隊里），只能通過良好的設計過程以及一些基本共識來得到好的設計質量。

過程質量是什麼？

在不同的角色下提到的「過程質量」都是不一樣的。如下圖：對於設計師 A 而言，過程質量指設計從開始到產出的質量，更多指的是設計過程質量；對於一個團隊而言，過程質量是指如何讓一堆設計師通過一個好的流程來更好的協作，更多指的是協作過程質量。

設計過程質量（個人）

對於單個設計師來說，高質量的設計過程可以帶來很多好處：提升個人設計效率、獲取更多信任等。對於設計過程質量，我比較關心的有下面幾點：

溝通質量

對於設計師而言，溝通是一件無比重要的事情。從某個層面來看，設計師其實是一個把問題解決方案通過原型、文檔翻譯給工程師；通過界面、交互翻譯給用戶的角色（雖然這個角色在很多公司由產品經理承擔），但「翻譯」的過程中，為了保證所有的信息傳遞不失真，這需要設計師有著很強的溝通技巧：準確傳遞自己的設計意圖、發生分歧時據理力爭、與用戶溝通的過程中理解他們真正想要的等等。

決策過程質量

經得住推敲的設計決策會給人安全感，這也是表現專業度和建立信任非常重要的方式之一。如果這是一個產品設計方案：這個方案是怎麼得到的？這個方案相比那個方案好在哪？如果繼續迭代還應該改哪裡？如果這是一個平台設計方案：這個組件的擴展性是否足夠好？能否滿足當前所有的業務需求？不同平台的特性是否一致？這些決策過程在側面反應了設計過程中設計師是怎麼思考問題以及思考過程是否足夠全面。

實現過程質量

這會落地到具體的設計實現上，重點是所有的落地方案是否嚴絲合縫的解決了所有問題，是否存在一些並不是設計意圖但因為某些原因引入的其他東西？有沒有別的方案可以滿足這個需求。這裡可以舉個例子：在做某個 Button 時的 Disable 狀態時會採用降低 Button 透明度的方式來得到更淺的效果，好處是可以非常直觀的得到一個更淺的按鈕並對其他按鈕的選色給出參考，這個方案的問題是設計意圖中並沒有改變 Alpha 值的想法，但在實際操作中卻引入了 Alpha 值。於是我們一起討論了這個問題看看是否有其他的解決方案，比如能否採用 HSB 而不是 RGB 來實現這個需求，這樣就可以不用引入 Alpha 值來解決這個問題（因為我們會希望前端的實現邏輯和設計意圖一致，如果我們在設計階段引入了 Alpha 值，那最終的 CSS 應該用到的就是 rgba(0,0,0,.2);，而不是 #000。至於我們為什麼希望這麼做可以日後寫一篇文章來解釋~）。這應該算是實現過程質量的一部分體現，即你的設計意圖和最終落地方案是一致的，而不是出現一些不可控或預期之外的因素。

這三點是我覺得設計師個人可以控制質量的最重要的三個過程，當然除了上面這 3 點還有一些其他也很重要的過程，比如設計稿的交付、工程實現的跟進等等。

協作過程質量（團隊）

一個團隊只有一兩名設計師時，個人質量就是團隊質量，幾乎不用考慮太多協作上的問題，但當團隊成員越來越多，不可避免的會出現團隊成員能力不一的情況，一般情況下沒有辦法直接控制產出質量（除非自己上手），能做的只是控制每一個環節的質量。當團隊作業的時候每個人會得到自己的分工，在不同的分工下，我覺得比較重要的是下面幾點：

共用組件管理質量

當設計團隊需要維護一個功能、交互形態較多的複雜產品時，我們會慢慢發現一個問題：產品設計迭代往往會佔用設計師更多的事情，而平台設計迭代會變慢，這時在原本的產品設計師中就會慢慢產生一個新的角色：平台設計師。這個角色需要思考的問題是：如何讓產品設計迭代更加高效？有一個做法是將設計組件化，比如我們將 Dialog 拆分出來當做一個獨立組件交給 A 負責，那 A 需要做的事情是定義 Dialog 的風格、不同組件在 Dialog 中的表現形式、不同設備的適配策略、不同業務的兼容性、支持的交互形式、呈現的內容結構等等，然後將這些內容規範化，其他產品設計師基於該規範設計。日後 A 就是該組件的負責人，他需要不斷的迭代以便支持更多不同的業務類型。如果遇到組件本身無法滿足的需求，該組件負責人需要做出迭代或採取折中方案來實現。這樣可以使得一個組件有明確的負責人，同時保證平台設計在不斷迭代。與之類似的還有 icon、Animation、Menu、Button 等各個組件，都可以採用這類方式進行管理和維護。

Design Review 質量

應該很多團隊都會有 Design Review，好的設計反饋能幫助設計者更好的完善設計（關於設計反饋本身我之前寫過一篇文章提到過），但 review 的執行質量很大程度上依賴主持人的控制，同時在團隊越來越大的情況下，如何設計一個好的 review 流程是一個團隊必經的過程。當我們提到 design review 的時候總會想到等到有完整的設計稿時再拿出來給大家看，但其實 review 可以在非常早期就開始進行，其實嚴格意義上來說這已經不算是「review」了，算是「聯合設計」。因為當團隊越來越大，通過反饋來收集意見效率非常低下，尤其是參與人數眾多的 review，要麼有一些人永遠不說話，要麼偏題一萬公里，所以早期小規模人員參與的「聯合設計」對改善設計質量的幫助會非常大，同時讓其他設計師能夠深度參與進另一個項目中，徹底了解設計背景和遇到的困難，這樣也能夠更大程度上幫助大家改善交流質量。

設計沉澱質量

我們會希望每一次迭代都是在前人的經驗上進行，這樣才會讓整個團隊有傳承感（之前也有過文章說過這個事），每當有新人加入，他可以很快明白我們當時為什麼做這個改動、改成了什麼樣、數據和用戶反饋如何、解決和遺留了哪些問題等等。如果這些內容都在團隊成員腦袋裡沒有落地成文字，那每當有人離職時，這些經驗都會隨著人員更迭而流失，就會很有可能出現一些之前是 A，後來被改成 B，再後來又被改成 A 這樣的情況，設計的迭代效率變成了以設計師在職時間為坐標系，而不是團隊和產品成立時間為坐標系，這對設計質量的提升不利（下圖是知乎設計團隊的一些設計記錄）。

合作質量

設計師會和工程、產品等各個層面的夥伴合作一同完成設計的最終上線，在合作過程中一定會出現各種問題，比如需求頻繁變更、產品層面沒有思考全面卻著急推動設計產出、工程認為實現設計成本過高不想實現等等，那採用什麼樣的流程來改善與各個角色合作就是一個需要花時間思考的問題。建立規範合理的需求提交模板（背景、問題、目標、數據、預期），項目上線後的及時復盤（記錄合作中遇到的問題），最終的數據分析結果同步，當然還有最重要的 TB！

上面提到的這 4 點都會在各個層面影響到團隊效率和質量，當然和個人一樣，除此之外還有設計稿的版本控制流程、設計和工程的工作流優化等等。

設計過程的優化是為問題找到長期最優解，一般不會被短期目標所影響，設計過程相比業務本身的迭代速度會慢一些。隨著團隊越來越大，業務越來越複雜，為了達到更好的結果質量，過程質量的重要性也會慢慢顯露出來，過去我們可能對結果和過程的關心比例不夠對等，不論是設計師自己還是團隊 leader 可能會需要慢慢調整自己對設計過程質量的關心程度。所以文章標題是個標題黨啦啦啦~~

最後知乎設計團隊在招人喲，實習全職均可！有興趣的老師請快聯繫我！

當然我們超酷的前端團隊也在招人，如果你是一個強而有力的前端工程師請火速發簡歷給我呀！今天投簡歷明天就上班兒！

推薦閱讀：