導語：產品原型並不是一個設計載體、而是一個高效溝通載體；產品原型有一套成熟的設計理論。本文為10年產品經理總結的產品原型架構方法論，圍繞5個方面、13個要點進行展開。助力產品經理從「術」的層面提升到「道」的層面。
一、產品原型的本質是溝通載體、而非設計載體
產品原型是每個產品經理必備的工具。很多初學產品的小夥伴可能認為實現原型設計最快捷的方式不外乎就兩種，一，淘取到一個成熟原型模板、COPY其設計；二，從業於BAT類網際網路企業、遵循其標準；
其實，如上兩種方法最終也是「邯鄲學步」（學到了形，而沒有學到神）。因為產品原型追根溯源解決的其實是」溝通效率」問題，而並不是如上兩種方式所聚焦的解決設計問題。
請各位思考這樣一個問題，倘若一個人身兼產品、設計、開發、運營多角色一身，產品原型還有必要麼？
所以，產品原型並不是一個設計交付物、而是一個溝通工具。認清這個本質之後，我們才可以建立產品原型的框架和內容、也才能掌握產品原型的設計方法論。
本文會圍繞5個方面，13個要點進行詳細闡述；這些要點均來源於多年實戰。適用於所有產品原型輸出場景，本文不是一篇產品設計工具書，而是一篇依託產品原型實現「高效溝通」的操作指引。
我先把我犯過的錯，或許小夥伴們也遇到過的困惑做一次盤點，看各位有共鳴否？
這些問題就如患羊癲瘋一樣偶發，不經意間在某個功能點上就會爆發；又如同腳臭一樣堅韌、無法根治則持續受其困擾。
總而言之，我們需要一種結構化的工作策略，可從根本解決如上困惑。那圍繞這個根本策略，我們總結了5個方面、13個要點；這些內容均是歷史項目中得到實踐、也形成原型的模板、也歸納成方法論；下面為各位展開論述：
二、一份好的產品原型判斷標準
首先，我們來分析一款好的產品原型，在高效溝通這個目標之下，需滿足什麼標準？我總結有如下5點：
簡潔精煉：內容沒有歧義、描述用詞準確專業、內容不重複；其中比較顯著的特點就是「不複製其他頁面內容，而採用關聯指向」，
全面完整：內容全面沒有遺漏，最終判斷標準就是進入開發後，很少或不出現補充遺漏邏輯；
鬆散組合：原型有公共描述部分、有個性化定義部分；最終實現每個開發只關注自己板塊的原型稿即可完成開發；
模板統一：整個原型擁有清晰的結構、準確的框架；自學習成本低，團隊內產品經理可形成一套統一模板；比如交付原型給新入職產品經理，該產品經理看完原型即可推動項目開發完成；
敏捷交付：原型大小以項目顆粒度為依歸；並於2周~1月內敏捷開發可上線；
三、5個方面概要圖
下圖為5個方面所對應原型中的一個設計要點，每個方面都解決如上的原型標準。
四、第一方面：菜單結構
4.1 菜單結構方面的價值
菜單結構是指產品原型的目錄具備清晰的結構、準確的框架，自學習成本極低；對應解決的就是原型標準中的「模板統一」。
4.2 錯誤的菜單結構案例
我們舉一個最簡單的訂餐系統為例，包含功能「加入購物車」、「支付訂單」、「登錄註冊」、「優惠劵下單」；如下是一個不良的原型菜單結構；
上面的菜單結構乍一看，沒有任何問題。可在進入項目實踐中會發現，該菜單結構存在非常多的弊端：
4.3 菜單結構」工作要點
我們將上圖的菜單結構進行一次規範整理，結果呈現的形式如下：
「菜單結構」整理的要點如下：
菜單依據A、B、C、D、E、F進行大板塊管理，比如A為商業分析、B為項目管理、C為公共文件、D為技術架構、E為前端原型、F為後端原型、G為運營管理、H為營銷推廣;
每個頁面用文件夾包裹起來，依據功能顆粒度，比如微信按照「萬能夾發送語音通話」、「萬能加發送位置」進行分類管控；比如上圖的「下單場景」文件夾
每個頁面採用固定命名規則：編碼 + 主數據 +業務 + 單據類型 ；A-01 火車票預訂單列表頁；而不是 「車票管理」這種不知所謂的命名；
產品原型每個頁面均要編碼；如A-01-01
總結，好的菜單結構如同一張清晰的地圖、任何人無經培訓都可看得懂。
五、第二方面：公共模塊
5.1 公共模塊方面的價值
公共模塊是指將原型中公共描述部分全部抽取進入一個版塊中統一闡述。公共描述部分需滿足兩個特點：其一是開發前所有人都要看；其二是在多個地方被引用；公共模塊對應解決的就是原型標準中的「鬆散組合」。
公共模塊分為三類，如下表從描述和包含給做了一次整理：
5.2 錯誤的原型案例
上圖中的例子，足可以說明，任何數據為空的頁面，產品都需要畫一個空值頁面來代表；這種方法弊端極大。其一產品需要花費大量時間去繪製價值低頁面；其二稍不留心則頁面設計無法統一；其三若空值頁面後期需變更設計，則需大批量修改。
5.3 「公共頁面」正確範例
所以，在「公共模塊」方面，我們採用一個公共頁面來統一風格，並通過參數來實現多地方調用；。比如下面「E-05-02-01 我的優惠劵列表頁」則採用參數調用「E-02-03 公共頁面–空數據」。
5.4 「公共模塊」工作要點
我們總結下公共模塊的工作要點如下：
所有開發都需知道的邏輯就抽取為公共內容；
從A位置複製到B位置，則該內容就需公共化；
公共板塊採用接口 + 參數進行描述；
公共頁面在原型板塊中也要建立獨立文件夾進行管理；
總結：好的公共模塊如同一部憲法、奠定了基本準則、構建了核心價值觀。
六、第三方面：單一頁面
6.1 單一頁面方面的價值
單一頁面是指採用體系化的描述方法來定義單個頁面的「頁面邏輯」和「交互邏輯」；單一模塊對應解決的就是原型標準中的「簡潔精煉」。
單一頁面分為三類，如下表從描述和包含給做了一次整理：
6.2 錯誤的原型案例
或許有些小夥伴會覺得上面的頁面描述已比較完整；不說大道理，直接上圖，看「單一頁面」的正確範例。
6.3 「單一頁面」正確範例
6.4 「單一頁面」工作要點
用表格列出結構化體系，同樣邏輯則用連結；表格內容不能為空；
連結只到單據編號；
總結，好的項目管控如同一座金字塔；層層分解條理清晰的闡述一個頁面的構造；
七、第四方面：自檢清單
7.1 自檢清單方面的價值
以上的內容足可以讓一份原型設計稿清晰準確、完整精煉；可這是否就代表產品原型設計已完善了呢？
恰恰不是，萬裡長徵才走完第一步！
設想在業務評審的時候，高層領導詢問如下問題，你如何應對？
你這款產品預估帶來的業務價值是什麼？顯性收益和隱形收益分別是？
你看過那些行業案例？他們都是怎麼做的？
你覺得你的原型中突出的幾個功能和設計要點是什麼？
你的平臺對海外或低網絡環境如何支持？
你覺得哪幾個功能模塊可以先開發？
你需要什麼運營支持？
7.2 「自檢清單」的工作要點
故而，我在團隊內採用自檢清單形式，每位產品經理在業務評審之前，可通過該清單，不斷審視產品。圍繞價值、競品、兼容、爆點、運營等多個方面進行深挖，
這種方式可讓產品不至於局限在操作體驗。同時在產品內部評審會議中，該表單也是設計稿能否通過的關鍵一環。
自檢清單方面要點如下：
自檢要素為7項：價值、競品、爆點、擴展、敏捷、宣傳、運營
自檢要素需在業務評審之前完成；
產品內評審需以此為參照物；
總結，好的單一頁面如同一份體檢單；幫助產品從用戶體驗中解脫出來，聚焦於價值和協同；
八、第五方面：項目管控
8.1 項目管控方面的價值
產品經理不是神，更何況在很多企業，產品經理都無力觸達經營。所以產品經理在思維上會極其受限。
故而，產品需藉助外力，完善原型框架、補充自身短板。
8.2 「項目管控」的工作要點
我總結的外力，就是三個會議，分別為「業務評審會、技術評審會、原型解說會」，每個會議都有各自目標，下表則詳細列出三個會議的與會人和補充的短板內容：
總結：好的項目管控如同一臺電話機，幫助聯通多角色的關注和資源；
本文由 @ boyka 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議