在整個設計過程，反饋是一個關鍵的組成部分，本文爲管理者和團隊領導提供了一套設計評論基本規則，具體使用要根據實際情況來進行修正。

反饋是整個設計過程的關鍵組成部分，因此它需要的不僅僅是一些好的遵循的指導方針和最佳實踐。一個禮貌的提醒，遵守適當的批評禮儀，並沒有切斷它。爲了充分利用反饋會議，管理者和團隊領導需要爲設計評論設定基本規則。

與設計生命週期中的任何其他步驟一樣，涉衆反饋會議應該具有相同的嚴密性、一致性和勤勉性。即使是一個單一的設計評估，正確的意圖，有潛力，推動設計從好到偉大。不幸的是，設計批評常常受到不明確的期望、不明確的議程、缺乏重點——或者對周邊問題的不適當的專注——不受控制的偏見、不恰當的觀點、不恰當的聲音的干擾。

要使設計批評會議富有成效和有價值，唯一的方法是在團隊之間清晰地交流和社會化設計批評的基本規則。每當涉衆和用戶體驗設計師聚集在一起對一個新版本的設計進行評估時，你應該提前提醒每個人注意基本規則。

這樣，你可以確保團隊的注意力不會從設計轉向設計師，從經驗主義到個人獨斷獨行，或淪爲個人擴張的犧牲品，而不是圍繞集體努力。

本文提出了一套給出和接收反饋的基本規則。當然，您可以根據團隊的環境、文化和化學要求對其進行剪裁。

首先，反饋的接受者和分配者都必須堅持作爲這些基本規則基礎的四個重要的批評：

1. 尊重。雖然它是好的隊友不同和不同意，每個人都必須保持最大的尊重和敏感性，對彼此。假設房間裏的每一個觀點都來自最好的意圖、智力、專業知識和經驗。永遠不要貶低或輕視任何人的意見。

2. 責任。涉衆是反饋會議的一部分，因爲他們對滿足用戶的需求負有共同的責任，交付最優的設計解決方案，並作爲一個團隊來交付業務結果。爲了最好地履行這個責任，每個人都必須保持開放的頭腦，關注設計師展示的解決方案和隨後的討論，並提供建設性的想法和建議。

3. 正確的意圖。隊友必須爲正確的理由提供批評——設計師必須以優雅的姿態接受他們，使設計解決方案更好地爲用戶服務。給每個人提供反饋的機會。任何人都沒有機會展示他的天才或發泄他的感情。

4. 反思。反思反饋會的真正焦點：問題、上下文和用戶。團隊應該意識到，會議不是關於他們的能力、聲音或個人偏好。

接收反饋的基本規則

在設計回顧的背景下，用戶體驗設計者幾乎總是呈現設計，並且是反饋的接受者。因此，他們有責任提醒利益相關者關於建設性批評的基本規則。

規則1：傳達基本規則

在反饋會議的一開始就設置正確的語調，外交地但權威地傳達基本規則，然後再鑽研你的演講。用演講的第一張幻燈片寫出基本的規則。它們應該是簡潔的，可瀏覽的，一目瞭然的理解。你可以是有創造力的，視覺的，甚至是機智的表現他們。如圖1所示，第一個幻燈片可能包括四個批評，提供反饋的基本規則：

如果任何涉衆對團隊來說都是新的，那麼這個項目剛剛啓動，或者這是一個初步的設計評審會議，那麼您可能需要快速解釋基本規則。否則，最好暫停幾秒鐘，讓每個人都瀏覽一下基本規則，然後再繼續。

規則2：儘早設定預期

在開始展示線框圖或原型之前，設定一些期望值，如下：

讓人們知道你何時以及如何接收反饋，例如，在會議結束時或在會議進行過程中。讓他們知道他們在任何時候打斷你問問題或尋求澄清是否合適，或者你會在特定的時間間隔停下來允許他們這樣做。

清晰地描述設計的階段，例如，初始階段、中間階段或最終階段。另外，他們可能會認爲設計是早期和流動性，所以建議在遊戲後期的大變化。

如果您正在呈現設計的修訂版本，請列出在修訂歷史中已經進行的任何更改。提到誰審查了設計和誰提供了反饋。如果房間裏有人提供了意見，提醒他們說，更重要的是，你要重申這是集體的努力，而不是個人的努力。

