開發與設計說「你的原型我看不懂」，問題是？

週末兩天在忙於pmtalk深圳產品經理大會，每天晚上想更新的時候已經超過了凌晨12點。所以在今天才更新，2天與500餘產品經理們碰撞了一些不同的火花，接下來會在後續的原創中不斷整理輸出。

產品經理在日常工作中，溝通、文件、原型是主要的3個聚焦點。其中原型的輸出質量，是可以有效降低溝通，也可能會佔據接近1/3的產品經理工作時間

至於原型的評判好壞不僅是可能需要美感，最重要的是產品經理能不能把需求講的透徹。例如：開發、設計如果第一眼看到原型後，即可明確需求或本次的任務是否合理，假設本次給的開發時間就乙個星期，你卻原型給出了要3個月才可以完成的任務。顯然是對需求沒有抓準。

在實際工作中，測試會看產品prd外，開發與設計都是以原型檢視為多。因為原型的**閱讀高效、快捷。

分別是：產品框架表達、邊界表達、注釋說明，談談我個人的幾點建議。

產品框架表達

產品的框架不管是移動端還是web端，都是從依靠的業務或使用者路徑來搭建的。我們梳理出業務是什麼範圍，使用者路徑有多少。以頁面來表達

比如在社群產品中，使用者的路徑分：作者與遊客

1.作者使用者的主路徑

註冊——投稿——結束

2.遊客使用者的主路徑

註冊——閱讀——結束

上面2個不同的角色中，所使用的產品的核心路徑乙個是投稿、乙個是閱讀。私人作者也會閱讀，但以主路徑來看，其實投稿只有他們這個角色才產生的。

針對這樣的表達，我們要想避免開篇所提出的開發與設計的懟話。建議在一開始首先把頁面鏈結給出，如下圖。

上面只是羅列的頁面，但還缺少路徑。也就是頁面與頁面之間的鏈結，把業務與使用者路徑加上，原型的表達整體就非常清晰明了了。

邊界表達

邊界表達，最好的方式是在原型給予注釋。注釋的說明在原型中並不要想文件那樣針對每個頁面都加上。而是以邊界或帶有邏輯甚至是計算需求的地方進行解釋。

例如上圖中，所注釋的包含了生命資料的計算演算法、控制項的狀態、功能調整入口的說明。這一點也是原型中要求產品經理需求調研的能力，初級產品經理可能乙個頁面：每乙個按鈕、每乙個文案、每乙個彈窗都有注釋。

這樣顯然會增加了原型中需求消化成本，所以針對邊界點在原型中注釋，常見的是計算方法、條件、狀態判斷、數值邊界等說明是需要注釋的。

注釋說明

在原型中，一套好的注釋可以幫助開發盡可能不去看文件都可以理解需求。我在產品工作中，認為優秀的產品經理輸出原型開發或設計的疑問會較少。

在實際工作中，產品經理能力高低的比較場景也是通過開發、設計能不能看懂來評判的。還有要說，每個產品經理都希望自己輸出的原型應該是「分分鐘」被看懂，因為天天被同事吐槽，工作能愉快嗎？

注釋說明除了上面的邊界外，還要注意幾點

區域注釋是面向功能集合的區域說明，比如在移動端中常見的入口集合

例如美團點評的服務集合，在不同城市會有對應的展示邏輯。為此區域權重注釋是大於功能注釋的。

區域注釋需要與上面的邊界注釋區分出，保證開發或設計同學在看對應解釋不會分不清。另外區域注釋的要注意分清什麼地方可以使用，什麼地方應該使用邊界注釋。比如功能集合的入口，整體幾個功能的邏輯會有成套的條件，區域注釋是非常好的。

例如美團點評雖然服務功能都不同，但他們都會有地理位置因素，這是需要區域注釋來說明。

做好產品經理，從原型基本功開始

在週末與產品經理們交流的時候，發現在現實工作中也存在原型都不怎麼畫的產品經理。可能幾個截圖，加上無數次溝通，還是把產品做出來了。

但我認為，原型技能為什麼說是產品經理的基本技能，核心在於你連原型都不會做，如何表達你的需求呢？尤其是當你從產品新人開始，逐漸高階期間。難道沒有經驗的你，還能自然的嘴炮說出需求嗎？

推薦閱讀：

堅持一年，招募100個產品經理

我的第一本書，給你們

開發與設計說 「你的原型我看不懂」，問題是？