產品設計流程中，有必要對設計進行評審是大家的共識。在我每周的工作內容中，參加各類大大小小的設計評審是必不可少的一環。既有腦力激蕩的評審讓設計方案脫胎換骨的，也有針鋒相對的評審讓設計方案搖擺不定的。怎樣進行一場高質量的設計評審？設計師應該如何應對設計評審，更好的表達設計意圖，并收集意見改進方案？怎樣避免設計評審變成競稿或PK？如何確保設計評審這樣的流程能帶來更大價值？帶著這些問題，我們一起看看原文作者Jason的觀點。*

批評從來都是很容易的事情，似乎人人都能擁有自己的觀點。但正如作者Harlan Ellison指出“你無法把控（他人）對你自身的意見，但你能把控（他人）對你觀點的意見?！?觀點的形成需要探索，而設計評審正是產品探索的重要環節。

創意者與團隊或客戶討論并解釋其創意時的設計評審，并非纏著設計師要求解釋驗證每一項設計決策，那僅僅是批評。優秀的設計評審是探索整個設計過程，找到亮點并發掘改進機會。理想狀況下，設計評審讓團隊中每個人都有被傾聽的感覺，允許客戶給出有價值的反饋。

設計評審中提出建設性意見往往是個挑戰，尤其在團隊缺乏設計評審的經驗時。在敏捷開發團隊中，程序員、項目經理、產品經理及其他相關人員坐在一起反饋，你得明白如何應對他們，并且把事情迅速往你的期望方向引導。

UI設計評審的原則

根據我的經驗，針對UI的設計評審應當在整個產品設計與研發過程中開展，或者至少以定期的方式，每周甚至每日開展。這么做可以讓產品設計可控，尤其在設計需要進行多次迭代的敏捷或者精益產品流程中。開展UI設計評審是一項挑戰，不僅需要解釋決策，還得耐心聽取其它建議。

在每次設計評審前建立清晰的原則-而不是“規矩”-至關重要。與規矩不同，原則不是教條式和限制式的，而是幫助每個人對焦期望，并允許進行自由形式的討論。

這些期望中的重點是讓每個人對你提及的點評細節達成共識。Jason Ulaszek推薦道：

在你點評的設計細節上開始詢問背后的原因及意圖。為什么我們需要這條信息？對于允許索取這條信息我們設置了哪些期望？我們會用它做什么？如果我們能回答它們，再進入討論解釋各種元素的優劣以及與之對應的不同意見會比較好。

圖1. 準備好演示

為了更好的遵循這個方針，無論是否包含UI設計，我建議遵守適用于任何設計評審的標準原則：

1、表示尊重

聽起來很老套，但如果每個人都是在批評而不是尊重臺面上的意見和他人的技能，那評審會迅速形成敵意。

2、指定角色

開始之前就澄清在設計評審中每個人的角色，最好在逐個點評時也把角色都重申，避免有人感到被遺忘。理想狀況是以下三類角色是不同人（往往不大現實）。

演示者

負責進行設計提案并解釋背后思路的人，他需要回答所有的問題，或找出能夠回答評審提問的人。

主持人

最好由不是直接負責設計的人來擔任，比如項目經理或產品經理。主持人確保每個人聚焦在主題上，并且每個人的意見都能被聽到。

記錄者

此人側重于記錄討論內容，尤其是確保會議相關結論（另外一條原則，后續會說明）在評審后能夠清楚傳遞。會議記錄者不應該被排除在討論范圍之外，盡管他們的職能傾向于讓他人更清晰的表達觀點。

3、針對當前評審描述項目目標

快速提醒每個人項目目標以及評審涉及的范圍。確保整個評審集中在手頭任務上，而不是東扯西扯，偏離話題。

4、回顧目標用戶

強調參加評審的人都不是產品目標用戶，提醒誰才是目標用戶。

5、避免給出答案

參與者將會帶有強烈的解決問題欲望，而且會在評審中提出解決方案。然而，最佳方案往往不會在評審時產生。評審的關鍵是探索問題及討論潛在的多個方案，幫助設計師拓寬思路并最終決策。

