最近正在做新產(chǎn)品設(shè)計，心血來潮，總結(jié)一下我慣用的流程套路。
☆前期調(diào)研
首先，我得有一個方向，這款產(chǎn)品最重要的場景是什么，面向哪些受眾，解決什么問題，解決思路又是什么。然后才會知道，產(chǎn)品是否有趣到挑起我的熱情，以及我的基因是否有信心把它接下來。
接下來調(diào)研競品，在Appstore上搜產(chǎn)品類型的關(guān)鍵字，每個關(guān)鍵字看30-50個App，感興趣就下載下來。同類型的做得不錯的產(chǎn)品，在搜索列表頁多半能進TOP50。
當初調(diào)研旅行大類的時候，大概下了近百款產(chǎn)品。這次少一點，20款左右，快速捋一遍，一個個評測并且念念有詞。如果競品很強，還需要手工統(tǒng)計內(nèi)容更新量與互動數(shù)，也看Appstore的排名曲線變化。
產(chǎn)品評測沒有任何模板，主要看它哪里能打動你，做得差的地方一笑而過，做得好的咂嘴咂舌，評頭論足，甚至開個excel記錄下來。評測時特別留意的是：
1、重要功能或特色功能的場景與競爭力
2、PGC和UGC(含互動部分)的質(zhì)量與風(fēng)格
新手在這里往往犯錯誤，只對比有沒有某一項功能，缺乏對實際效果的體會；只看內(nèi)容更新數(shù)量，不重視內(nèi)容瀏覽感受。那一定是買櫝還珠了。
除了看產(chǎn)品本身，對于重要的競品還得Google一下，看看團隊基因，從各種訪談報道中挖一些背景資料。因為我有社交不耐癥，從人脈圈子中八卦打探這個環(huán)節(jié)就省掉了。
這次的20款競品，從搜索到看完，也就大半天時間，都是不大復(fù)雜的輕量級產(chǎn)品?？赐暝傧霂滋欤a(chǎn)品框架和運營框架在腦袋里有了個基本的形狀。
☆開始設(shè)計
我自己的設(shè)計工具是Axure，我司產(chǎn)品小哥推薦另一款在線設(shè)計工具叫“墨刀”，也挺好，很適合原型展示(尤其在手機上展示)。
畫原型圖，我有三個習(xí)慣。
1、不做任何動效。小團隊磨合嫻熟，攤開原型，一個個頁面當面講，參與者都是專業(yè)人士，有沒有動效不影響理解。一套原型經(jīng)歷幾十遍修改，加動效太浪費時間了，盡量把需要動效的部分平鋪在Axure的一個頁面里，頁面層級關(guān)系與命名必須嚴謹清晰，產(chǎn)品文案用反復(fù)推敲的正式版，而不是隨便寫幾個字先填上以后再改，對于內(nèi)部溝通，這些比動效可重要太多了。
2、大部分的交互設(shè)計，我都得先找到一個樣本，它在某一款應(yīng)用里長什么樣子，摸起來手感如何。每次畫原型圖的時候，對每一個頁面細節(jié)，腦袋里先有一個概念，我想要怎樣的布局，怎樣的感覺，然后憑記憶去手機里(下了300款應(yīng)用)東翻西翻，找到類似的設(shè)計點。如果場景相仿，我預(yù)設(shè)的感覺與實際手感又能搭上，再想想如何移植過來。一方面取百家之長，當然你們說是抄襲我也無所謂；另一方面也是功力不夠深厚，非得在真實場景“眼見為實”才吃得準，僅僅看原型圖的話，無法腦補還原現(xiàn)場。
然而翻遍手機也找不到樣本的情況，必定也是有的。這時很痛苦，眉毛打結(jié)眼斜嘴歪，不停地自言自語說“太惡心了，太惡心了”。沒辦法，只能硬憋一套無先例的交互出來。蟬游記PC端的游記排版，移動端的游記編輯，蟬游攻略的作者平臺與攻略瀏覽，都憋得老子面色猙獰。與其說是拼交互創(chuàng)意，不如說是拼場景理解，把使用場景想得特別透徹，再按照通用的交互規(guī)范去編排頁面與功能。
3、蟬游家的產(chǎn)品框架與(內(nèi)容)運營框架都由我來搭，最大的好處是，我對內(nèi)容需求理解透徹，產(chǎn)品與運營的耦合度高，又有擴展性。我經(jīng)常在畫原型之前先去搭(內(nèi)容)運營框架，比如這次的新產(chǎn)品，掐指一算，覺得難點不在于交互，就先去整理內(nèi)容類型，一級二級三級標簽，近百個標簽挨個分析調(diào)研。斷斷續(xù)續(xù)搞了一兩周，覺得運營框架理清楚了，這才動手畫原型。如果產(chǎn)品經(jīng)理和運營經(jīng)理分離，這時會很不好辦，大多數(shù)產(chǎn)品是服務(wù)于運營的工具，運營方案先行，越細越好，產(chǎn)品設(shè)計才容易配合到位。
運營框架準備好之后，我畫原型很快，10個以內(nèi)的頁面一天畫完，復(fù)雜的大功能模塊只用半天。蟬游記App用了2天時間出第一版設(shè)計，PC端也是2天，H5版1天。所以看到大公司PM扎堆做一個項目……撓撓頭，憨厚地一笑。
☆產(chǎn)品討論與PRD?
原型畫完了，我激動得很，到處拉人給意見。當然，前提是我對蟬小隊足夠信任。一拉五六七八個人，七嘴八舌指指點點，肯定能找出來問題，然后我去改，改完了再集體討論。反復(fù)好幾次，原型算是定稿了，移交給UI設(shè)計師出圖。
因為產(chǎn)品團隊夠小(PM2/研發(fā)3/UI1)，座位又近，PRD也相當簡陋……其實是根本沒有PRD。頁面效果我跟客戶端工程師口述，簡單的算法也口述，比如頁面排序規(guī)則。如果是功能點整理，或者給后端工程師的復(fù)雜算法，就單寫一個任務(wù)放在Tower.im上。工程師根本不看原型，對著Tower任務(wù)看UI稿，搞不懂的地方吼一聲，我立刻屁顛屁顛地跑過去解釋。
所以我的PRD主要是Tower上一長排任務(wù)，按產(chǎn)品模塊進行分組。這時你多半會問，沒有PRD，產(chǎn)品測試和交接可怎么辦啊。對頭！我還有一份細到令人發(fā)指的Mindjet測試用例，上面記錄了每一個頁面，每一個功能，每一個效果的測試項。帶產(chǎn)品新人的時候，對著Mindjet文檔把細節(jié)過一遍就好了。每次發(fā)新版本，更新這份用例是件特別惡心的事情，但也得做啊，攤手。
想得起來的經(jīng)驗大致這么多，么么噠。
