【 iCHEF 設計分享會 】施與受都有福：官方 Q&A
距離首次 iCHEF 設計分享會已經過了半年，相較於上次較廣泛的講題「產品設計師的進化之路」，我們這次更著重在工作流程中的關鍵 —— Design Review 上。
會選擇這個主題是因為，Design Review 是 iCHEF 設計團隊的特色之一，對我們來說，他人的觀點就像探照燈一樣，可以照亮我們的思考死角，讓設計成為「共創」的過程，每個人都是讓產品順利落地的推手。
除了介紹 Design Review 的效益、流程、事前準備，也深度討論了「給予和接受回饋的痛點」，甚至加入分組討論環節，讓大家盡情抒發！也許是主題跟內容引起大家的強烈共鳴，當天交流得非常熱絡，甚至散場後都還有設計師們聚集在電梯前聊天。
這就是 iCHEF 設計團隊想要帶給台灣設計工作者的價值：不只能得到心態和專業上的啟發，還有機會建立人脈。（畢竟我們設計師真的是非常需要取暖和誇誇的生物 🥹）
本篇文章會選出當天最多讚數的十個問題，補上較完整的資訊跟脈絡。
一、給予和接受回饋
Q1. 如果自己吸收資訊與思考比較久才能給回饋的話，有什麼方法可以解嗎？
🔹 Kat：所謂的「回饋」不一定是「具體指出該怎麼做」，它也可以是引導對方進一步思考的提問，或是補足自己不知道的資訊的提問。因此可以試著問對方「想了解這部分設計的考量是什麼？」，讓自己更了解現況，以及對方的設計脈絡。另外，也可以練習觀察其他 reviewers 都是怎麼給回饋的，包含他們關注的面向、給予回饋的內容結構、語調和肢體語言。
🔸 Fei：自己本身也是一個需要時間消化大量資訊的人，尤其是加入不同產業、不同產品團隊時，這件事會更加明顯、需要適時給自己一些時間上手。如同 Kat 所說，在無法馬上理解所有脈絡時，可以試著多針對自己不懂的地方提問，除了增進自己對產品的認識，也可以有效的幫助對方發現溝通盲點，如：講得太快、規格複雜不容易理解、需要更簡化的說明 ⋯⋯ 等等。這些都是很好的回饋方式唷！
Q2. 想學怎麼誇誇，很需要 😆
🔹 Kat：在《你可以改變別人》裡有提到，「你好聰明喔！你做得真好！」這類回饋會助長定型心態，聽到的當下也許會很開心，但過了一段時間就會很空虛，因為你不知道具體是哪裡做得好。若要培養成長心態，讚美時可以著重在努力，而非天份。例如：
- 你這次 Review 控時很精準、講述完整又有結構，我覺得很棒耶
- 剛剛 Review 被問到 ＿＿ 的時候，你很冷靜面對，情緒也控制得很好
- 在 Design Review 上，你有把設計方案說明得很清楚，文件也很易讀
🔸 Fei：如果你是一個不太習慣用讚美的話、鼓勵他人的人，也可以嘗試讓別人知道他們的產出對你的幫助，比方說：
- 對方的設計文件做得清楚，你可以告訴對方：這份文件的規格標示很清楚，我試著放到自己的專案中使用，覺得跟 RD 對規格更有效率
- 對方的設計發散很完整，你可以告訴對方：我嘗試了你的設計發散方式，有效的產出更多方案、提升設計體驗
- ⋯⋯ 各種幫助到你、讓你成長的事項
即使上述都沒有一些誇誇用詞（如：好棒、很厲害、很好 🤣），但是當別人知道自己的東西會被其他人學習、甚至幫上忙，也是一種很正向的鼓勵方式。
Q3. Host 在 Design Review 接受每個回饋的當下，要如何確保有好好回應建議（或可能做好表情管理），並推進到下個想尋求回饋的主題？
🔹 Kat：學會覺察自己的情緒很重要！當我們聽到較負面的回饋，可能會感到焦慮、憤怒、沮喪，如果當下不知道怎麼排解，會引發「戰或逃反應」，影響後續 Design Review 的進行，所以如何讓自己保持穩定且健康的心態，會是 Host 要面對的一大課題。
🔸 Fei：收到許多非預期、甚至負面回饋時，當下一定多少都會造成情緒波動，這是人之常情。此時需要一些理性的小工具引導自己完成 Design review 該完成的事，例：
- 事前定義好的 review 範圍：若當下收到太多超出範圍的回饋，可以跟 reviewer 再次說明今天的 review 範圍，並且告知在會議後你會再閱讀跟處理。讓對方知道雖然你當下沒有回應，但並不是不處理的態度。
- 當下無法馬上吸收跟回應的回饋：可以誠實告知你還需要時間思考，讓對方理解你的狀況，並且也了解你還有其他主題需要討論。
二、處理回饋
Q4. 好奇衡量判斷回饋的「影響Ｘ成本」時，iCHEF 團隊是跟哪些職能一起討論的？如果產品開發團隊對於同個回饋的「影響Ｘ成本」價值觀點認知不一致時，會怎麼協調溝通呢？
🔹 Kat：因為「影響」涉及到商業目標、專案目標、使用者體驗，「成本」涉及到設計成本、開發成本、預算等等，所以通常 PM、設計師、工程師都會一起參與討論，但是「討論權」並不等於「決策權」。大家可以站在專業立場提出自己的看法，不過最終決策權還是會在 PM 和設計師身上。
另外，就算價值觀一致，也不等於大家都認同某一個設計方案，反之亦然。大家可以對策略、目標、專案方向都有一致的認知，但還是有可能針對設計細節有不同看法。所以身為設計師，我們要判斷現在的目標是拉齊大家對於設計原則與目標的共識？還是設計方案取捨的共識？
Q5. 如果因為工程資源吃緊，設計跟工程實作開發時程不是直接銜接，導致工程師在後面進行開發的時候才詢問很多必須處理但當初沒有討論到的一些邏輯判斷、edge case 等，會建議怎麼處理比較好？
🔹 Kat：可以思考怎麼避免工程師到開發階段才提出需要處理的邏輯判斷，當然不可能 100% 避免這件事的發生，但可以在設計階段就處理掉大部分，這是設計師也是工程師的責任，不必等到 kick-off 後才開始密集溝通。針對邏輯判斷和 Edge Case，一樣可以用上方的 Impact-Effort Matrix 思考：
- 影響
產品：如果真的發生，會不會造成嚴重後果、踩到產品底線 - 影響
用戶：如果真的發生，使用者有沒有其他的解法 (workaround) - 成本：如果決定要處理它，設計、開發複雜度會不會很高
三、對焦與溝通
Q6. 想聽聽你們分享內部遇到最困難的 Design Review 專案～～ 中間是如何討論，讓專案逐漸明朗化
🔹 Kat：我認為沒有所謂「客觀上」的最困難，困不困難是很主觀的，例如 50kg 的背槓深蹲對我來說就是一件極度困難、近乎不可能的事，但對很多人來說可能輕而易舉。因此對你來說簡單的專案，對正在經手的人來說可能很吃力，所以我們可以多一些同理和包容，適時幫助彼此。
Q7. 設計後跟利益關係人對焦，這裡會遇到功能或設計大改的狀況嗎
🔹 Kat：一定會啊！iCHEF 又不是烏托邦 🤣 如果問題是「會不會」，那答案就是「會」，但如果你想問的是「怎麼面對和處理」，那就要認知到在真實的市場環境中，有變化（甚至是劇烈變化）是一件很正常的事，我們不知道下個黑天鵝事件什麼時候會再發生。因此擁有可以接納變化的餘裕和彈性，也會是從 Junior 設計師走向 Senior 設計師的一大關鍵。
大力推薦這集〈沒有快捷鍵〉，Soking 有談到為何餘裕與彈性是重要的
Q8. 好奇專案的目標，iCHEF 產品團隊平時是如何去討論，讓利害關係人和自己都能站在同一條線
🔹 Kat：我們身為在同一間公司的員工，一定是站在同一條線的，就算我們的職責不同，但我們的使命都是相同的。正如前文所述，站在同一條線不代表他們要同意所有的設計方向與決策。Design Review 的目的不在於消弭掉任何建議或反對的聲音，而是營造一個安全的環境，讓大家都能提出想法。
四、測試與研究
Q9. 易用性測試可以用什麼樣的方式呈現，才能讓夥伴更能理解易用性測試的結果，有什麼工具嗎
🔹 Kat：可以先思考對方想要了解易用性測試的什麼部分，再決定要呈現的內容與篇幅。例如：
- 目的：為什麼要執行易用性測試？希望驗證或是蒐集什麼回饋？
- 流程：篩選受測者的條件、測試腳本內容、執行測試的方式
- 結果：易用性測試後得到的 insight、設計做了哪些相對應的調整
Q10. 若是支持設計的佐證資料只來與自利害關係人的言論該怎辦？本身公司內部沒有足夠的資源做研究，還是 Design Review 就不需著重這部分的討論？
🔹 Kat：有幾個可以思考的面向
- 利害關係人也許對產業洞察很深，所以他的言論可能就足以支持設計了
- 若還是會對設計感到不確定，也可以找內部其他同事做簡單的易用性測試
- 就算把握度還是沒有很高，設計上線後仍然可以繼續迭代，反覆實驗
也可以參考 UX Stone 撰寫的文章，了解不同資料的「信心程度」為何
感謝看到這裡的你！
要記得，接受和給予回饋都是需要不斷練習的，如果真的卡關了，也要適時尋求嚮導（團隊中資深夥伴）的協助。尋求協助不意味著這是弱者的展現，正好相反，正是因為足夠瞭解自己、知道在什麼時機點需要借助外部資源，才能順利推動專案進行。
最後送上《男孩，鼴鼠，狐狸與馬》的這張圖，期望我們都能成為幫助對方的力量。
🔗 iCHEF Yourator｜最新職缺都在這裡
🔗 iCHEF Medium｜不定期分享設計文章
🔗 iCHEF Q 報｜最真實的團隊幕後記錄
