編輯導語：畫好産品原型，是每一位産品經理的必修課。而從零開始的項目，其難度更是高于其他已經進入正常疊代節奏的項目。本文主要從個人的實際工作經驗出發，介紹如何畫好新項目的産品原型。感興趣的小夥伴們快來一起看看吧。

在每個産品經理的成長道路上，總會遇到一些全新的挑戰，比如全新的功能，全新的項目，乃至全新的業務，全新的市場。

每一次新挑戰，都是對自己的一次磨砺。

其中，經曆一個從零開始的項目，親手打造一個全新的産品，對于産品經理來說，是成長最快的一種方式，同時也是檢驗自己能力的絕佳路徑。

然而，負責一個全新的項目，與負責特性疊代、新的功能模塊有所不同，其複雜度有了很大的提升，很多時候會讓人難以入手。

新項目的市場分析、用戶分析、需求分析等等，已經有許許多多的文章和介紹，在此就按住我個人的拙見不表。

本文主要從新項目如何進行原型設計這一角度切入，介紹個人的一些工作經驗，希望能對大家有所幫助和啟發。

一、新項目的難點

一個新項目的産品原型，之所以會讓人感到頭疼，主要有以下原因：

• 新項目不像功能特性疊代，需要有全局視角，但項目中的所有人（包括産品經理自己），對産品的最終形态，都缺乏一個清晰直觀的認識；
• 新項目往往包含多個模塊，原型設計上容易聚焦于每一個模塊和頁面本身，最終使得原型隻是頁面的堆積，而缺少功能模塊之間的聯動；
• 不同功能模塊有輕重緩急，頁面上的不同功能也有輕重緩急，産品原型很難在呈現整體功能特性的同時，體現不同模塊、功能的優先次序；
• 在整個項目的過程中，随着讨論的深入以及項目的推進，原型會經曆反複的修改，内部的信息很難對齊。

正因為存在如此多的困難，所以做好這件事情，才顯得如此有意義。

本人去年開始負責部門内一個老系統的重構，由于新系統增加了許多功能特性，也删掉了老系統許多的冗餘功能，整體的流程和交互上也有了很大的調整，因此在一定程度上也可以當成一個全新的項目。

由于是後台項目，因此這個項目并沒有交互設計師、視覺設計師加入，産品經理提供的原型，也直接應用于項目研發中。

為了支持這個項目，部門也投入了一些新的研發人力，這些新進入項目的同學，對業務知識、老系統的功能知之甚少，因此如何通過需求原型統一大家的認識，并實現對項目的持續推進，成為了梳理系統需求以外最重要的事情。

我也會以這個項目的一些實際工作經曆為例，介紹如何進行新項目的原型設計，以及進行原型的更新疊代。

二、業務流程等産品資料

很多産品經理，會将産品原型等同于頁面交互。

其實，産品原型從本質上來說，是一種溝通工具，它能讓産品經理能夠更加方便地傳達産品的功能特性，也能讓研發、測試能夠更加快速地了解産品的流程及功能，進而可以更準确地對方案進行評估。

因此許多溝通技巧，在産品原型中也同樣适用。

沒有人喜歡在不了解背景的情況下，一下子就進入溝通的正題。

對于産品原型也一樣，因此我們也需要在産品原型中，針對相關業務背景，以及業務流程進行鋪墊，讓團隊成員不要先有一個整體的認識，而不是一下子進入具體的頁面設計中。

1. 核心業務流程

下方截圖内容，就是騰訊雲備案審核系統的關鍵業務流程，整個審核系統的訂單處理，就基于這個核心流程來推進。

2. 頁面流程圖

除了講述核心的業務流程以外，我們還需要介紹整個系統包含哪些模塊，每個模塊包含了多少個頁面，頁面之間的關系是如何的。

如果某個功能模塊相對來說比較複雜，涉及到了多個頁面，那麼有一個清晰的頁面流程圖，就可以更好地幫助研發理解。

3. 頁面狀态及交互說明

上面的部分，是不同頁面之間的流轉關系。

有些時候，同一個頁面，在不同的狀态或環節，其主要功能操作往往也有所區别，因此在特定的頁面，最好也能加上頁面狀态及主要功能操作的說明。

4. 競品資料

競品調研也是産品分析環節非常重要的一環，在産品原型的設計中，友商的設計經常能開闊我們的視野，為我們帶來一些啟發。

我在進行功能體驗的時候，對友商産品流程進行的整理，看看友商在哪些地方學習了我們，也看看友商有哪些地方值得我們學習。（在這裡也給産品新人提一個建議，對于自己負責的項目，也可以根據類似的辦法，整理相關的資料）

三、每個頁面/模塊增加功能點列表

在進行具體頁面的設計時，往往很難在一個頁面中講述清楚所有的功能，尤其是涉及到狀态變更，以及某些隐藏功能的時候。

此外，頁面中不同功能的優先級是不一樣的，追求頁面功能完整性的話，就會顯得頁面非常臃腫，難以區分輕重緩急。

這個時候，我們可以在子頁面中具體介紹每一個子功能點，大到一個重要的交互，小到一個具體字段的定義，都可以單獨進行說明。