6、對結論形成共識

記錄者需要回顧每個參與評審人員提到問題的結論，以便在下次評審中大家形成共識。

不幸的是，UI設計評審經常在視覺細節上死磕，而忽視交互層面的更影響設計的內容。因此，對UI設計評審，我們增加了幾條原則：

7、澄清設計媒介

在跟聽眾講解設計時，記得提及產品界面展示的平臺及相關技術。這是個iPhone應用？一個網站？是否使用AngularJS技術或者C#開發？確保這些都充分考慮，否則你的設計方案可能完全無效。

8、勾勒流程

你得了解路線圖。對于UI設計來說，應該是用戶體驗的流程?；蛟S是故事板、用戶旅程圖或者其它描述流程的方式，每個參會者都應該在點評界面之前充分了解整個流程。

9、演示產品，而不只是描述

我得再次強調：偉大的用戶體驗應該更多的展示出來，而不是口頭描述出來。用戶在不必解釋的情況下就應該明白產品如何工作。你的演示需要盡可能少的語言解釋，就好比老話說的：好的UI就像笑話一樣，如果需要解釋，那么肯定很糟糕。

10、提出正確的問題

設計評審中的大量提問與評述跟協作精神有較大沖突。我推薦一些在探索設計時的開放對話中可以用到的問題，比起導致激烈PK更容易促成協作，你可以推薦給你們團隊試試。

圖2. 關鍵是提出正確的問題

“這個方案你是如何想出來的？”

在任何評審或者交流中比較適合的切入問題，詢問設計師如何做出某個方案，而不是為什么做某個方案？詢問為什么立馬會讓設計師進入防備心態，而詢問如何進行的會讓設計師在不需要澄清理由的情況下去表達自己設計理念的初衷。

圖3. 找到答案不難，問對問題很難

“為什么”相關的問題讓我們急于證明某件事情的真實性，而不是解釋它作為一種可能性。根據Aaron Morton的觀點：

“為什么”引出一個故事，解釋某件事情的真實性。如果你問為什么，一切都無法奏效，你更想要創造一個故事，無論真實與否。這是讓你感到糟糕的危險領域。 與詢問“為什么”不同的是，考慮詢問“如何”能夠引出一個創造流程的故事，不必為它的存在辯護。然后你可以問設計師之前考慮過的各種可能，認真傾聽設計師在提供方案之前做過的嘗試。他們也許過于看重某些東西，不過沒必要深究。

“你想要這樣做的想法來自何處？”

愛迪生說過一句著名的話“天才是1%的靈感+99%的汗水”，但他那最重要的1%來自Nikola Tesla。畢加索也說過“優秀的藝術家借鑒，偉大的藝術家偷竊”。

皮克斯動畫總裁 Ed Catmull的《創造力》一書的中心思想就是，一個偉大的團隊遠勝于一個偉大的想法：讓合適的人產生合適的化學反應比得到正確的想法更重要。

我們極少在隔絕情況下形成想法，看看想法來自何處能推動我們自己的創意。更妙的是，在團隊中把靈感匯集很容易產生新的創意。

一個忠告：避免指責或者居高臨下，比如暗示他們的想法是偷來的。盡管你希望在不影響創新的情況下，設計師推動對于自己創意驅動的理解和創意來源。

“這應該在什么時候發生？”

如同喜劇一般，合適的時機意味著設計的一切，所有的事件應當在適當時間點以適當的秩序發生。盡管我們設計時，元素的秩序不易察覺，除非我們耐心解釋。

偉大的UI就像一個好故事，你得小心編排。開啟表單填寫時需要展示多少信息恰到好處？是否展示了對應上下文的信息方便用戶理解？是否已經到了揭露結論的正確時刻？

Jason Kunesh是Public Good的公司CEO，這是一家專門幫助非盈利組織通過新聞來做連接的創業公司。他告訴我：

