設計師能理解的需求

轉到交互崗已經有一陣子了。原來在做產品的幾個月里沒少和技術、設計進行溝通，每當自己把意思想法傳達下去的時候，反饋回來的結果基本都要進行進一步的修改，這種返工和修改在產品快速迭代的過程中很浪費時間。當時自己沒有覺得表達有問題，已經把需求的目的結果都表達清楚了。可能是自己沒寫過代碼、沒做過設計所以在一些專業的術語的表達上，方案實現方式的選擇上存在偏差，導致技術、設計沒有完全按照自己設想的預期做出結果。

要是這麼說產品經理只要學習了解一些設計的基本原理並且能看懂簡單的代碼是不是這種溝通就不會存在障礙了呢？當我在設計崗上工作了一陣子後發現自己不僅僅是在工作職能上進行了轉變，更是一種團隊中角色定位的轉變。所以產品要將需求的預期結果交代給設計的時候並不是懂設計（不要對比這麼強烈；顏色太跳躍等等）就能把結果表達的很清楚，更多的是站在設計的角度將原始的需求轉化後傳達給設計。

下面我舉一個這周工作中的小案例

一天我接到了產品提的一個需求，「我們後台新加入了一個功能，能不能給我設計幾個好看的圖標。我自己做了幾個方案總覺得不好看，你給我設計一下吧。畢竟後台我們自己用不面向用戶，不用太精細，謝謝啦！」然後隨手甩給我一張圖。

打開看到這個demo後並沒有一下將焦點集中在想要修改的icon上，而是把自己當做是用戶思考地圖上面這幾個東西我能用它們來幹些什麼。可能是從產品轉過來的緣故吧，並沒有像其他設計師一樣只把產品給我的需求做好就行，我必須要明白我這麼做能給用戶帶來什麼功能和方便。所以我思考片刻後，找到產品接連問了以下幾個問題「地圖上的字和icon是可點擊的按鈕還是提示？它們分別能實現什麼樣的功能？用戶能得到怎樣的方便？」

「是可以點擊的按鈕，可以讓用戶實現手動標記位置和自動定位間切換，定位之後可以保存」這時我大概理解產品想要什麼了，是一種功能的切換和對於結果的保存。那完全可以不用Button的形式去展現，用Tab會更好，不但能實現功能的切換並且能讓用戶知道當前選擇的功能。至於保存結果下方已經有「保存」的button了，所以沒有必要在地圖上再加保存功能。於是我輸出了下面的圖：

產品看過之後表示這不是她想要的結果，我只是想在自動定位定不準的情況下可以手動進行修改，打開頁面時已經存在定位為了防止誤操作是不能修改的，然後如果想修改定位可以選擇「手動標記」。這中間還有其他溝通的環節，然後我輸出了下圖

第二次修改結果

產品不要求再改了，這一個小工作算是搞定了。

雖然是個很簡單的工作但是中間付出了不少溝通成本，所以覺得有必要拿出來總結一下：從最初的「給我設計一個好看的icon」—>「可以在定位時手動自動切換」—>「用戶可以修改自動定位不準確的位置」。其實最後還有一個最終的需求「我要後台定位準確」。前三個都是產品在這次任務中向我表達的需求，我在充分理解第三個需求後便可做出產品經理想要的結果。最後的那個需求是這個產品的最終需求，但作為設計師充分理解第三個足矣。

再舉一個例子，是來自百度設計總監史玉潔在一次演講報告中提到的。老闆提出來一個需求「我要設計師給我在這個頁面下方加一個大的、紅色的、醒目的按鈕」。細細分析一下，把這個需求按照上面例子的格式寫出來便是「我要一個大的、紅色的、醒目的按鈕」—>「用戶可以有慾望去點擊」—>「我只是想提高這個頁面的轉換率」。

第一個是表達層面的需求，即使產品再懂設計也只是可以提出一些意見，而不應該對設計層面的東西指手畫腳。如果你說顏色不好看，形狀太小這些設計層面的問題不如從用戶角度說明這個問題更讓設計師信服。最後一個是整個產品層面的需求，可以讓設計師去參加產品需求會議去了解，在產品快速迭代中不必再重申產品層面的需求。第二個是站在設計師位置以用戶角度提出的需求，也是設計師真正能理解的需求。所以給設計師提出的需求一定要用設計師的需求語言。這裡引用一篇Facebook產品設計總監Julie Zhuo的一篇文章。

設計師尤其是交互設計師本身就是個定位很模糊的職位，因為在產品整個開發的過程中，各個環節都會影響到用戶體驗（這個詞實在是太大了，工作越久越不敢輕易脫口而出）但是設計師是最能站在用戶角度去考慮問題的崗位。產品需要為用戶考慮體驗問題，但是產品更需要去權衡整個框架，包括開發周期、實現方式、運營方式等。權衡各個問題的比重而不會完全將產品的重心放在用戶體驗上。工程師使用的開發技術也會影響到用戶體驗，但他們更多把重心側重在產品的實現、邏輯、可修改性等等方面。所以在產品開發的各個環節設計師是把手用戶大門的角色，他們的存在就是在團隊中爭取更多的資源為了用戶。

這麼說來就不難理解為什麼在給設計師提需求的時候應該多站在用戶角度，以設計師的角色去給他們提需求。

最後回到文章開始所說的，並不是了解設計和技術就能和他們進行無障礙的溝通。更多的是要理解各部門在開發中所扮演的角色、負責的首要任務。設計師們在得不到明確的需求時應該多去和提需求方溝通，引導需求方將隨口提出的需求轉化成屬於自己角色的需求。往往了解產品業務的聰明的設計師會對別人提的需求有更好地理解，而不是片面的只聽到了「需求」，會根據業務推導出屬於自己角色層面的需求。讓設計師參加產品需求會議就顯得格外重要，而很多團隊只是把設計師當做幹活的美工，在不了解業務的情況下增加很多溝通成本。

今天主要是以設計師的角度通過工作中的事情和自己平時所看所學思考的一些問題。團隊中的交流溝通實在是一個大的話題，還會牽扯到很多其他因素，我會隨著工作經驗的積累慢慢再對溝通問題做進一步深入討論。