大家可以看到上圖是我們常見的設計流程，需求方或用戶提出需求，產品經理整理需求，最后才反饋給設計師開始設計。這看似司空見慣，但是卻會造成一些問題：
1，信息滯后：大部分需求設計師都是最后一個知道的，也許在知道之前，產品經理和領導就已經討論完了，甚至有了基本的設計解決方案。設計在最后才介入，只能做一些執行的工作。
2，目標不清：因為設計師無法了解原始的場景，當時用戶的問題和需求點都沒有自己感受到，只是別人傳達的。那么可能會被傳達少一些，或者加入很多主觀的想法歪曲了一些，這樣設計師所了解到的設計目標可能根本就不是一開始想要的。
3，進度失控：大部分情況下項目周期可能都是領導和產品經理訂好了，什么時候立項、什么時候測試什么時候上線。等到某一天突然找設計師要圖的時候，天啊~完全沒有準備好！
尤其是像我們獵豹移動是一家產品經理為主導的公司，產品經理有很大的影響力和信息的壟斷性，表現到煩惱上就是——大家覺得產品經理太強勢了！但是后來我仔細想想其實這也不算什么問題，百度也是工程師文化，阿里也是運營文化，估計除了蘋果以外設計師在哪里都得面對這樣 的現實。
如何解決這些煩惱？
在聊如何解決的時候，我想說一下假如這些煩惱都已經解決了，假如有一種符合設計師的理想模式，那會是怎樣的？
1，設計師由接任務變為推動設計：傳統的情況我認為設計師都在接任務，接受別人的任務并且完成，這樣不斷的反復。但是在理想模式下設計師可以推動自己認為美好和正確地事情去變為現實；
2，設計師自己掌控自己的時間：尤其是設計師可以為自己留出認真思考和創新的時間，而不是始終疲于奔命；
3，方案的通過率高：指的是我們只需要出那么一兩稿，就可以基本確定大方向，不用一直繞圈子；
而在這種模式下，我覺得設計師已經不再是流程的下游了，而是某些意義上來說，設計師在領導整個團隊推進產品設計的提升，這就是設計師掌握了主動權。
大家可能會覺得這種夢寐以求狀態實在太理想了，也可能會問到底應該怎么做才能掌控主動權呢？其實我也沒有完全做到這種狀態，但是我們團隊始終在以這個目標不斷的嘗試和改進自己的工作方法，在很多情況下都已經產生了不錯的效果，所以想分享一下我們的經驗：
1，設計師要做到知己知彼，掌握全面的信息
我曾經做過瀏覽器的交互設計，我經常接到的需求一般會類似于 “做一個加載網頁的進度條”，要是平常可能大家就這么去認真的研究這個進度條了。但是我們會首先放在整個產品架構上去看這個需求，進度條是屬于網頁速度體 驗的一個環境，那么和安全、瀏覽器性能上有什么關聯呢？又或者在表現形式上，加載的進度條和下載的進度條有什么區別呢？
所以我們的設計師會維護一個產品的用戶體驗架構，看問題并不是只看一個點，而是看一個面，并且看到他們之間的聯系。這樣可以提升我們的反應能力和設計的精準性，而要做到它就必須建立在有非常充分信息的基礎上。
1.1 我認為設計師要掌握的信息有三類，第一個是要了解產品的戰略方向。
具體表現就是產品的商業目標：為什么要做這個產品？以及產品的策略：通過什么方式來實現這個目標？
剛加入金山調入瀏覽器部門的時候，上班第一天我就問領導一個問題 “為什么要做獵豹瀏覽器”，當時領導一副詫異的表情類似 “你一個美工干嘛要問這個？”。后來經過長聊之后我們才溝通清楚，作為設計師，之后的每一項方案、每一個研究和思考的方向、每一次設計決策，都是為了幫助 實現你的產品目標。所以如果能溝通清楚讓大家都清晰才能夠更好的協作和執行，甚至讓設計師發揮自己的主動性來達成目標。
給大家舉個例子，一年之后我們進入海外市場，當時海外的瀏覽器市場還沒有飽和，移動瀏覽器的技術瓶頸也還沒有到。所以我們決定做一款“最快的手機瀏覽器”，依靠簡單的速度去贏得用戶的口碑。
但是可能很多人就問，“快”不是性能和開發的問題嗎？和設計有什么關系？其實快不僅是性能，視覺上的簡潔輕巧，交互上的化繁為簡，都是用戶能真切感受到的“快”。
所以當時我們做的第一件事情就是把主題改成白色了。獵豹的品牌色一直是黑色和橙色，非常重的質感，老板很喜歡。所以我們這個改動不是一般的難，一來它觸犯了品牌一致性的大忌，二來非常難說服老板上個年代的審美觀。但是因為強烈的目標感，大家最終還是推進下來了這件事情。
所以就是這樣幾張簡單的圖，我們在感官上給了用戶順暢和快速啟動感受。
所以其實在實際工作中，產品的方向深刻的影響了設計師的每一個判斷和思考，同樣也影響了設計師的效率和成敗。有的時候我們只覺得管好眼前的事情或者分內的事情，殊不知反而會帶來更多的迷茫、爭執和不理解。
1.2 了解用戶反饋和數據
在傳統的流程下設計師大部分情況可能都不會直接接觸到數據和用戶反饋，而是經過運營或產品經理整理，或者好一點的公司還能有用研給一個結論。更有的同學覺得，數據和用戶反饋不就是產品經理和運營用到的嗎？設計主要還是靠美感和品位。
但是更多時候設計是解決問題的，問題的來源往往就來自于數據和用戶反饋。可是數據和反饋并不能直接給出設計師想要的目標，它們僅僅是素材，運營同學 可以從中看出如何改善運營活動，產品同學可以從中挖掘需求，所以設計同學也應該自己去研究和消化數據和用戶反饋來改進自己的設計。
我們團隊的流程通常是這樣的，有一位專門的同學每天收集來自各個渠道的用戶反饋然后發給團隊所有成員，如果大家有興趣的話，可以挖掘用戶的原文并且找到用戶的聯系方式繼續深聊。如果數量多或者比較嚴重，則會在討論會上各個角色都提出自己的專業建議，并且討論項目排期和改進計劃。
數據也是一個道理，數據的漲跌會因為很多復雜的原因造成，各個角色也會參與和跟進到數據的變化的分析中。有的時候我們的設計師會做出很多種設計樣式小量測試，然后看數據的變化來得出最佳的設計方案。
所以這兩樣東西設計師不光是簡單地看：反饋的原始場景是什么？反饋的是什么樣的用戶？能否深挖這個反饋，和用戶聯系？
也不僅僅是看而已：收集并且觀察，重要的還得跟進細節；長期保留作為以后設計決策的依據；長期觀察，提升自己對用戶和數據的理解；
1.3 了解項目計劃
設計師對項目計劃有很強的被動感，很多時候覺得反正你們定好我按照安排做就行了，不知道也不想知道別人都在干什么，但是這樣往往最終都給自己帶來了麻煩。
有一次周五下午一個產品經理找我說有一個很急的需求，希望我周一的時候能給出方案。當時我就懵了，這不是要我周末加班嗎？ 說好的和妹子看電影什么的。于是我反問他項目計劃，為什么周一要方案。原來周一的時候產品經理例會，他要給產品總監匯報這個需求但是沒有原型無從說起。經 過了解后我們達成一致，我先給他一個粗略的方案，能夠表現出大概的交互方向，然后等之后在確認了我再補充上各種細節和分支，這樣即滿足他也不會耽擱我很 久。
所以設計師如果對項目計劃的各個節點都充分了解不但可以避免誤會和爭吵，還能提前準備和思考，把控自己的工作節奏。比如：
什么時候可以定設計方向？（提前做好充足的準備，探索風格）
什么時候開發要介入？（需要給出基本框架和布局）
什么時候開發會細調界面？（需要給出細節和標注了）
什么時候測試和上線？（要和開發一起調試實現效果）
上線之后效果的反饋周期？（幫助自己驗證和改進設計）
但是在了解和思考項目計劃的時候有一點需要注意的是，設計師的考量標準是目標和結果而不是項目計劃中對方的要求。經常有的項目計劃太 緊張讓我喘不過氣來，但是卻想要很高的結果。比如產品經理說希望改進界面大幅度提高用戶口碑，但是卻只給我半周的時間，如果我客觀分析了不行，我就會直接 告訴他說半周我能完成一個新的設計方案，但是絕對做不到想要的這個結果的。這是能力問題，要不你換個大價錢找個能做到的，這次逼我也沒有用啊。
2，設計師要明確設計目標
2.1 思考設計目標是什么呢？我到底做這個設計方案是為了解決什么事情？
首先 “解決方案” 絕對不是目標，我們大部分時候接收到的其實都是解決方案而不是目標。比如產品經理有的時候說：“你要新加一個按鈕，或者新加一個紅色的按鈕”。但是新加按鈕其實是為了為某個功能做一個入口，入口一定要是按鈕嗎？是不是banner，卡通圖形也可以？而要做紅色的按 鈕也許是為了強調這個入口，那么強調的方式也可以有很多種，除了顏色以外，布局位置，周圍的留白，陰影和質感都可以起到強調作用。
所以有的時候設計師聽到需求方這么具象的要求都很生氣，心里想著 “哇靠明明和我們風格不符沒辦法這樣做好嗎？要不你來做 “，但是實際上都是因為互相都沒有深刻去挖掘目標。這樣的例子還有很多：
1，設計一個注冊流程 = 滿足用戶收藏的欲望 = 真的需要注冊嗎？
2，增加幾張啟動歡迎頁面 = 告訴用戶版本新功能 = 放在場景中引導是否更有效？
3，將banner做大一些 = 提升30%的轉化率 = 內容是否也有改進余地？
2.2 為誰而設計？
我們做UE行業的人有一個單純而美好的錯誤，就是認為我們都是為用戶而設計的。但是現實很殘酷，除了用戶，我們還要考慮為公司的商業利益而設計，甚 至是為領導而設計。在做設計的時候如果沒有考慮到這兩點可能方案就被莫名其妙的拍死了，有的人還會因為挫折太多而開始反思自己的志向。
有一段時間我特別苦惱公司的商業化目標，因為以前一直埋頭做用戶口碑，想著把產品體驗做好就可以了。但是產品突然到了收割 期介入了很多“商業產品經理”，提出過很多超出自己底線和無理的需求。剛開始的時候我還一直不理解和反抗，但是仔細想想我才明白，商業化本身和用戶體驗不 沖突。所謂用戶體驗，本來就是在幫助公司實現商業價值的前提下，盡量讓產品保持好的體驗的。
而想明白了這個，就開始更積極的去想如何把商業化的體驗做好。比如提升廣告質量，在場景和使用路徑下做精準化投放等。其實很多人覺得商業化是萬惡之源，只是因為大家都打著商業化的旗號而懶于思考，見縫插針，簡單粗暴做事情罷了，而沒有真正的擁抱和思考它。
2.3 規劃目標的優先級
如果我們設計師接收到的目標只有一個，那干活的時候就太輕松了，因為我們只要稍微挖掘就可以知道應該怎么做。但是到現實中我們往往遭遇的矛盾就是感 覺通常目標都有好多，產品經理這也想要，那也想要，這也不能丟，那個也很重要，到底要怎么辦？最有趣的段子就是需求方的要求是：高端大氣有檔次，低調奢華有內涵，簡約中帶著點霸氣，既體現歐式奢華又能傳承中國古韻…（笑）。所以我們通常接收到的需求，都是會包含很多目標的，我們要把這樣目標分解成優先級：
1，核心目標：核心目標只有一個，是最符合本次產品設計和改版根本緣由的。我通常會和產品經理說假設因為時間和能力有限，他提的所有的要求中我只能實現一個，他會怎么砍？殘酷和艱難的抉擇留給對方自己，因為只有明確了唯一的核心目標，設計師才能在日后有什么沖突和矛盾的時候做出爭取的抉擇和判斷。
2，兼顧目標：除了核心目標以外，需求方還會說很多“這些最好也需要達到”的目標，比如和品牌相統一，盡量保證開發性能之類的。對待兼顧的目標我的 原則是如果能實現我就盡量實現，但是實現不了或者與核心目標有沖突則果斷砍掉。有的時候設計師會和產品經理一起糾結在這些兼顧目標中去，糾結完其中一個又 糾結另外一個，所以如果之前已經和對方溝通過核心目標，當發生矛盾的時候大家砍掉就變得很自然。
3，有則更好：這個比較簡單，就是能做到最好了，需求方也不做特別要求。但是很多時候需求方認為只是有則更好的東西，到了設計師眼里變成很重要的東 西，比如做的超華麗，可以發到網上無數點贊的那種。這就需要設計師理解設計的根本是幫助產品解決問題的，優先做好核心目標再思考在這個地方的提升會更受大 家歡迎一些。
那么在現實中我是怎么用這個思想去指導設計決策呢？
比如作為交互設計師，我可能會接到需求是要 “設計一個App的導航方式”。我會先把各種可能應用到的導航方式全部列出來，并且分析他們各自的優點和缺點。然后我判斷的依據是：它的優點是解決核心目標最佳的方案，而它的缺點又是可以被容忍的，這就是最合適的方案。
比如像上圖，如果我要設計的是一個像新聞一樣的沉浸閱讀App，就會傾向選擇抽屜式導航。而如果是強調不同模塊的互動，強調用戶去參與更多功能的，就會選擇普通的底部tab形式。
想做到這一點，多了解導航的基礎知識是非常有必要的。
2.4 保持目標的導向性
給大家舉一個例子，有一次我去找領導討論，想確定一個導航方式的時候：
我想很多設計師也會這樣吧，發現自己在和外部討論的時候總是很容易被說服，或者發現最終討論的結果不是一回事，自己又在不停的改一些無關緊要的東西，方案為什么不能很快被完結呢？其實就是因為在后續的推進和溝通中沒有保持目標的導向性。
我的經驗是，先聚焦在如何推進和解決最關鍵的部分上，暫時忽略分支和細節。比如在對一些設計稿的時候領導和其他人總會針對一些小地方提出自己的建 議，我都會拉回來說咱們這次主要是定xxx，其他地方后續我們可以慢慢修改。這樣就相當于把自己的工作分了步驟，不至于繞一大圈而丟失很多效率。
3，加強設計的推動力
我一直有一種觀點，就是認為如果沒有被最終實現的設計不能算作真正的設計作品。因為從本質上來說它沒有帶來任何價值，也沒有解決任何用戶的問題，只 是流于形式和藝術。所以要做到這將設計落實下去，設計師就應該不斷地思考如何把提升自己的推動力，這些不僅僅考驗的是出圖的能力，對設計師的溝通力和把控 力也有了很高的要求。
我認為首先要做到我之前說的兩點（也就是了解信息和明確目標），另外還可以分享一些提升推進力的具體流程和方法：
3.1 更前置的開展設計工作
場景A：PM來找到設計師說 ：“小U，老大說這個地方體驗不好，咱們改一下吧，后天要發版所以你明天給我方案好了。”
場景B：設計師找到PM同學說 ：“小P，最近我們的用研發現A流程的體驗還有問題啊，我們想了一些解決方案并且有一個不錯的，所以你看看什么時候能夠協調出開發資源呢？ ”
大家覺得，哪一個場景更好？
我們認為要做到場景B，就得有一套前置開展設計的流程和方法。我們團隊的設計師在看待設計工作的時候并不是看成一個點，而是看成一個面，一套體系。 比如說我們會維護一個用戶體驗地圖，將產品的使用流程分解，去標注每個節點都有什么做的好的地方和差的地方，這樣就可以直觀的反應出哪里的體驗還有改進的 余地。加上之前我們對信息的收集和目標的確定，設計師在產品經理提出具體的要求前，就已經可以大概知道哪些地方需要改進和提升了。
用戶地圖是很實用的設計工具，建議設計師們都掌握起來：
接下來的我們會把問題池中的重要問題提煉出來，然后去規劃它的解決方案。比如UX內部自己開展一些用研計劃、概念稿、可用性測試，直到我們認為出現 了一個不錯的可解決的方案。接下來就是在合適的時間去推動整個產品團隊實現這個方案，比如在技術成熟，資源有富余，或者領導正好關心這一塊的時候適時的提 出來。而暫時還沒有推進的方案我們則會保留下來，這樣下次有人再提出來的時候我們不但已經非常了解了，而且可以很快解決問題。
3.2 主動發起和跟進
之前講項目計劃的時候也提到，很多設計師都只關心自己這一塊的工作，而沒有去Push大家的習慣，比如圖已經做好了一封郵件丟出去就不管了，反正等結果就好了。但是實際上我就遇到過很多坑，比如丟出去圖產品經理沒有反饋，等到好幾天后又突然反饋說不行再改改，但是離完結時間也沒多久了。或者又一次其他人選了一個站在設計角度不是最優的方案，我當時也因為懶也就沒有再去爭了，但是最后被老大看到還是痛批了一頓老老實實改。
所以說到底設計師根本是為了自己的設計結果和效果負責的，而不僅僅為了完成當下的任務，設計師還得自己去發起和跟進自己的設計。
1）主動發起設計評審：
完成了方案就及時的找相關的人討論，而且要發起會議，不是簡單地丟一封郵件給對應的產品經理，這些人可能包括領導，開發，測試等。
為什么要這樣呢？因為點對點的溝通沒有面對面的溝通效率來的高，大家可以集中把意見都提出來，省下一個環節一個環節的麻煩。
2）增加大家的參與感：
就是在正式的評審環節前，讓各自利益相關的人看一看，聽聽他們的想法和建議。
大家有沒有這樣的經歷？開發如果覺得這個設計方案不好實現，往往不會說開發難實現，而是會說這個設計不好看或者體驗差。這因為在公開場合示弱往往是很不好意思的事情，所以提前去了解一下大家的想法和建議，這樣才可以平衡各方的利益，免得被一次拍死。而且如果你私下采納過大家的想法，對于其他人就有種 “自己也參與了這個設計，這也是我的方案” 的感覺，是可以潛在的獲得更多支持的。
3）跟進開發實現的效果：
很多人會把跟進實現的工作丟給產品經理或者項目經理，但是其實他們是不懂設計的，也沒有像素眼，很多細節點理解不到位。所以設計師自己去盯去看還是很重要的，用戶在用得不爽的時候只會罵設計師，才不會記得你的設計稿呢。另外在獵豹招聘設計師的時候，能有實現的產品我們都只看實現的效果，如果對方說是實現不好，我們都會反問 “那為什么你沒有把控好實現的效果？”
3.3 管理產品經理
這一點聽起來很奇怪吧？明明是PM管理我們吧？尤其是在獵豹移動和360這樣產品經理強勢到類似領導的公司，或者很多小團隊中沒有獨立的UX部門， 設計師本身就依附在產品經理下面。但是我想說其實產品經理只是設計師順利工作的一個因素罷了，以正確的方式面對產品經理的需求，并且適當的提出質疑和建 議，獲得他們的信任。在某些程度上，還可以利用產品經理對整體需求和資源的把控優勢來推進很多事情。
所以轉變觀念很重要。
Review
最后說了這么多，其實核心的觀點就是：了解信息 – 明確目標 – 推進設計，如果要再深入展開的話會還能有很多的內容和案例可以講。但是大家一定有一個疑問：我平時都忙的要死，哪還有時間和精力去做這么多事情？
其實我認為大部分人，真正有效的工作時間都只有40%，而浪費在爭吵、等待、理解錯誤和反復修改的時間上確是大部分。所以與其浪費時間做錯誤的事情，還不如多多思考該怎樣改進自己的工作方法，怎樣養成一些好的習慣。
本文轉載于:http://www.uisidc.com/designer-have-the-initiative