優秀的適時交互是讓產品（服務）吸引或失去客戶的關鍵區別。將間歇性的互動變為持久關聯的秘訣在于一系列精彩微交互，以及當用戶需要時恰好出現的信息內容。 在設計評審流程中，應當詢問每一個行動、每一次詢問或者每一次數據展示是否出現在正確的時機，以確保界面在切換時傳遞信息時順暢。

“我們是否可以運用動效來添加視覺線索？”

這個問題可能會讓不少已習慣于靜態設計多年的設計師們感到意外。不過，動效、動畫與轉場過渡將成為體驗設計的標準。動效將在設計中成為顏色一樣的重要元素。

圖4. 在現代UI設計中，動效與顏色一樣重要

UI動畫設計專家Rachel Neighbors說過：

隨著扁平化設計與用戶體驗趨勢的搖擺變化，我們能預感到頁面部件缺少視覺線索的風險，因此動畫能減少這種風險。 這種動效可能是顏色、透明度的變化，也可能是用猴子的手臂延伸頁面這種細節，或者用戶完成任務后展示太陽升起的效果。詢問在UI設計中加入逐步動效的可能將極大的推動設計師改善設計，使得設計師思考時間維度的設計細節，而不只是局限在空間維度。

“我們如何使它更簡單？”

要做到簡單很難，增加東西比移除東西更容易，因此許多界面得了“暴雪中的雪花”綜合癥，當然這里的每個雪花都是獨一無二的，只是在暴雪中容易被忽略罷了。在UI設計中，我們?？吹浇缑嫔铣涑庵溄?、按鈕、控件和圖片，客戶往往認為需要將用戶可能用到的東西都放出來，這樣一來用戶根本無法找到實際需要的東西。

圖5. 降低噪音與干擾

當我把簡化設計的問題拋給《Don’t Make Me Think》的作者Steve Krug時，他回答道：

這是一個很好的問題，我認為它是每個人都應該吸收的教訓，盡管并非如此。我總喜歡提到：對用戶的真實目標來說，頁面或屏幕上的任何元素都不是解決方案的一部分，而是噪音和干擾。 在設計的每一步中，我們都需要自問：我們如何能夠創造更小思考成本下能發揮同樣作用的產品？在設計評審中，這是要求把方案簡化的最佳表達。在設計中保持界面清晰很重要，使用盡可能少的點擊、文案和輸入框來達成目標更好。踏踏實實的把用戶需要完成工作的消耗降到最低，用戶會感激不盡。

“接下來會發生什么？”

優秀的設計評審與優秀的采訪類似：他們都是一種探索。一名優秀的采訪者Studs Terkel說過：

采訪不是審訊，而是一種探索，對過去發生事情的探索。因此我認為最紳士的問題就是最好的問題，“請問接下來如何呢？”

將它應用到UI設計上，我們通常問設計師接下來發生什么。這個問題幫助他們進一步思考后續考慮事項。因為每一步行動后用戶終歸得有一個地方可去。

任何UI設想的最大挑戰之一就是考慮所有可能的用戶路徑，而不僅僅是我們希望用戶去走的“happy path”。用戶點擊按鈕后發生什么？如果出現錯誤怎么辦？用戶提交表單后會發生什么？一直詢問接下來發生什么，直到你們考慮到每一個可能的場景，否則就可能存在讓用戶無所適從的風險，這是一種糟糕的體驗。

不要只是提問，還要回答它們

對與此有關的任何人提問時，不要只是簡單的問一些你想聽到的答案。當某人向你提問但又不聽你的解釋或者理解你的思路，只愿意聽到它們想要的答案時，這會讓人反感。

圖6. 隨時準備傾聽和記錄

如果你曾經這樣，馬上改掉。問完問題后洗耳恭聽，接下來基于聽到的回答，而不是那部分你想聽到的內容，來構建你的回復。

優秀的設計評審有什么特征

評審的質量取決于參與者技能、目標和責任。不過一個優秀的設計評審通常都聚焦在產品某個具體細節，并針對當前的方案進行透徹的探索。