同時，在頁面中增加一個功能點列表，并對每一個功能進行編号，以及定義好相關的優先級。

這個項目，因為開發工作量較大，我們分為了好幾期進行開發，PM和研發也主要根據這裡定義的優先級進行排期。

四、不制作過于複雜的交互效果

沒有人不喜歡高保真原型，但高保真原型是有代價的。

在我看來，具有複雜交互效果的高保真原型，主要是面向老闆（投資人）、産品核心用戶的，并不适合敏捷開發流程。

在實際的研發流程中，高保真原型是存在一些缺點的：

（1）不直觀

某一些彈窗必須通過特定的條件或特定的按鈕才能觸發，如果研發比較粗心，沒有注意到原型中的這個點擊動作，那就漏過了這個産品經理精心設計的功能了。

（2）容易讓人聚焦于細節

産品實現需遵循粗放到精緻的過程，如果原型中使用了過于複雜的需求，容易讓人聚焦于細節，而忽略整體流程中的問題。

（3）維護困難

項目初期，産品原型會經曆非常多的改動，甚至會出現删掉某個大模塊的情況，具體到每一個頁面，也時常經曆着大改的考驗，因此過于複雜的交互，會給後續産品原型的維護帶來諸多困難。

（4）職責不明

如果項目還有交互、視覺同學參與進來，那麼太過于精細的産品原型，反而會限制交互、視覺的發揮，讓交互、視覺的工作淪為“畫圖”，反而少了許多對項目的思考及參與，長此以往，對整個項目反而是不利的。

目前包括Axure在内的很多原型設計工具，都支持制作複雜的交互效果，但我們要秉承“為我所用”、“我會，但沒必要”的原則，使用合适恰當的方式來呈現需求。

個人是習慣将彈框這些默認不可見的元素，也放到頁面原型的旁邊，并在頁面中增加相關标記，表明頁面元素與這些彈框的關系；此外，也會在頁面中增加相關文字說明，以便研發同學了解。

五、發布在線原型

Axure這些原型工具是支持生成html文件的，可以直接通過浏覽器打開，查看原型的具體内容。

然而，如果原型需要頻繁修改，那麼原型文件的同步就成了大問題。往往一個原型文件剛發出去，就發現有一些需要修改變更的地方，又需要趕緊打包一個新的版本。多的時候，一天打包十幾個版本都是可能的。

版本衆多的原型文件，很容易造成信息不對稱，因為産品經理也很難将最新的原型文件及時同步給到所有人。

因此，有一個統一的，在線的，可随時更新的在線原型是非常必要的。

Axure本身支持将産品原型發布到雲端，可以直接鍊接查看産品原型，不過這樣做會存在信息洩露的風險。

為了規避這種風險，我們可以将原型的靜态文件更新到自己的服務器上。

我之前的項目中，就曾經通過這種方式進行管理，讓研發同學幫忙将原型文件發布到内網的服務器中。

隻不過這種習慣最終沒有保留下來，因為服務器權限還是在研發同學那裡，每次發布原型都需要研發同學幫助，後來項目團隊發生變化之後，就沒有繼續沿用這個方法了。

後來發現了騰訊内部的pages工具，可以來發布靜态頁面，産品經理自己就能适用git工具發布更新原型文件，雖然存在一點門檻，但上手之後卻是非常方便。

目前我們團隊内部的産品經理都主要使用這種方式來對外發布産品原型，推薦大家學習使用。

六、時常更新，并記錄變更内容

在線原型雖然可以實時更新，但也引發了新的問題：産品經理在同步原型文件的時候，一般還會同時同步修改的内容。

但可以方便地實時更新之後，這種修改記錄的同步就很難要求了。即使同步了，往往也隻是在項目團隊内部，而很難同步到項目團隊以外。

因此在原型中，最好能夠配套一個ChangeLog，這樣可以讓所有人員，快速了解原型的更新内容。即使每天原型更新十幾次，也能夠在ChangeLog中說明所有改動的内容。

七、适合的，就是最好的

之前說過，原型是一種溝通工具，既然是一種溝通工具，就需要根據溝通的對象，溝通的場景，以及團隊内的流程及習慣進行調整，并沒有放諸四海皆準的标準，适合的，就是最好的！

作為産品經理，在産品需求溝通這個環節，應該将團隊成員當成用戶，将原型當成一個産品來打磨。

團隊成員，除了研發，還會有PM、測試，乃至是Leader，不同角色想要從原型中獲取的信息各不相同。

同樣是研發職能，不同的研發人員的習慣也不盡相同。

作為産品經理，在進行原型設計時，需要考慮不同職能，不同人員的需要，不斷地打磨原型内容的呈現，盡可能地提高團隊内部的溝通效率。

最後也說一句，我們不能忽略忽略産品原型在項目中的作用，也不能過度拔高原型的作用，不能因為有了清晰準确的産品原型，就省略掉必要的溝通。

作者：klayhuang，騰訊産品運營；公衆号：騰訊大講堂

本文由 @騰訊大講堂 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,