很多公司的產品除了要挖掘和實現(xiàn)用戶需求 ，還需要協(xié)調團隊資源，推動項目的進展。尤其后期在跟技術的對接上，尤其需要花很多時間。

那產品設計師如何與技術協(xié)作更高效？

1、技術需要了解業(yè)務和用戶；

很多技術（或公司管理層）覺得，技術只管實現(xiàn)功能就好，不需要了解業(yè)務。尤其很多公司發(fā)展到一定階段，技術離業(yè)務越來越遠，甚至說不清楚自己公司是做什么的。

這樣導致的問題是，技術離用戶很遠，不知道產品有什么問題，需要為用戶解決什么問題，而了解這些，就知道自己在開發(fā)的產品用戶是誰，能為用戶解決什么問題，哪些問題還未解決等。同時，也能減少協(xié)作的溝通成本，產品講場景時，技術能瞬間get。

2、讓技術參與需求評審；

讓技術參與需求評審，參與討論，一方面讓技術同學腦海中有場景感，知道為什么要做這個需求，是解決誰的什么問題，而不是僅僅把一堆文檔給他們，告訴他們開干，這樣會讓技術變成純粹的執(zhí)行機器；

另外，技術能站在他們的角度提出一些思路，看需求是否可行，是否有更合理的方案。

3、給技術提供詳細的文檔

一般情況下，產品都會準備PRD文檔，也會同步給技術。但跟很多技術同學溝通過，普遍表示他們一般不會看prd文檔，內容太多，效率太低。大多數情況下，他們需要這幾個文檔：
1）原型稿（最好是高保真原型）；
如果前期的需求評審階段，技術已經對需求和場景理解的很好的話，一般提供了高保真原型，他們腦海中就知道該怎么做了，這是最好的情況；

另外，原型上的標注說明需要描述清楚，比如，對不同狀態(tài)的解釋，出現(xiàn)特殊情況（如操作出錯或斷網時）該如何提示等；

2）業(yè)務流程圖；
流程圖能清晰展現(xiàn)出場景的順序和結果，在做產品設計甚至活動流程等地方都用的十分廣泛。尤其對于任務型需求，涉及的情況分支太多，這時候，業(yè)務流程圖就非常有必要了。

大致提一下繪制流程圖幾個關鍵點：
1 參與者：這個場景中，有哪些人（角色/系統(tǒng)）參與？比如一個雜志主編需要審核一個作者的投稿，那么參與者就是主編和作者；

2 事件：這些人做了一件什么事？接著上方案例，1是作者向雜志投稿，2是主編看到這篇稿子后對其進行了處理；

3 順序：這些事情的前后順序是怎樣的？哪些任務是條件？比如，肯定是先有投稿，再有審稿；有人投稿是審稿的前置條件，如果都每日投稿，也就沒辦法審稿了；

4 輸入（上游）：這些活動開始前需要有什么數據傳達或者操作，比如主編要審稿，那作者需要投稿給他，并且最好系統(tǒng)能提醒主編去做這件事；

4 輸出（下游）：這些活動結束后，會有什么反饋傳達？比如，主編審稿之后，如何讓作者知道這件事兒？

6 標準化：每個流程有開始和結束，每個符號代表什么意義；

以上是產品設計師跟技術gg協(xié)作最基本的流程。對新人來說，經常會在某個環(huán)節(jié)出現(xiàn)一些問題，但不要著急，慢慢跟技術磨合，經歷各種互相撕逼、一個又一個項目后，就能達到比較和諧的狀態(tài)。

另外還有幾個非常值得注意的點，都是經歷汗水總結出來的經驗：

1、 盡可能考慮周到

在給技術文檔時，一定要把所有情況考慮到，不要等技術來找你。
比如：
1）每個流程是否有完整的開始、結束，是不是每個可點擊的按鈕都有交互反饋，
2）錯誤提示、網絡環(huán)境有問題時如何處理、空狀態(tài)、各類彈層是不是有考慮；
3）新老版本之間如何兼容；
4）數據埋點怎么埋，提前溝通；

2、盡可能的不要改需求

產品最常見被技術『砍死』的最大原因之一：臨時改需求。
因為產品沒考慮清楚，突然讓技術改東西，但牽一發(fā)動全身，你以為改動小，但對技術來說可能就是半天或者幾天的工作量，這種情況出現(xiàn)多了，不被噴死都是技術仁慈了。

所以事前想清楚，提交開發(fā)之后就不要輕易改需求了。

3、產品功能和邏輯比炫酷的視覺更重要

對產品新人來說，總是希望自己做出來的產品一看就很炫酷高逼格。但實際情況是，過分追求視覺上的炫酷不僅需要耗費太長時間，拖慢項目進度，而且會忽略產品本身的功能和邏輯，得不償失。

與其看上去酷，不如把功能設計的更簡單易用。

當然，每個產品新人都需要經歷各種項目、各種磨合，才能慢慢修煉的老道。每一次犯錯，都是成長。