UI設計評審不只是在關注到視覺方面，而應該在交互和用戶需求滿足上聚焦。參與者經常會問為什么事情沒有按照他們預期的方式進行，而不是考慮用戶的需求。來自UX for Good公司的Jason Ulaszek告訴我他的觀點：

在討論中保持客觀，考慮該設計使用用戶的心智模型，這是我們探討方案的關鍵。

時刻記住，像逐幀動畫一樣，最終成品的1秒影響需要數周甚至數月的努力。盡管我們可能在界面的某個小細節上就需要花費很多精力，可能它在用戶的使用體驗中也只是很小的一部分。

圖7. 團隊得有共同的目標

Steve Krug對此的看法是：

我們認為，很棒的產品描述（比如產品手冊）對用戶來說就跟“坐在60碼時速的車上看到的廣告牌一樣”，UI設計師們比較難理解用戶是如何忽略這些產品界面細節的，盡管設計師為此付出諸多努力。 優秀的設計評審放慢節奏，考慮每個元素，但是能認識到這些設計細節可能不會被用戶注意到。如果參加評審的人員在顏色、字體及體驗設計方面沒有專業知識，他們可以考慮以下重要因素：

1）一致性

在產品中的設計是否保持一致，包括顏色、字體、控件、圖像及任何使用超過一次的界面設計元素（靜態、動態）。

2）上下文

你是否統一考慮了用戶使用產品時的上下文？不斷去詢問這個問題是關鍵，因為在設計或測試中很可能你只是在模擬，而不是在上下文環境下共情。

3）調性

品牌和設計是否有清晰一致并且可辨識的調性。

4）轉場過渡

界面上重要變化狀態之間的過渡是否使用了轉場效果？現代設計不僅僅是視覺方面的因素，考慮所有的界面元素在用戶交互時是如何移動和變化的。

5）簡單

對于完成任務，設計是否足夠簡單？

避免敵對批判

評審時常充斥著PK，團隊成員不管出于何種原因，總習慣忽略創造過程中的思考而進行批判。他們帶著自身偏見看待設計，而不是從用戶出發，有時候只是為了顯得自己牛逼。

你一定能想起出現過激爭論的評審：設計師開始對設計決策進行辯護，而不是解釋如何得到的方案并且討論其它替代可能。避免變成爭論的關鍵在于設定清晰的原則并且提出開放的建設性意見。記住，評審時用來加強設計協同共建，而不是競稿。

評審變成PK的話毫無意義并且會傷害團隊。對抗性的批判會強迫設計師進入一種防衛姿態，只想護衛完成的工作，而不是拓展和改善它們。設計本身就是大部分依賴直覺，并不容易量化評估。

不過，這并非意味著評審只是討論對設計師的看法，應該討論對設計師通過經驗形成的方案的看法。來自Agentic的網頁制作人Phillip Djwa感覺其中的關鍵在于：

經驗告訴我，不要試圖一概而論。例如我會問“我不確定開放的banner是否足以傳達品牌？”，而不是問“哇，用戶根本不會理解我們的品牌價值?！?/p>

結語：設計評審不是可用性測試

我們很容易認為自己是站在用戶角度共情，或者通過使用用戶角色，或者自身帶有偏見。無論使用多少用戶角色，經歷多少輪評審，你仍然不是你的用戶。Steve Krug告訴我：

這就是為什么我認為每個設計師應該花時間觀察用戶并且使用自己的產品（又稱可用性測試）。

圖8. 設計評審只是體驗工具箱中的一個工具

如同激光測量精度跟肉眼估算測量精度對比一樣，可用性測試比設計評審更加精確，也更加費時費力。常規設計評審對于項目實現目標沒有直接價值貢獻，也無法取代真實用戶現場測試。如果只進行評審而不去做可用性測試，得到的結論就是自high。

原文地址：https://www.smashingmagazine.com/2016/08/running-a-ui-design-critique/

譯者：阿里巴巴\1688事業部\無線交互\舒舟

譯文地址：http://www.aliued.cn/2016/09/26/【譯文】ui設計評審成就微創新.html