初入行（算上實習）時的我，在接到一個來自產品經理的口頭需求後，經常犯、現在也會偶爾復發的一個錯誤就是粗略瞭解思索一下，就立刻開啟軟體投入到對解決方案的探索中去；在需求比較小/專案時間緊急的時候，這樣做的概率會變得更高。初衷是希望能節省時間、加快交付速度，但實際卻會出現一開始就跑偏了方向，解決方案需要完全推倒重來的情況，結果反而耗費了比預期更多的時間來完成專案。在學校接受設計教育時，我們都知道，在開啟軟體進行正式的設計工作之前，需要花上很多時間來進行前期調研、分析、頭腦風暴、草圖等；而在實際工作中前期準備也非常重要，現在我正在培養一種意識，在開啟軟體前先告誡自己一句：「該做的事都做好了嗎？」
溝通了解專案背景
其實這點在之前的文章裡已經提到過很多次了，當產品經理本身足夠靠譜的時候，這部分並不太需要設計師花很多時間去主動溝通了解，他們會通過文件或口述的方式把設計師應該關注的專案背景資訊都說明得一清二楚。但畢竟你也不能指望一直遇到足夠靠譜的產品經理，如果他只是簡單粗暴地說一句「XX你做一下這個功能/圖示的設計」，就需要設計師自己有意識地主動去詢問、確認清楚相關資訊了。
在做新的產品設計之前，需要了解清楚產品的目標使用者定位與具體的使用者畫像描述，本次設計的頁面/功能/圖示具體是為了解決什麼問題，要改變怎樣的業務現狀，改進怎樣的體驗痛點，判斷這個需求是否真的能解決業務與使用者的問題，還是隻是隔靴搔癢（當然，對設計新人來說這點可能比較難，有時明明直覺不靠譜卻又難以說服產品經理，這時請教/求助組裡資深的設計前輩會比較有用）。否則的話，如果遇到的是靠譜的產品經理（嗯我現在遇到的都很不錯）還能濛濛過去，遇到拍腦袋提需求的就有方向南轅北轍、需求中途被砍、辛苦設計出來的方案最後完全用不上的風險了。
明確資料和相關衡量指標
一個設計方案是否取得了預期效果，上線後的資料會是一個非常有力的評判工具；而後續的迭代優化，也往往需要圍繞某一資料指標的提升展開。過去我對產品的資料這塊漠不關心，設計之前完全不清楚產品的各種資料指標現狀，只知道要提升一個整體的XX率；設計做完了上線了就和沒事一樣，並不關注設計方案的實際市場反饋如何，知道那個整體的XX率提升了就滿足了，而不關注是否真的是設計的貢獻，是否具體在互動流程某一個或幾個環節還存在問題。
現在剛剛開始嘗試在一次產品設計改版中做出一點改變，在設計之前，先和產品經理了解清楚本次設計需要達到的目標是什麼，這個目標是通過什麼資料指標（UV？PV？流失率？轉化率？滿意度？）的提升來衡量，迭代前的產品資料如何，在互動流程各步驟的分佈情況如何，有哪些是可以通過設計上的改進來達成的，等……將其作為設計過程中的思考方向引導和設計上線後的跟蹤驗證標準之一。
競品資料蒐集分析
競品分析環節並不是說要像做專業、規範的競品分析報告那樣，實際上緊張的專案排期也往往容不得我們花大量的時間精力在這一環節。但平時可以有意識地多玩多蒐集應用網站（我算萬年iOS+Android雙機折騰黨，雖然現在做移動端的機會不多應用玩得也少了些，但習慣仍然保留），在腦中構建起一個知識索引庫，真開始設計的時候能迅速舉一反三出多個案例，而不是茫然地想：「看上去好像沒有什麼競品可以參考啊？」
對於在BAT等大公司實習工作的同學，公司內網各業務線各部門UED的資料也是一個不小的寶庫，只要善於主動去發現與挖掘，我就會去找一些公司裡相似產品業務的設計文件來看，看看工作經驗多很多年的前輩們是怎麼考慮問題、找到解決方案的。
當然這一環節有一點是一定要注意的，要知道競品本身存在產品定位、目標使用者、使用場景上的差異，不能被表象迷惑無腦抄襲，做出完全不適用於當前產品的設計方案。
善用紙筆來思考、表達與溝通
使用軟體做前期的設計草案探索有一個壞處，就是有時會不自覺地陷入到對一些當前無關緊要的細節的追求中去，如果有過視覺設計背景的話這種情況可能更多。我自己有時就會在整體佈局方案都還沒確定的時候先去糾結對齊、字號、多狀態處理、特殊場景一類的問題，結果後來整個方案被推翻，這些細節也就失去了價值。
最近在做草案階段的時候，我開始嘗試迴歸用紙筆思考表達，讓自己的注意力保持在全域性框架上，避免中途被某個細節勾走分心，紙筆想得差不多了再開啟軟體勾勒線框圖。同時紙筆也是一個很快捷方便的前期溝通工具，有時精心畫出一個線框圖/視覺稿給需求方看，結果被說完全不是他想要的，造成較大的返工成本；如果前期就能通過便籤、草圖一類方式和需求方溝通甚至協同創作，看上去時間增多了，但長遠看來卻能減少更大的無意義返工成本。