圖2中所示的幻燈片實現了所有這些目標。

您還可以在設計批評會議之前共享這些信息，方法是將其包含在會議邀請函中。

規則3：重新創建上下文

詳細說明設計的業務目標。分享人物角色，提醒每個人你正在爲他們設計解決方案。強調高級別的用戶需求和使用上下文。重申您在創建設計時考慮到的時間框架、技術和業務約束。

另外，談論任何最近的研究，需求變更，或者新的信息，這些信息已經影響或者需要對設計的變更。這似乎是一個重複或多餘的步驟——特別是如果您經常進行反饋會議。儘管如此，至少花幾分鐘來做這件事已經成爲了習慣。許多涉衆都參與到多個併發的項目中，因此很容易使他們失去對上下文和背景的跟蹤。快速複習可以幫助他們保持正確的觀點。

規則4：從用戶角度描述設計決策

永遠保持你的用戶的正面和中心。在瀏覽你的設計時，從相關人物角色的角度進行解釋。

不要用你的個人想法或感覺來表達你的設計決定。例如：“我寧願把這個按鈕放在右上角。”“我覺得這是最好的選擇和編輯方式。”相反，要圍繞用例和場景來制定你的設計決策。

場景是涉及人物角色的簡短故事，它們建立了使用的上下文。例如，“約翰在處理工資單。他的最後期限快到了。他正在使用我們的系統來創建新的工資項目並編輯現有的項目。”

用例是用戶爲實現某個目標或期望結果而可能承擔的特定的、逐步的任務。以下是幾個例子：

用例1：“John想要創建一個新的工資項目。步驟1：他單擊new按鈕……”

用例2：“約翰想編輯現有的工資單條目。步驟1：他顯示工資單。步驟2：他選擇入口。步驟三：他點擊編輯圖標。…”

規則5：解釋，不要辯護

沒有必要爲你的工作辯護。如果你發現自己這樣做了，有意識地檢查自己。設計師有時會被他們所創造的設計所吸引，這可能會妨礙他們對新的想法和建議保持開放。

記住，設計是一個集體的努力。確保每個人都知道這不是你的設計，而是我們的設計。如果有人有更好的主意，就對它敞開心扉。不要防守。保持中立，用簡單的分享來解釋你的設計決策。

• 爲什麼用戶可能需要或想要這個解決方案？
• 你還考慮過哪些其他選擇？
• 誰或什麼影響了決策——例如，競爭對手評論、涉衆、專家輸入、標準或用戶體驗研究

規則6：一定要記筆記

使用你的電腦，白板，或一支筆和記事本捕捉每個人的反饋。重要的是要做清晰的筆記，讓你的聽衆知道你正在這麼做。每次有人提出了相關的觀點，讓團隊知道你已經注意到了。這使他們放心，你正在認真地對待他們的反饋。當然，接受或丟棄某些反饋是你的特權，但不是沒有給予適當的考慮。

嘗試捕捉重要的洞見、問題或關注點，並賦予其特徵，包括任何偏離主題而需要稍後討論的內容。如果有必要，你可以讓每個人等一會兒，這樣你就可以寫下一個筆記了。在反饋會議之後，與團隊分享你的筆記以避免“他說，”她說“或者模棱兩可”。

圖3顯示了一個建議的記事模板。

規則7：不要只接受表面價值的反饋

勤奮地記錄下所有的反饋，不立刻拒絕任何東西。然而，在必要的時候，你應該恭敬地要求澄清或質疑批評背後的基本原理。稍後，這可以幫助您決定是否以及如何將反饋合併到您的設計中。如果反饋是模糊的，基於個人偏好，與你的一般思維方式相矛盾，或者可能會對設計產生相當大的影響，那麼這一點尤其重要。

詢問細節——例如：

• 能否請您詳細說明爲什麼您認爲這是比目前的建議有所改進？
• 請你告訴我，約翰，我們的目標人物，將如何受益於這變化？

你所建議的改變也會影響設計的其他部分。你認爲做出這樣的改變是值得的，讓所有這些其他級聯的改變？

你的建議和我對這個設計的看法有很大不同。[解釋它有何不同。]只是爲了讓我更好地理解這個變化的價值，請告訴我爲什麼你認爲我可能錯了？

