當產品進入碎片迭代，設計師可以做些什麼？

 　　鴻影：我在之前的用戶體驗設計實踐經歷中，所做的項目絕大部分都屬於『從0到1』，以被動地接收分析產品經理提出的需求、然後不斷設計全新的產品或功能為主，一個項目完成後就基本不再管，後續的運營數據也不關心，而是立馬投入下一個新的項目中去。這種四處忙碌的感覺看起來很充實，但實際上卻有些浮躁，作為設計師沒有完整地參與進產品設計閉環，少了數據驗證、迭代改進的步驟(這正是當初Mentor不建議我畢業後去設計咨詢公司的核心理由，但IT互聯網公司不停地出新APP，出完後就不再更新的案例也不少，不點名黑了)，對產品也難有產品經理那種Owner的感覺，缺失主動推進產品不斷優化改進的意識，發揮出的價值和贏得的話語權與信任感因此受限。

　　但是當長期跟著一個項目時，在完成了『從0到1』的階段後，就進入了『尴尬期』：整塊的設計需求變得很少，更多是功能體驗上的修修補補，工作成就感降低;有了一些用戶反饋，但缺少系統地整理、甄別，而是盲目地依據反饋修改設計;項目組永遠有他們認為更重要的事情(比如修BUG)需要先做，而設計師看起來有些『無所事事』……這種不充實的狀況一度令我感到煩躁不安，於是尋求或等待新的項目/功能需求/改版的到來以期結束這一局面，但其實這便回到了本文第一段所說的狀況。

　　於是我開始思考：在看起來好像『沒什麼事情做』，有也是各種瑣碎修補的產品上線迭代期，我還應該一直被動地『等需求』做設計嗎?我是否應該更主動一點去做些什麼?用戶都有了些什麼反饋，這些反饋是普遍還是個別問題?我去實際驗證了用戶在真實使用場景下的感受了嗎?現在體驗不好造成流失的點我都知道嗎?……然後發現大部分問題自己都回答不上來，『尴尬期』可以做的事情其實有很多，根本不該是『無所事事』的狀態。

　　整合碎片需求，整體改進優化

　　迭代期的需求相對會很零碎，PD也不太會像之前一樣對每個細碎的需求都寫一個完整的Prd，作為設計師如果仍然只是被動地接收需求、一個一個修修補補過來，久而久之會缺少成就感與動力，變得有些偷懶：不再認認真真地把每個需求的場景目標都溝通梳理清楚，而是純粹『畫圖的』，被各種界面細節上的糾結困住，磨滅了主動跳出來、從全局角度解決問題的意識。

　　意識到這點後，我開始嘗試去尋找一些碎片需求的內在規律與彼此間的聯系，發現一些需求其實可以納入同一個場景/流程體系下，於是利用體驗地圖一類的工具和PD討論、梳理清楚關鍵行為節點上所有的碎片需求/待優化點，再統一出新的優化方案，這樣設計的時候可以考慮得更加全面、整體。而如果是來一個小需求就改一次方案，就可能因為之前對擴展性的考慮不夠而造成需要大幅改造或全盤推翻舊方案，或者將界面邏輯弄得越來越復雜化。

　　沉浸真實場景，觀察發現機會

　　在產品『從0到1』的過程中，更關注先搭建起核心的功能、框架，而和實際目標用戶的接觸、觀察、訪談的機會是比較少的，沒有已經上線的成品，最多做幾個Demo找旁邊同事測試一下，離真實的用戶使用場景還原仍有一定距離。

　　但是產品上線後就不一樣了，組裡有的設計師會選擇坐到真實目標用戶旁邊，觀察記錄其實際操作行為，再考慮如何進一步優化設計方案，這一點對於設計師本人非目標用戶的ToB產品還是很有效的，也是我目前做得不好的地方，還是有些拍腦袋做設計，離真實用戶太遠了。所以接下來的工作計劃中，會考慮和PD一起去邀約產品的目標用戶進行場景模擬，觀察他們使用產品的真實情境，發現潛在的優化機會。

　　關注反饋數據，思考產品改進

　　在以前實習做移動端ToC產品的時候，我有沒事就去各大應用市場評論區、社交網站上搜索浏覽用戶反饋的習慣，現在做ToB產品後雖然反饋來源減少，但有渠道也會保持關注，偶爾能從中得到一些產品設計優化的靈感。對不願意只是被動聽命PD的設計師來說，關注反饋可以幫他們更好地了解用戶、主動去思考如何改進，驅動產品完成創新。

　　至於數據，我還停留在師姐教過的一點理論層面，實際使用得不多，在有真實成功應用案例之前就不多談了。簡單來說，設計師對數據的關注不應該只是一個最終的結果，比如單純看一個整體的流失率之類意義並不大，而應該結合設計過程中的目標來拆解分析，比如關注每一個具體操作流程節點中的流失率，再結合一些相關的用戶訪談結果等，分析思考具體的流失原因，是正常流失?功能內容缺陷?還是交互體驗上不夠好?進而發現需要在產品設計上進行優化的地方，再改進之。