設計師如何掌握主動權

今天想和你們聊一聊設計師的煩惱，由於我本身是設計師，周圍的朋友也大部分都是作設計行業的，你們交流的時候不免吐吐槽，說說本身的煩惱。可是聽多了以後發現設計師的煩惱仍是挺有規律的，無非就是這三大類：

1，太着急：常常早上提的需求下午就要，沒有時間認真打磨和研究，更別提什麼創新了。老是被需求方催着，只能草草了事，本身都不忍心看。

2，修改太多了：感受對方也不知道要什麼，怎麼作都要被修改，你們都很糾結.

3，被指點江山：尤爲是被不懂設計的人指點江山，常常提一些很主觀和細節的要求，感受還不如讓他們本身作得了。

可是認真感覺這些煩惱以後，發現一個更嚴重的問題就是：大部分設計師都沒有設計的主動權。圖是設計師在作，可是設計的過程和結果卻不是設計師本身可以掌控的。

因而我就在想爲何會形成這樣的問題，固然緣由有不少，但是有一個很根本的緣由就是在如今的互聯網設計流程中，設計師自己就是處於整個流程的下游。

你們能夠看到上圖是咱們常見的設計流程，需求方或用戶提出需求，產品經理整理需求，最後才反饋給設計師開始設計。這看似司空見慣，可是卻會形成一些問題：

1，信息滯後：大部分需求設計師都是最後一個知道的，也許在知道以前，產品經理和領導就已經討論完了，甚至有了基本的設計解決方案。設計在最後才介入，只能作一些執行的工做。

2，目標不清：由於設計師沒法瞭解原始的場景，當時用戶的問題和需求點都沒有本身感覺到，只是別人傳達的。那麼可能會被傳達少一些，或者加入不少主觀的想法歪曲了一些，這樣設計師所瞭解到的設計目標可能根本就不是一開始想要的。

3，進度失控：大部分狀況下項目週期可能都是領導和產品經理訂好了，何時立項、何時測試何時上線。等到某一天忽然找設計師要圖的時候，天啊~徹底沒有準備好！

尤爲是像咱們獵豹移動是一家產品經理爲主導的公司，產品經理有很大的影響力和信息的壟斷性，表現到煩惱上就是 – 你們以爲產品經理太強勢了！可是後來我仔細想一想其實這也不算什麼問題，百度也是工程師文化，阿里也是運營文化，估計除了蘋果之外設計師在哪裏都得面對這樣 的現實。

如何解決這些煩惱？

在聊如何解決的時候，我想說一下假如這些煩惱都已經解決了，假若有一種符合設計師的理想模式，那會是怎樣的？

1，設計師由接任務變爲推進設計：傳統的狀況我認爲設計師都在接任務，接受別人的任務而且完成，這樣不斷的反覆。可是在理想模式下設計師能夠推進本身認爲美好和正確地事情去變爲現實；

2，設計師本身掌控本身的時間：尤爲是設計師能夠爲本身留出認真思考和創新的時間，而不是始終疲於奔命；

3，方案的經過率高：指的是咱們只須要出那麼一兩稿，就能夠基本肯定大方向，不用一直繞圈子；

而在這種模式下，我以爲設計師已經再也不是流程的下游了，而是某些意義上來講，設計師在領導整個團隊推動產品設計的提高，這就是設計師掌握了主動權。

你們可能會以爲這種求之不得狀態實在太理想了，也可能會問到底應該怎麼作才能掌控主動權呢？其實我也沒有徹底作到這種狀態，可是咱們團隊始終在以這個目標不斷的嘗試和改進本身的工做方法，在不少狀況下都已經產生了不錯的效果，因此想分享一下咱們的經驗：

1，設計師要作到知己知彼，掌握全面的信息

