這個問題在很多的小公司都不存在。小公司養著、催著設計師，設計師不用去考慮能不能拿到結果，因為你不干，大家都等著你，因為身後自然有一群人在push：老板，工程師，同事。這個結果是大家一起push的結果。
但是在很多大的公司，存在很多很多的項目，孩子多了，爹媽都顧不上。項目多了，老板也顧不上。他們只看最終的結果：
為什麼有的設計師一年做了那麼多項目？那麼多收益很好的項目？
為什麼有的設計師卻一年產出寥寥無幾？做的項目多半半途夭折，或者直接胎死腹中？
若以產品經理為主導，那也還好。產品經理背負著更加沉重的考核壓力，他們會以push出結果為主要的方向，在他們的push下，設計師妥協妥協，折中折中，產品經理負責打點打點各種資源（工程師、測試等），結果也就出來了。
但是，關鍵是，作為用戶體驗設計師，總不能一直被動著響應pd們的需求——他們要做什麼就做什麼，100%的精力都放到他們的“商業目標”驅動的項目上。作為用戶體驗設計師，應該有獨立的一部分精力抽取出來，去主動發起一些項目，改進一些項目，以使網站變得更加親切易用。
關鍵就出在這裡。設計師有時也很不喜歡老是被動響應PD的需求，也想主導一些項目，但是，往往以設計師為發起人或主導的項目，很難拿到結果，現狀可能有：
工期拖得很長（優先級排得很低，幾乎可以忽略）；
沒有資源配合——畢竟項目是需要團隊的，需要工程師，需要前端開發，需要測試，不可能單打獨斗；
長時間得不到確認，不知道什麼時候開工去做；
即使是產品經理們發起的項目，在產品會議上說了能夠帶來多少的收益，老板們都點頭了，尚且需要排定優先級，等候設計資源、工程師資源。更不要提單單是某個設計師說：“這個體驗不好，我想要改成這樣……”的需求了。
為什麼拿不到結果？
“我做了一個系統性的改進方案，我覺得肯定比現有的要好很多。已經找了周圍的同事進行了測試，大家都說不錯，都盼著趕快上線呢。但是去找需求分析人員評估了一下，發現需要30多個人日開發量。而且從優先級上去排，說不定要排到年底去了。根本就沒有資源去做……”
“我覺得某某頁面有很大的問題，於是做了一個分析和改進，結果發現那個頁面上的區域被劃分為不同的產品線，分屬不同的產品經理負責。為了推動我的設計，天呢，我需要找好幾方進行溝通，他們給我的意見非常多，甚至完全相反。我根本無法估計這樣改動會造成什麼樣的後果，後來就不了了之了……”
“你覺得那個東西很難用？那就對了。我們不是不想改啊？方案都出了好幾版了，同樣有上面的問題，一沒資源，二，牽涉的利益方太多了，改動束手束腳，後來就一直保持現狀了。”
拿不到結果的借口和原因當然有很多很多，作為設計師，這些都感同身受甚至自己也遇到過。
分析下來，所有的原因都可以歸結為：“方案與資源、溝通”問題。
設計方案本身存在問題——有潛在的風險，投入大產出小，本身就不合理等；
設計方案沒有問題，但是資源緊張，無法投入，自然沒有產出；
設計方案沒有問題，但是多方溝通不能順暢推動，擱置。
這個時候，出現了一個矛盾，既然我們提供了好的設計方案，為什麼卻得不到資源的響應，按理說，如果足夠好，優先級也應該高，各方也應該支持的啊。如果是好的設計，為什麼在溝通上會如此艱難？這個時候我們是抱著好的設計等待呢，還是有別的辦法？
當我們認為我們的設計是很好的時，我們很難去妥協讓步，
但是——
上一頁
12 3 4 5 下一頁 閱讀全文