為了讓自己的設計充分解決問題,每一個設計師都會嘗試收集很多同行、用戶的建議,這是一個需要彼此充分溝通的過程。但是往往這種溝通會變得不那么愉快,設計者覺得對方不懂,對方覺得設計者不接受自己的意見,反饋了也沒用。有了不愉快的經歷之后下次可能設計者就不會去尋求更多的建議,只是憑借自己的經驗去做決定。這對于達到優秀的設計起不到任何幫助。對這件事有一些簡單的想法,寫下來希望對大家有點用。
這里的「心態」是一個廣義的概念,這里主要說一下我覺得最重要的「防御心態」。這種狀態一般會表現出兩種情形:過度保護和過度開放(這個詞可能不太恰當,領會精神)。在很多設計反饋的討論中,很多設計師都或多或少的有一些防御心態,這樣的心態會讓大家覺得這是一場 Challenge 大會,一定要有贏家和輸家,于是整個討論就變得火藥味十足,設計者開始保護/放棄自己的設計,反饋者忘了設計目的,不停的雞蛋里挑骨頭,最終大家不歡而散。
在反饋之初,參與雙方要保持一個平等的態度,在提供反饋時注意自己的措辭,不要急于否定對方的看法,保持開放的心態,當出現「防御心態」的時候需要及時提醒對方(當然很多時候他們會覺得自己并沒有處于防御心態)。Asana 的聯合創始人 Justin Rosenstein,他發明了一種「D」手勢,用來提醒在討論過程中陷入「過度防御狀態」的設計師,這也是一種很好的做法。
這里的對象指提供反饋的人,最好的情況是你可以對所有人一視同仁,但肯定會有一些人是你喜歡與之交流的,有一些人你是比較反感的。當遇到你不喜歡的人時,不可避免的你會出現上面提到的「防御心態」,這對于收集到良好和正確的反饋是不利的,所以在你做到對所有人一視同仁之前,建議去找那些你喜歡并且你認為能切實給你建議的人。
一個好的設計反饋應該至少有 1/3 的時間是聽設計者講自己的想法,在這個過程中合適的方式來闡述方案很重要,有的人喜歡搞個 Keynote,有的人喜歡用白板,不論用什么,只要能讓自己自然完整的闡述設計方案就是好的方式。
很有可能大部分人都不了解這個設計的背景、要解決的問題等等,準確完整的表達自己的想法至關重要,建議表達的思路從 Why(這個設計解決的問題是什么、為什么要解決這個問題) - How(通過什么樣的思路解決、有過哪些嘗試、優劣勢分別是什么) - What(想過哪些具體方案、為什么最后得到這個結果、這個方案的優劣勢是什么) 開始,然后說明希望自己遇到的問題以及希望從反饋者得到哪類信息。我一直認為不了解設計背景和方案成型過程的人是沒法給出針對性有效反饋的,所以這一步至關重要,不要因為時間原因放棄這個過程。同時設計者本身要控制好其他人,不要被其他人在這個過程中打斷。
很多反饋者會直接在反饋中說:你把紅色變成藍色,透明度降低 20%,不要覆蓋界面……我認為這樣是不好的,這樣會使得設計者放棄后續的思考過程,直接采用對方給出的方案,而這個方案不一定是最優的。所以我認為好的反饋應該是下面這種:
這個設計面向的用戶是 XX 類型,我們要解決的是這些用戶從場景 A 到場景 B 時遇到 C 問題,這個設計是從 D 角度出發,如果是這樣可能會引出問題 E,如果沿用該設計,那問題 E 是否需要解決?
如果這是一個問題,得讓設計者感同身受,準確且清晰的描述問題,然后讓對方想想如何去解決這個問題。不要急于給出自己的解決方案,讓對方有過思考之后再討論具體的方案實現。這樣可以讓彼此在想法上對等,信息充分之后交流效果更佳。
主觀看法沒有問題,很多有趣的思路都是從主觀看法演變而來的,但不要只有主觀看法。「我覺得用戶不會喜歡這個」、「我不喜歡這個思路」、「這個想法太傻了」如果你說出了這些話,其他人一定在期待你給出一個更好的想法,但如果你沒有更好的想法,那他們就會覺得你是來攪局的,以后就不帶你一起玩了,所以最好有一些客觀「事實」或「數據」來證明你自己的看法,這樣會讓他們更尊重你。
很多人會用「我這個人說話比較直」為由來激烈表達自己的看法,但對于某些年輕、內向、內心不夠強大的設計師來說,這種對話可能會讓他們并不是那么舒服,進而對設計反饋這事產生疑慮。能在一起工作的人水平也差不了太多,仔細聽完對方的表述,平和的交流。
我們在設計中面臨的問題可能是下面這樣

期望的解決方案是下面這樣

但實際上我們設計的解決方案是下面這樣

一個好的設計反饋可以幫助我們在上線前就盡可能避免出現上面這樣的結果,同時增強團隊信任,了解彼此的工作和性格,更好的推進產品本身的改進。
北京星誠視野網絡科技有限公司 © 2008-2022 京ICP備09003513-1號 技術支持:北京網站建設公司 北京APP開發