再次，通過友好的雙向對話，以恭敬的方式進行提問。一旦你注意到一個建議背後的基本原理並告知你將考慮它，馬上停止討論。在任何時候，這種談話都不應該變成一場激烈的來回的爭論，也不應該成爲一場關於一切的討論。

但是，如果某人的反饋是有爭議的，或者與你最初的思路相沖突，請其他涉衆參與進來。看看多數人怎麼想。如果你強烈地感覺到反饋是錯誤的，要求一些時間來反思它，然後尋求利益相關者的共識。如果可能的話，與提供反饋的人進行離線的討論。有時一對一的談話要比在試圖解決有衝突的觀點時進行小組討論好得多。

規則8：積極管理反饋會議

在設計評審期間，你必須戴多個帽子——演示者、記事本和主持人。

最終，這些會議直接有益於您的工作。因此，確保會議井然有序和富有成效，符合你的最大利益。主持會議的責任在於演示者——他通常是用戶體驗設計者。確定您正在尋找的反饋的格式和焦點。決定邀請哪些涉衆參加會議以及在設計的哪一階段。

超過六、七個人的大型團隊缺乏設計評審所要求的親密感和專注力。因此，將邀請列表縮小到那些在特定階段對設計過程至關重要並且最有可能提供有意義的反饋的涉衆。

在反饋過程中，確保每個人都保持參與。禮貌地要求人們集中注意力，如果他們變得分心或多任務。如果某些聲音主導了談話，干預和鼓勵其他人也表達他們的想法。如果人們很安靜和被動，在桌子周圍，以確保每個人都參與進來。如果你需要一個特定的個人對某一問題的觀點，它是好的問一個直接問題的那個人。

如果太多人同時發言，有些人在進行側談，或人們表達相互矛盾的觀點，可以隨時提醒該團體一次表達自己的觀點，這樣你就可以記錄他們的反饋並確定他們的優先順序。適當地記錄每個人的反饋有助於你正確地看待問題並反思問題。

提供反饋的基本原則

提出設計的用戶體驗設計者並不是唯一在反饋會議上有利害關係的人。參加反饋會議的涉衆有同等的責任對解決方案進行權衡，並提供建設性的、可採取行動的反饋。他們必須遵循給出反饋的基本規則。

規則1：在熟悉背景和背景之前避免插嘴動作

對你不完全理解的東西發表評論是有風險和不負責任的。作爲一名設計評審員，您必須堅持爲您所評審的內容獲取上下文和背景。即使您認爲自己理解了上下文，也要詢問自上次審閱會議以來是否有任何更改或是否有任何新信息可用。您需要注意以下幾點：

• 相關用戶角色；
• 主要利益相關者或中小企業的投入（專題專家）；
• 主要限制、挑戰或阻礙因素。

規則2：專注於爲什麼

當回顧設計時，如果你發現一些錯誤，在沒有理解其背後的原因之前不要做出反應。請設計師解釋一下這個設計決定背後的原因。不要簡單地認爲那是由於缺乏應有的思想、疏忽或無能。

用問題的形式表達你的關切。“請解釋爲什麼你選擇在這裏使用下拉列表而不是單選按鈕。”這使設計師有機會澄清是否有合理的理由作出這一決定。這種辦法鼓勵進行開放式討論。另一方面，“我認爲你應該在這裏使用單選按鈕”，這聽起來可能是指令性的，讓主持人處於守勢。

規則3：戴上你的用戶帽

當你回顧一個設計的時候，把你自己放在用戶的位置上。這有助於減輕你的偏見和與你個人偏見的距離。對自己要保持個人好惡。相反，要根據用戶使用解決方案完成其任務的難易程度來判斷設計。如果您對用戶、用戶需求和使用的上下文了解不夠，請一定要詢問他們。

即使您是從特定的專業領域——例如，業務、開發、內容或合法領域——對

設計進行評審，也要始終將用戶放在最前沿，並確保將您的反饋與對用戶最有利的內容保持一致。

規則4：讓反饋更有意義

對設計師來說毫無用處的反饋包括這樣的評論：“這看起來很奇怪。”“我不喜歡這個。”“我不喜歡這樣。”這樣的陳述缺少兩個關鍵的信息，這些信息可能會使它們變得有意義和可行。