我曾經作過瀏覽器的交互設計，我常常接到的需求通常會相似於 「作一個加載網頁的進度條」，要是日常可能你們就這麼去認真的研究這個進度條了。可是咱們會首先放在整個產品架構上去看這個需求，進度條是屬於網頁速度體 驗的一個環境，那麼和安全、瀏覽器性能上有什麼關聯呢？又或者在表現形式上，加載的進度條和下載的進度條有什麼區別呢？

因此咱們的設計師會維護一個產品的用戶體驗架構，看問題並非只看一個點，而是看一個面，而且看到他們之間的聯繫。這樣能夠提高咱們的反應能力和設計的精準性，而要作到它就必須創建在有很是充分信息的基礎上。

1.1 我認爲設計師要掌握的信息有三類，第一個是要了解產品的戰略方向。

具體表現就是產品的商業目標：爲何要作這個產品？；以及產品的策略：經過什麼方式來實現這個目標？

剛加入金山調入瀏覽器部門的時候，上班第一天我就問領導一個問題 「爲何要作獵豹瀏覽器」，當時領導一副詫異的表情相似 「你一個美工幹嗎要問這個？」。後來通過長聊以後咱們才溝通清楚，做爲設計師，以後的每一項方案、每個研究和思考的方向、每一次設計決策，都是爲了幫助 實現你的產品目標。因此若是能溝通清楚讓你們都清晰纔可以更好的協做和執行，甚至讓設計師發揮本身的主動性來達成目標。

給你們舉個例子，一年以後咱們進入海外市場，當時海外的瀏覽器市場尚未飽和，移動瀏覽器的技術瓶頸也尚未到。因此咱們決定作一款「最快的手機瀏覽器」，依靠簡單極致的速度去贏得用戶的口碑。

可是可能不少人就問，「快」不是性能和開發的問題嗎？和設計有什麼關係？其實快不只是性能，視覺上的簡潔輕巧，交互上的化繁爲簡，都是用戶能真切感覺到的「快」。

因此當時咱們作的第一件事情就是把主題改爲白色了。獵豹的品牌色一直是黑色和橙色，很是重的質感，老闆很喜歡。因此咱們這個改動不是通常的難，一來它觸犯了品牌一致性的大忌，二來很是難說服老闆上個年代的審美觀。可是由於強烈的目標感，你們最終仍是推動下來了這件事情。

 

而後設計師由於對目標的瞭解也發揮了很大的主動創新能力，好比在簡單App啓動過程當中，咱們爲了讓App的啓動感受更快，作了不少細節上的修改。

傳統上的App啓動分爲上圖這幾個步驟，程序啓動是必定要等幾秒的，通常產品會選擇作一個品牌宣傳的頁面，好比UC這樣。可是咱們當時選擇一張圖片，讓模擬加載出通常的「框架效果」，這樣用戶就會覺得咱們是一個逐漸加載的過程。

固然這也不是咱們原創，只是咱們爲了快的目標，而最終選擇了這個方向。

另一個步驟就是首頁的內容展示也會有一個加載，雖然很短可是若是不做處理的話就會顯示一個loading也不是很好。因而咱們又用了一張圖片，是用戶上次退出的時候主屏的截圖來替代loading的小菊花，這樣過渡效果就柔和不少。

另外還有一個小細節，一樣的截圖，咱們顏色確是不同的（下圖文本框），這樣一深一淺是模擬加載的時候內容漸隱展示出來的感受。

因此就是這樣幾張簡單的圖，咱們在感官上給了用戶順暢和快速啓動感覺。

因此其實在實際工做中，產品的方向深入的影響了設計師的每個判斷和思考，一樣也影響了設計師的效率和成敗。有的時候咱們只以爲管好眼前的事情或者份內的事情，卻不知反而會帶來更多的迷茫、爭執和不理解。

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%，而浪費在爭吵、等待、理解錯誤和反覆修改的時間上確是大部分。因此與其浪費時間作錯誤的事情，還不如多多思考該怎樣改進本身的工做方法，怎樣養成一些好的習慣。