老板說字體要大要紅色，其實是想引人留意，進一步提升點擊率和轉換率。所以無論是設計師還是甲方，在提出/接到需求時都不應當簡易粗暴地執行，反復洽談找出最本質的需求才能讓彼此都滿意。多說無用，徑直來看在工作中的真實案例。
轉到交互崗已經有一陣子了。原來在做產品的幾個月里沒少和技術、設計實行洽談，每當自己把意思想法傳達下去的時候，反饋回來的結果基礎都要實行進一步的修改，這種返工和修改在產品火速迭代的進程中很浪費時間。當時自己沒有覺得表達有問題，已經把需求的宗旨結果都表達清楚了。可能是自己沒寫過代碼、沒做過設計所以在有些專業的術語的表達上，計劃實現方式的選取上存在偏見，造成技術、設計沒有完全根據自己設想的預期做出結果。
一天我接到了產品提的一個需求，“我們后臺新加入了一個功能，能不能給我設計幾個好看的圖標。我自己做了幾個計劃總覺得不好看，你給我設計一下吧。畢竟后臺我們自己用不面向客戶，不用太精細，謝謝啦!”然后隨手甩給我一張圖。
打開看到這個demo后并沒有一下將焦點集中在想要修改的icon上，而是把自己當做是客戶考慮地圖上面這幾個東西我能用它們來干些什么。可能是從產品轉過來的緣故吧，并沒有像其他設計師一樣只把產品給我的需求做好就行，我必須要明白我這么做能給客戶帶來什么功能和方便。所以我考慮片刻后，找到產品接連問了以下幾個問題“地圖上的字和icon是可點擊的按鈕還是提醒?它們分別能實現怎樣的功能?客戶能得到如何的方便?”
“是能夠點擊的按鈕，能夠讓客戶實現手動標記位置和自動定調間切換，定調之后能夠保存”，這時我大約了解產品想要什么了，是一種功能的切換和對于結果的保存。那完全能夠不用Button的模式去展現，用Tab會更好，不但能實現功能的切換并且能讓客戶知曉現在選取的功能。至于保存結果下方已經有“保存”的button了，所以沒有必要在地圖上再加保存功能。于是我輸出了下面的圖：
產品看過之后表示這不是她想要的結果，我只是想在自動定調定不準的情形下能夠手動實行修改，打開頁面時已經存在定調為了避免誤使用是不能修改的，然后如果想修改定調能夠選取“手動標記”。這中間還有其他洽談的流程，然后我輸出了下圖：
產品不要求再改了，這一個小工作算是搞定了。
固然是個很簡易的工作但是中間付出了不少洽談成本，所以覺得有必要拿出來總括一下：從最初的“給我設計一個好看的icon”—>“能夠在定調時手動自動切換”—>“客戶能夠修改自動定調不準確的位置”。其實最后還有一個最終的需求“我要后臺定調準確”。前三個都是產品在這次任務中向我表達的需求，我在充分了解第三個需求后便可做出產品經理想要的結果。最后的那個需求是這個產品的最終需求，但作為設計師充分了解第三個足矣。
我在充分了解第三個需求后便能做出產品經理想要的結果
再舉一個例子，是來自百度設計總監史玉潔在一次演說報告中提到的。老板提出來一個需求“我要設計師給我在這個頁面下方加一個大的、紅色的、醒宗旨按鈕”。細細解析一下，把這個需求根據上面例子的格式寫出來便是“我要一個大的、紅色的、醒宗旨按鈕”—>“客戶能夠有欲望去點擊”—>“我只是想提升這個頁面的轉化率”。
告訴設計師，看到這個頁面客戶想要去點擊這個按鈕
第一個是表達層面的需求，即使產品再懂設計也只是能夠提出有些意見，而不應當對設計層面的東西指手畫腳。如果你說顏色不好看，形狀太小這些設計層面的問題不如從客戶角度介紹這個問題更讓設計師信服。最后一個是整個產品層面的需求，能夠讓設計師去參加產品需求會議去理解，在產品火速迭代中不必再重申產品層面的需求。第二個是站在設計師位置以客戶角度提出的需求，也是設計師真確能了解的需求。所以給設計師提出的需求務必要用設計師的需求語言。
設計師尤其是交互設計師本身就是個定調很模糊的職位，由于在產品整個開發的進程中，各個流程都會影響到客戶體驗(這個詞實在是太大了，工作越久越不敢輕松脫口而出)但是設計師是最能站在客戶角度去思考問題的崗位。產品需要為客戶思考體驗問題，但是產品更需要去權衡整個框架，包含開發周期、實現方式、運作方式等。權衡各個問題的比重而不會完全將產品的重心放在客戶體驗上。工程師操作的開發技術也會影響到客戶體驗，但他們更多把重心側重在產品的實現、邏輯、可修改性等等方面。所以在產品開發的各個流程設計師是把手客戶大門的角色，他們的存在就是在團隊中爭取更多的資源為了客戶。
這么說來就不難了解為何在給設計師提需求的時候應當多站在客戶角度，以設計師的角色去給他們提需求。
最后回到文章著手所說的，并不是理解設計和技術就能和他們實行無障礙的洽談。更多的是要了解各部門在開發中所扮演的角色、負責的首要任務。設計師們在得不到明晰的需求時應當多去和提需求方洽談，引導需求方將隨口提出的需求轉換成屬于自己角色的需求。往往理解產品業務的聰明的設計師會對別人提的需求有更好地了解，而不是片面的只聽到了“需求”，會按照業務推導出屬于自己角色層面的需求。讓設計師參加產品需求會議就顯得格外緊要，而許多團隊只是把設計師當做干活的美工，在不理解業務的情形下提升許多洽談成本。
聰明的設計師在理解業務后能推導出屬于自己角色層面的需求
今天緊要是以設計師的角度通過工作中的事宜和自己平時所看所學考慮的有些問題。團隊中的交流洽談實在是一個大的話題，還會牽扯到許多其他原因，我會隨著工作經驗的積累漸漸再對洽談問題做進一步深入探討。
