為了節省人員更替的交接成本，通常的產品文檔會匯總成一個超大超長的文檔，但這樣會在后期嚴重增加與開發人員之后的溝通成本。對此，作者給出了解決的方法。

近段時間在和幾個小伙伴一起做創業項目。項目初版已經接近尾聲，就提前做了階段性復盤，因為是初版且還沒上線，所以業務上沒什么可討論的，我們重點分析了產品團隊內部的問題和解決方案。

復盤發現核心問題是沒技術基礎的產品同學（非技術型產品經理）在跟開發人員交互時，很容易被懟。

被懟的主要原因是他在注重業務設計的過程中，忽略了落地方案的復雜度和嚴謹性。相信這是困擾很多產品同學的一個問題。

想與開發建立良好的合作關系，產品經理們要做到讓他們開發起來有“爽”的感覺。下面我們以產品中的交互提示為例，來講述如何讓開發“爽”起來?。ā疤崾拘畔ⅰ闭f起來簡單，就偷個懶，有悟性的同學自然能舉一反三）開始走干貨～

一、提示信息產出的節點和作用

產品的設計制作過程大體分為：

• 業務流程
• 產品架構
• UI交互
• 容錯機制
• 運營支撐
• 數據收集&挖掘

“提示信息”的產品研發需求一般出現在“UI交互”和“容錯機制”階段。

主要目的一是為了讓用戶在使用產品時有流暢的體感，引導用戶做我們希望他/她做的事情；二是為了保證產品的健壯性，不會出現業務或流程上的“斷層”。

二、如何正確的輸出“提示信息”需求

分三步：

1. 根據已經完成的業務流程和產品架構，羅列出需要校驗的所有狀態。（包括但不限于用戶狀態、賬戶狀態、訂單狀態、商品狀態、授權狀態等）

圖1-業務流程

上圖為一個簡易的業務流程（已做文案脫敏，僅做參考），根據圖1我們可以歸納出用戶使用過程中需要校驗的項有：

圖2-根據業務流程歸納的校驗項

2. 逐個頁面填充已羅列出的校驗項，并明確校驗節點。（比如：落地即觸發、點擊交互觸發、滑動交互觸發等）

逐個核對每個頁面的校驗節點是一件很繁瑣的事，需要產品經理有足夠的耐心，核對過程中一定以之前確定好的業務流程和產品架構為標準，如非遇到產品的邏輯漏洞，一定不能再天馬行空隨意增改內容。

圖3-逐個頁面核對后的校驗項填充

上圖清晰給出了產品UI頁面中需要添加校驗項的頁面名稱及校驗內容。如果進一步規范，還可以注明頁面編碼（頁面編碼主要為提高產品、UI、前端之間的溝通效率和準確性）。

做到這里，我們需要和業務、研發等各團隊進行一次溝通或評審，確保我們沒有遺漏的同時，在業務層面對用戶的使用限制是合理的。

3. 說明提示類型（交互方式），給出提示內容。（包括但不限于Tosta、帶標題彈窗、單按鈕提示彈窗、雙按鈕提示彈窗等）

有了前兩步的鋪墊，工作就剩下具體的文案和提示交互設計了，我們在第二步的基礎上進行表格數據的補充即可。

圖4-完整的輸出文檔（Excel形式）

做到這里，就可以將此需求交付給開發人員了。交付物之需要圖4中的內容即可，前面的所有文檔留作產品文檔進行備份。

三、一點建議

我的團隊目前是把業務流程、功能架構、產品原型、接口需求、交互需求通過獨立文檔的形式來管理，所以你會看到我們上面說到的提示信息是以獨立excel的形式提交給相關開發人員的。

希望大家可以借鑒這種方式，時間跨度較長的項目，這種方式可以大大縮減溝通成本。而開發過程中最重要的就是時間，最浪費時間的就是溝通。

題外話——經驗不足或把控產品能力不是很強的同學，很容易被大公司的規范化開發制度坑掉，尤其是文檔管理這方面。

大公司為了節省人員更替的交接成本，常把產品文檔匯總成一個超大超長的文檔。在這里我想告訴那些初級產品伙伴們，根據我多年的文檔輸出經驗，盡可能細化的拆分你的需求，并進行文檔管理，對自己、對開發進度、對溝通成本都是有百利而無一害，別因為公司管理方面的利益，讓自己喪失了把控產品的主動權。

感謝各位讀者，希望對各位能有幫助！有各方面產品知識需求的同學，可以留言，我會持續更新！

本文由 @配色 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議