Facebook加入
LINE加入
2021/12/25
設計師如何更有效拿到結果?
這一次的教學是屬於設計理論領域中的設計理論的相關教學。
文章出處是來自Tencent CDC Blog的設計理論類文章，寫教學的作者是heidixie，感謝heidixie提供設計理論的實作教學。
教學大綱:
這個問題在很多的小公司都不存在。小公司養着、催着設計師，設計師不用去考慮能不能拿到結果，因為你不幹，大家都等着你，因為身後自然有一群人在push：老闆，工程師，同事。這個結果是大家一起push的結果。
設計理論教學開始
這個問題在很多的小公司都不存在。小公司養着、催着設計師，設計師不用去考慮能不能拿到結果，因為你不幹，大家都等着你，因為身後自然有一群人在push：老闆，工程師，同事。這個結果是大家一起push的結果。
但是在很多大的公司，存在很多很多的項目，孩子多了，爹媽都顧不上。項目多了，老闆也顧不上。他們只看最終的結果：
為什麼有的設計師一年做了那麼多項目?那麼多收益很好的項目?
為什麼有的設計師卻一年產出寥寥無幾?做的項目多半半途夭折，或者直接胎死腹中?
若以產品經理為主導，那也還好。產品經理背負着更加沉重的考核壓力，他們會以push出結果為主要的方向，在他們的push下，設計師妥協妥協，折中折中，產品經理負責打點打點各種資源(工程師、測試等)，結果也就出來了。
但是，關鍵是，作為用戶體驗設計師，總不能一直被動着響應pd們的需求——他們要做什麼就做什麼，100%的精力都放到他們的“商業目標”驅動的項目上。作為用戶體驗設計師，應該有獨立的一部分精力抽取出來，去主動發起一些項目，改進一些項目，以使網站變得更加親切易用。
關鍵就出在這裡。設計師有時也很不喜歡老是被動響應PD的需求，也想主導一些項目，但是，往往以設計師為發起人或主導的項目，很難拿到結果，現狀可能有：
工期拖得很長(優先級排得很低，幾乎可以忽略);
沒有資源配合——畢竟項目是需要團隊的，需要工程師，需要前端開發，需要測試，不可能單打獨鬥;
長時間得不到確認，不知道什麼時候開工去做;
即使是產品經理們發起的項目，在產品會議上說了能夠帶來多少的收益，老闆們都點頭了，尚且需要排定優先級，等候設計資源、工程師資源。更不要提單單是某個設計師說：“這個體驗不好，我想要改成這樣……”的需求了。
為什麼拿不到結果？
“我做了一個系統性的改進方案，我覺得肯定比現有的要好很多。已經找了周圍的同事進行了測試，大家都說不錯，都盼着趕快上線呢。但是去找需求分析人員評估了一下，發現需要30多個人日開發量。而且從優先級上去排，說不定要排到年底去了。根本就沒有資源去做……”
“我覺得某某頁面有很大的問題，於是做了一個分析和改進，結果發現那個頁面上的區域被劃分為不同的產品線，分屬不同的產品經理負責。為了推動我的設計，天呢，我需要找好幾方進行溝通，他們給我的意見非常多，甚至完全相反。我根本無法估計這樣改動會造成什麼樣的後果，後來就不了了之了……”
“你覺得那個東西很難用?那就對了。我們不是不想改啊?方案都出了好幾版了，同樣有上面的問題，一沒資源，二，牽涉的利益方太多了，改動束手束腳，後來就一直保持現狀了。”
拿不到結果的借口和原因當然有很多很多，作為設計師，這些都感同身受甚至自己也遇到過。
分析下來，所有的原因都可以歸結為：“方案與資源、溝通”問題。
設計方案本身存在問題——有潛在的風險，投入大產出小，本身就不合理等;
設計方案沒有問題，但是資源緊張，無法投入，自然沒有產出;
設計方案沒有問題，但是多方溝通不能順暢推動，擱置。
這個時候，出現了一個矛盾，既然我們提供了好的設計方案，為什麼卻得不到資源的響應，按理說，如果足夠好，優先級也應該高，各方也應該支持的啊。如果是好的設計，為什麼在溝通上會如此艱難?這個時候我們是抱着好的設計等待呢，還是有別的辦法?
當我們認為我們的設計是很好的時，我們很難去妥協讓步，但是——
什麼是好的設計？
在之前，我胡言亂語寫過一篇文章，定義的好的設計是：最少的成本達到設計目的，設計目的是什麼呢?一，最有效傳達信息;二，使產品好用易用;三，使用戶在使用過程中感到愉悅。好的設計必須要達到這三條。
可是現在，我卻發現這些都還只是好的設計的必要條件，而不是充分條件。
因為在更加複雜，更加商業導向的環境中，好的設計在“以用戶為中心”的導向上，又增加了很多條件：
一. 價值大;
在項目pk中，當然是價值大項目首先脫穎而出。這個價值，雖然主要是商業價值，但是也涵蓋了用戶體驗改進帶來的價值。
二. 技術可行，可實施；
除非不得已，沒有人喜歡水中望月，畫餅充饑。一個完美但是得不到實施的藍圖，除了獲得稀稀拉拉的掌聲外，什麼得不到。你需要團隊幫你實現設計，那麼你的設計必須是他們能夠complete的。
三. 投入產出比高；
在項目pk中，當然是投入小，產出大的項目脫穎而出。當和價值大但是投入也大的項目相比，則更勝一籌。老闆們都比較會算賬，你需要他們點頭同意。
所以，看看我們手中擱置的設計，是不是在現實環境中“好的設計”?
如果不是，那麼就去調整一下。
如果確實是，還是沒有辦法拿到結果，那麼就硬着頭皮去推動，去溝通。一個同事說了一讓我很感嘆的話：態度和意願問題，看你是不是真的很想要拿到結果。有些設計師做了設計就單純在等，有些設計師就不斷溝通和推動，結果當然不一樣。
羅嗦了很多，總結一下吧：
作為用戶體驗設計師，如何拿到結果？
用戶體驗設計師，有交互設計的能力需求，有視覺表現的能力需求，比如，圖形化能力，能夠在開發前就憑想象呈現出很多複雜的交互狀態，溝通與講解能力等等。
若要做能夠拿到結果的設計師，就應該在整個項目流程中，像產品經理一樣，擔負起來項目協調人或項目經理的角色。把整個項目的生命周期若按以下流程劃分的話：
很多設計師認為拿不到結果的問題出在“方案評估與確認”環節上。其實不然，任何一個環節處理不好，都會拿不到結果，或者拿不到想要的結果。
01.發現問題階段——找准問題：
能力要求：
對特定用戶群特點和需求的了解。電子商務的用戶與遊戲網站的用戶心理、生理特點是不一樣的。若站在自己的角度而不是用戶的角度去使用網站，發現問題，往往會有偏差。自己覺得好用的，用戶真的會感覺非常無辜地不會用。同時，要細心，體貼入微，有時，解決問題的可能不需要大量的設計和開發，也許僅僅改一句文案就可以了。
對優先級排序的敏感性。有的時候，發現問題太容易了。沒有完美的無懈可擊的網站，沒有完美的用戶體驗。真的存心找碴的話，放眼望去，網站都是問題。選擇哪個問題首先出擊?那些問題稍稍放后?那些問題暫不考慮?設計師心裡要有個數，在資源有限的情況下，挑選最亟待解決，解決后最有價值的問題，提供優化方案。
挑選維度，可以有解決難度係數，解決后帶來的價值，不解決的風險,損失等。
02. 提供方案階段——提供“好的設計”：
能力要求：
商業意識的敏感性，知道每次的改進不僅僅是感性的“更加好用”，“用戶更加喜歡”，而是能夠預知因此能夠帶來一些可量化的變化。即使是拍腦袋，也盡量訓練自己慢慢拍得更加準確。
另外，對於好的設計的理解，更加透徹。
在提供方案前，除了要了解這個項目的需求(自己提出的，別人回饋的等)，若是改進型的項目，更需要明了現有方案的問題，好對症下藥。通過溝通和探求，要知曉其他人，尤其是重要人士對這個項目的期望。當然，在資源比較緊張的情況下，一定要事先了解“限制”。哪些功能雖然好，但是確實是做不了或者需要花很大成本才能夠做的。否則提出一個自己認為很perfect但是在現有的架構和技術能力限制下，等同於空中樓閣的方案，是不可能拿到結果的。
盜用一張 design thinking 上的圖片：
說的大概是同一意思。
但是，作為設計師，提出一個雖然很容易實現但是看起來有點沒有水準的設計，也是丟face的。會不會被很多人挑戰設計能力?
解決方法：同時提供兩種方案，即，心目中理想的方案是什麼樣子，我們稱之為“藍圖”，提供未來可能性的美好框架，給人們暢想的快感和希望。但是一定要同時提供這個藍圖的精簡版——可實施的方案。筆鋒一轉，由於目前受到什麼什麼的限制，我們無法做到什麼什麼，保留了什麼什麼功能，去掉了什麼什麼功能。所以提供一個可實施的方案如下，已經得到了評估，需要多少個人日開發量等等。
這樣，既有設計師的面子，又有希望拿到結果了。
03.提案確認、評估階段——意願驅動，結果導向
好，現在我們手中有了一個上述的“好的設計”方案了。接下來的主要任務就是讓這個方案得到相關人士的認可，這些人包括：
老闆，他有生殺予奪的大權，他說好，可以做，那麼這個項目的阻力就小很多。
同部門同事，他們會從專業水平來對這個設計進行評審，到底好用不好用，有沒有更好的辦法——這個時候可能會被信息轟炸掉，要注意鑒別，並非所有的意見都要參考的，畢竟每個人的立場不同，思考問題的角度和深入程度不同。。
需求分析(RA),前端人員和工程師：他們是要負責實現的，雖然在出最終的方案前已經讓需求人員介入進行可行性分析，但是最終方案出了以後，一樣要再次進行評估，此時不僅僅是可行性，也要評估具體的工作量，要實現這些設計功能和效果，前端需要多少人日，工程師需要多少人日等。
相關部門同事，如這條產品線的產品經理，畢竟是動了人家的土，也許某種情況下涉及到的產品線不止一方，可能同時需要和幾個產品經理進行溝通協調，還有客服部同事，網站一經改動，他們就必須要通知到，不然怎麼教客戶用啊。所以，在沒有正式上線前就應該讓他們知道，另外作為一個與客戶親密接觸的部門，他們也能夠提供一些有用的信息，幫助我們進行改進。
記得王石在武大的一場講座上回答“登雪山難還是管理企業難還是做慈善事業難”的問題時，他的答案是：登雪山最容易，因為只是在和自己與雪山打交道。管理企業次之，涉及到的人很多，做慈善最難，涉及到的人更多。
所以，與人打交道和協調本身就是不容易的事情。很多時候，用心力交瘁，勞而無功來形容一點都不為過。但是(對不起，又一個但是)，不這麼做，又怎麼能夠拿到結果呢?自己發起和主導的項目，是不能依賴產品經理的，要自己主動出擊。
纏，磨，黏，死纏爛打——種種招數，會哭的孩子有奶喝，這是老話。
出了意願驅使去爭取資源和認可外，當然也要對好的建議進行採納吸收，踏踏實實進行方案的“妥協”和“調整”。
反正最終目的仍是得到認可，多方認可，直到把這個項目排在日程表上。
當然，我們還要求設計師是有大局觀的，根據自己項目和別的項目對比得出的優先級排日程和資源就好了，不要太過了。。
能力要求：
多方溝通與協調能力——還要求“多語言能力”，怎麼說呢：
與工程師要用工程師的話語溝通，與數據分析人員要用數據平台的語言溝通，與設計同仁們則用設計的語言溝通，與老闆們要以產品經理的語言溝通。與copy writer則要用英文溝通，設計師，尤其是新人，要主動地多和同事、別的部門的同學溝通，以掌握其語言特點。
承受挫折，捲土重來的心理素質
不可避免會碰很多釘子，可能你的改進雖然整體效果不錯，但是可能會觸及到某個產品經理的利益，可能影響到他的考核(比如流量的下降)。要說服他講究大局觀而放棄掉這些流量損失，是看似“不可能的任務”。所以在挫折下屢敗屢戰，絕對是心理素質，當然，也可以曲線救國，爭取重要人士的支持。
理性預估項目風險與價值
設計師當然是感性的。但是現實是，你縱使拍疼了大腿給你的老闆說：這個設計真的很好很好啊，用戶一定會多麼多麼喜歡用的啊……沒用的。老闆和別的貢獻資源的同事們都眼巴巴問你要“證據”，你能拍着胸口承諾說：“我保證用戶一定會更喜歡用”。那麼，怎麼保證?所以感性的設計師也要有預估項目收益的能力，當然，是量化的。比如，數據。改進前後流量的前後對比等。對着空氣去預計當然有很大的風險，不過既然不做不行，就逐漸鍛煉自己拍腦袋也越拍越準確。剛開始當然從最底線開始預估，最低達到多少，希望的結果是達到多少。不要過於保守——不然大家沒興趣，不要過於冒進——不然自己壓力大。如何剛剛撓到癢處，着實還需要考慮考慮學習學習。
04.項目推進階段——團隊協調與時間管理
我很崇拜古代的大將軍。我為數不多的偶像級的人物裡面有幾位大將軍，比如衛青，比如趙雲，比如霍去病等。為什麼呢，《明朝那些事兒》的作者講得通俗易懂，打仗不是鬥毆，是有很多技術含量的。比如，給我們10萬人，讓我們帶着去西湖溜達一圈，能保證一個不少帶回來就了不起了。更何況要完成一些非正常環境下的衝鋒殺人的任務。所以，多方溝通很重要，帶領團隊更加重要。
作為發起人的用戶體驗設計師，有時為了拿到結果，不得已就要充當這樣一個團隊帶領者的角色。管理的四大職能看起來是書本上的理論，但是若在實際情況下一一去對照，發現說得都是經典：
計劃——我們是planner，需要確定非常smart的項目目標，以及為了達到這個目標我們需要採取的行動(作業計劃)，還應該讓每個人都清晰了解自己的角色和職責，最後讓他們知道應該在什麼時間完成這些工作。關鍵詞：項目定義、目標、角色及職責、時間點。
組織——我一直覺得自己組織能力欠缺。有些人從小就喜歡參加組織性的工作，比如文體委員，班長等，連居委會大媽都不是輕鬆的活，不是誰都幹得來的。想想，要把性格各異，語言不同，思維方式和思考側重點都不一樣的人組織在一起完成共同的目標?天呢，對於很多設計師來將，真是恨不得自己擼了袖子單幹!可是，逃避不是解決問題的辦法。所以，對於像我一樣本身有點內秀的設計師來講，不妨開始硬着頭皮嘗試一下，從主動承擔一些小的組織項目開始。
領導——領導在這裡我理解為主要是以身作則，以自己的形象、專業性去影響別人，讓團隊信服而不是去說服。同時，要有激勵團隊、鼓舞士氣的能力，很多項目不可能順風順水，中途或許會遇到很多挫折，若遇到一點小意外，自己都亂了陣腳：發牢騷，“煩死了”“這可怎麼辦”，若想要拿到結果，這些字眼最好不要提。而且，要以更加積極的心態去應對，去鼓舞大家繼續努力，寧可一條道走到黑……
控制——我以前經常抱怨我的老闆控制欲很強，他恨不得我上班的8個小時完全是屬於他的，他想知道我的項目進展，想知道任何細微的變化，直到有一天他對我更加信任了。有效的控制是促使團隊更加有效達到目標的手段，而且能夠控制在基本正確的道路和方向上。
關於這個階段的管理能力(主要是團隊管理和時間管理)，偶也不是很擅長，也正在學習中，這裡就不展開說了，免得貽笑大方。歡迎有興趣的諸位多多探討。《卓有成效的管理者》這本書，可以讀讀。
05.項目跟蹤與總結階段——理性，數據分析
設計師已經拿到結果了，可以長吁一口氣了，但是別忘了最後一個階段，項目到底好還是不好，有沒有達到事先設定的目標?畢竟我們的目標是拿到好的結果。這也關係到你的下一個項目能不能繼續順利立項和推進的重要因素。
要進行數據的跟蹤，要具備數據分析能力。設計師在設計初期定了設計目標時，就應該有意識去考慮將來用什麼樣的方式驗證設計的成敗，是流量的增長還是黏度的增高?或者是其他?
也應該提前與數據分析人員溝通以確定你要的數據能不能取到，若不能，還要在開發過程中考慮如何布點以方便數據提取。
最後，來一份比較漂亮的總結報告，總結項目的得與失，總結下一步的改進建議。
這才是真正的完整的項目結果。——恭喜你終於拿到了！
最後一句話：萬事都是說著容易做着難。以上文章觀點並非原創，而是來自國際站UED會議精華總結。
所以，看似簡單的道理，人人都懂，看似簡單的邏輯，實際上在實行中總是會有不可預見的障礙與困難。別看我寫了這麼多，現實情況中卻做得“提高的空間非常之大”，無論是時間管理或者是主動溝通…… 以此文，希望與各位設計師共勉，一起進步。
討論: http://www.missyuan.com/viewthread.php?tid=424243
–本文轉載自 http://www.missyuan.net 教學網 —
熱門推薦
留言回覆