• 背後的原因-而不是個人偏好。
• 哪些方法可能會更有效？

在提供反饋時，始終將其與邏輯的、客觀的需求聯繫起來。例如，用戶或業務需求、標準、約定、可用性、用戶體驗或技術或法律約束。

此外，試着舉一個例子，什麼可能是合適的替代。如果您沒有現成的示例，請在以後提供。或者要求設計師和其他利益相關者參與到可能更好的工作中。

如果你的評論是基於一個主觀的觀點，承認這一點，並敦促設計師做一些測試，以確保它不是一個問題的用戶以及。

規則5：避免只關注消極方面

設計評審不僅僅是尋找設計的缺陷。他們還提供了一個機會，以加強什麼好。這有助於爲未來的設計建立更好的標準和基準。積極的加固也使並鼓勵設計師始終朝着正確的方向前進。正面正面的強化也有助於設計師不那麼防禦性和更開放的建設性批評。

在提供反饋時，如果可能的話，先指出積極的一面，然後再指出消極的一面。突出什麼工作得好加強了什麼工作和什麼不工作之間的對比。這使得設計者更容易識別設計的缺點。

規則6：考慮後果

有時候，你建議的一個看似簡單的改變也許並不那麼簡單。例如，建議移動一個按鈕在一個頁面上的位置，可能會引發在許多頁面上進行類似的更改以確保一致性的需要。或者您向用戶流添加一個簡單的附加步驟的請求可能會在後端打開一個由技術約束組成的潘多拉盒子。

通常，用戶界面上看似很小的變化都會引發一系列的相關變化。所以，不要認爲任何建議的改變都是瑣碎或簡單的。問問設計師和其他利益相關者，他們是否認爲這可能會導致任何併發症。意識到你所提倡的潛在的巨大的變化可以幫助確保你的反饋是平衡的和實際的。

規則7：注意你的語氣

時刻注意你的評論或反饋的語氣。你的語氣暴露了你的意圖——不管是建設性的還是支持性的，還是輕蔑的和輕蔑的。例如，考慮下面兩個評論的不同語氣：

“我不知道你爲什麼在這裏使用下拉列表。單選按鈕會工作得更好。”

“你能幫我理解你爲什麼選擇了一個下拉列表嗎？你不覺得收音機的按鈕可能會工作得更好嗎？”

第一個評論有一種判斷性的，僵硬的語氣。它對設計者的智慧提出了質疑，並給出瞭解決方案。另一方面，第二條評論，雖然讓你的偏好充分清晰，卻給解釋和公開的討論留有餘地。

規則8：知道如何推進爭論

有時設計師不會很好地接受你的反饋。他們可能提出相反的論點，可能會說服你改變你的想法，也可能不會。即使在你做出了合理的嘗試後，設計師也可能會鑽研並拒絕你心目中的臨界點。那你該怎麼辦呢？有力地爭論直到你如願以償？表現出沒有被聽到你的不悅？靜靜地接受現狀？

的確，爭論沒有贏家。所以，即使你贏得了一場爭論，你也有可能失去設計師的好感，破壞你們的關係。不滿或沉默同樣會適得其反。所以要確保設計師記下你的反饋。這提供了一個文件線索的討論和可能性，團隊可以探索的設計方案，你已經建議在未來。

通常，最好的方法是詢問其他利益相關者的意見，看他們是否同意或不同意你。或者，您可以要求與設計人員進行一對一的討論以跟進。有時，人們在親密的交談中比在一個充滿人的房間裏，對新思想更開放、更容易接受。

如果您認爲在設計中沒有考慮或納入您的反饋可能會帶來潛在的風險，那麼標記問題，記錄您的反饋，並與其他涉衆分享，甚至將問題升級到組織的領導。

結論

大家理解設計批評的重要性，並遵循這裏概述的基本規則。

優秀的設計評論可能會給優秀的設計帶來啓發，然而，如果一個設計評論缺乏結構或禮儀，它可以退化成空洞或痛苦，這對團隊和用戶都是有害的。因此，給設計批評以應有的評價是絕對重要的，在幫助他們的時候，要確保每個人保持正確的嚴密性和遵循這些基本規則。

本文編輯:長離

本文著作權歸原作者所有，秋褲說已獲得授權轉載。