背景介紹：（1）我們做的是對b端的產品，web端和app都有，整個開發流程基本一樣，只是有些功能app用原生做不需要做html頁面；（2）產品組有一個同事負責項目管理，同時也負責金融的產品；（3）我們有專門的交互設計師。

目前遇到的困擾有：（1）迭代周期長、效率低下；（2）用戶體驗差；（3）苦樂不均。這里先拋開“人”的問題，只從流程上找導致問題的原因和改進辦法。所以，先看一下我們現在的產品開發流程，見下圖（省略了一些細節和異常流程）：

（1）產品方案評審后再處理交互。之前每次產品評審的時候，開發針對原型都會提出很多交互的問題，可能是原型上沒做相關交互，也可能交互方式不合理，然后再根據提出的問題改。誰來改呢？一般來說是邏輯上沒有問題，應該是交互同學來改。但是事實上不完全是，大部分仍然是產品自己改，因為交互和產品用的原型工具不兼容！另外，交互稿出來之后一般是不再評審的，直接發給產品同學看下，沒問題就扔給視覺和研發。然后就視覺、研發、測試的同學經常就跑來問我，這塊的交互怎么處理啊？如果之前我和交互溝通過的話可以直接回答，沒有的話就要找交互補交互稿或者交互說明。這樣白白增加了溝通成本。

解決辦法：產品確定需求邏輯后，與交互同學一起做出高保真原型后再評審。一方面可以彌補交互評審的缺失；另一方面高保真原型本來就是為了便于大家理解需求和評估工作量，因為交互是不可缺失的一環。

（2）設計稿出來后不經評審。現在基本上都是設計和產品單線聯系，出完圖讓產品看看，不滿意再改（或者撕），ok了就發給前端。這樣的話就十分依賴設計師和產品的水平和責任心，結果常常是原型什么樣，設計稿就什么樣，頂多調整下細節。

解決辦法：增加設計稿評審環節。主要是給設計同學一些壓力，不會隨意對待，提高用戶體驗。

（3）立項之后產品一直在各個角色之間忙溝通，沒有足夠精力規劃后續版本。從前兩點也可以看出來，整個過程非常依賴產品，不管是溝通還是把關。雖然作為一只產品汪這些事情責無旁貸，但是這真的是為了這個項目好嗎？