在《用戶體驗要素》一書中說到，產品是由戰略層、范圍層、結構層、框架層和表現層這5層組成。

而之前的文章中，給大家介紹了做產品要如何貼近用戶、如何評估需求的。即從戰略層和范圍層的角度，去解決問題，定義需求。那在需求明確后，我們又該如何將需求轉化成產品方案呢？

這篇文章，將從前期準備、方案設計、需求評審三個層面，給大家介紹下該如何從結構層，框架層和表現層，對需求進行產品化設計，并通過需求評審的。

大家如果有需要的話，可以先收藏，后續設計方案時，再一一核對參考，保證我們在設計方案時，做到不重不漏。

一、前期準備

1. 明確需求目的

目的，是產品方案的指向標。我們通過各種渠道，獲得需求后，我們首先要明確，做這個需求的目的是什么，是為了解決什么問題，滿足什么需求而出發的。

因為，我們在需求產品化過程中，會產生很多“新點子”。但這些點，是否適合放到產品方案中，就需要我們立足于需求目的，去通盤考慮，平衡投入產出比，輸出符合預期的產品方案。

總的來說，需求或版本的目的可分為以下三類：

1. 用戶體驗優化：已有功能點優化、增加操作入口、增加功能等；

2. 提高內部效率：增加內部平臺某種能力、給運營增加推廣渠道、功能組件化開發等；

3. 商業化：增加會員模式、增加對接廣告接口等。

為了保證產品人對需求有足夠的深入的思考，一個版本或一個方案，都只要解決一個主要問題。因此，我們在定義目的時，也要盡可能收攏到一個核心觀點上，讓整個方案都圍繞目的服務。

2. 了解需求背景

不論多大的公司，多大的團隊，在產品的發展階段，資源都是不夠用的。此時，論證需求必要性，提高需求實現的優先級，就非常重要。

而了解需求背景，我們首先找到需求第一來源人，并通過以下兩點，來論證需求必要性：

1）數據論證

通過調查，從數據層面，來論證需求的緊急性和迫切性。

如：用戶體驗優化，可以用用戶投訴量來論證；內部平臺能力和商業化需求，可以用上線多久后提升多少收益，或估算投入產出比（ROI）來論證。

2）競品調研

若市面上有同類產品已實現該需求，這也可以側面論證需求實現的必要性。所以，我們可以通過調研的方式，梳理的功能流程圖，并從用戶、需求、場景三要素進行分析，看競品是否滿足需求的，又是如何滿足需求的；

但在實際工作中，系統的競品調研，其實比較少做，主要是比較耗費人力，后續有機會的話，會專門寫一篇文章來給大家詳細介紹，這里就不過多描述了。

可雖說我們比較少做系統的調研，但我們在平時的工作中，也會關注競品每個版本新增的功能模塊。分析后，若發現競品的新功能是符合用戶需求的，我們也要及時跟上。

二、方案設計

在明確目的，了解背景后，我們進入產品方案的設計環節了。即下列內容，將正式從結構層，框架層和表現層的角度，和大家介紹該如何把需求，進行產品化方案呈現的。

而這個環節的最終目的，是要我們輸出完整產品方案，接下來我將從五個步驟來跟大家進一步介紹：

1. 邏輯梳理

在做需求時，很多剛入行的產品，接到需求后，就直接就開始畫原型，這個是錯誤的。因為，畫原型，是產品方案已經確定，產品流程無明顯紕漏，需求邊界已經明確后，才開始執行的工作。

否則，后續評審或開發過程中，會出現因方案不夠嚴謹，出現多次返工的情況。不僅降低我們自己的工作效率之外，而且還可能影響產品的迭代節奏。

所以，在畫原型之前，首先我們要先梳理兩個核心邏輯：

1）產品方案邏輯

產品方案之所以被稱之為“方案”，因為它是從宏觀的系統角度，可持續迭代的層面切入需求，且通常需要多角色配合的。

如，為了減少用戶投訴而做的產品方案，就要從客服、用戶、運營、產品這四個層面，告知各方在不同的版本后，需要支持和協助的工作是什么。

因此，我們在梳理產品方案時，要關注不同角色的所面臨的問題，如何持續觀察優化的角度去通盤思考。

我們可以從第一用戶要執行的動作入手，進行邏輯推演。如下圖泳道圖所示，我們如果要開發一個給客戶提供線上下單的平臺，就可以從要發貨的客戶下單的動作入手。

客戶下單之后，訂單數據應該被哪個下游角色所接收，接收之后，下游角色還需要哪些角色配合支持，以此來不斷往下延伸拓展。

在梳理清楚之后，我們再最終把所有角色的交匯場景通過泳道圖的樣式呈現出來，明確各個角色要支持整個產品方案的具體工作，最終輸出產品方案的流程圖。

2）頁面流程

頁面流程是從微觀產品功能層面的邏輯梳理，是包含在產品方案中的某個產品能力。常用于大小功能點優化，版本升級中某功能點的梳理。

如：上面的客戶下單、受理、創建單的場景，客戶是如何在什么頁面，點擊哪個模塊下單的，受理部門受理之后，又是如何創建運單的，把這些頁面的具體操作流程一一細化梳理出來。

如果是功能點優化，可以從用戶和數據交匯核心頁面出發，梳理頁面流程。

如果是獨立的功能或產品版本，可以先從功能入口出發，思考各頁面中用戶是誰、解決的需求點是什么、產品如何解決需求的，并且后續還要考慮數據流轉情況。

這里的用戶是包括所有使用產品的角色，可能有運營、客服、銷售、領導層、運營、開發等。當然，如果需要呈現多角色的使用流程，同樣可以利用泳道圖的方式來呈現。

如果競品有類似的功能，我們也可以參考競品的頁面流程，但注意，我這里說的是“參考”，不是“照抄”。產品人要以滿足用戶的需求來思考方案，面向用戶場景來設計需求，解決用戶問題為最終目的。

3）注意事項

• 工具無優劣

就跟吃飯用筷子還是用勺子的一樣，選擇適合自己的就行。因此，不論是泳道圖、流程圖、還是簡單的線框圖，只能能清晰地描述邏輯即可。

• 方案多選擇

在思考方案時，肯定會有多個方案，多種場景，如果出現難以判斷孰優孰劣，可以輸出多個方案。在內部討論或向上匯報時，陳述不同方案的優劣勢，讓大家一起討論決策。

以免出現單方案不通過，要重新思考，降低工作效率。

• 善于求助

工作是要解決問題的，不是來體現你個人能力的，這也是你們之所以稱之為“團隊”的原因。如果遇到自己確實無法解決的問題，要及時向同事或上級同步困難，尋求幫助。

• 流程多討論

在方案梳理時，要和需求涉及的團隊多溝通，尤其是開發，保證方案切實、可行；在梳理完成后，要盡快在團隊內部和領導過一遍，以保證產品邏輯無太大紕漏再執行下一步。

千萬別偷懶，也別怕麻煩，畢竟，很少有人能夠獨立的把整個方案都思考得很全面。前期的每一步繁瑣，都是為了避免落地時的返工。

2. 確定邊界

在確定核心流程之后，需要進一步細化方案，確定需求邊界。主要是補全流程中異常情況和應對策略，盡可能做到，既節約資源，又擁有好的用戶體驗。

在補全異常流程時，我們主要關注四個問題：

1）平衡：注意平衡用戶體驗與開發工作量的關系

在實際工作中，工作量和用戶體驗是成反比的，體驗越好的模塊，工作量越大。所以，產品的工作要從需求目的出發，尋找雙方的平衡。該如何取舍，取決于產品發展情況、市場情況、產生命周期和產品自己的工作經驗。

如果遇到難以決策或解決的問題，要及時向上匯報，尋求幫助。

2）安全：資金安全和用戶安全問題

新版本的微信，紅包功能就調整了紅包個數和金額的位置，導致有大量的用戶導致資金和金錢輸入錯誤，導致用戶投訴。

因此，如果需求涉及資金、用戶信息等問題，要慎之又慎。產品文檔在進入評審會之前，最好多過幾輪，以求萬無一失。

3）復用：組件化開發

如果功能模塊后續可能被其他需求所復用，為節約開發成本，可以與研發多溝通，看是否可進行組件化開發。

如：banner廣告可能可以在其他頁面復用，但當前版本僅支持首頁的應用即可，就可以進行組件化開發，后續其他頁面如果需要的話，就可以直接復用。

4）便捷：配置性功能開發

如：banner的內容后續需要經常更換，為了減少后續反復發版，影響線上功能，也可以和研發多溝通，看能否進行配置性開發。

這也是節省了研發后續的工作量，你跟他提，他會比較樂意幫助你的。

3. 原型設計

原型設計是在框架層，來思考和設計產品的。前面的邏輯和需求邊界都確定的話，這一步其實可以讓交互設計師來支持，尤其是業務推進比較忙的時候。

但并非所有公司都有交互設計師，如果沒有的話，這一步還需要自己來實現。畫原型的具體操作，就不多講了，如果是剛入行或準備入行的小伙伴，想學的話，可以報個班學一下Axure或sketch。

不用太精通，只要能把想要的頁面，簡單的還原出來，設計師和開發都能看懂，就已經足夠了。在這里我講一下幾個避坑指南：

1）原型分版本保存

我剛做產品的時候，原型都是直接覆蓋上一個版本的。但后來，評審會的時候老大提出要加什么功能，我突然想起這個功能在之前一個版本做過，但想找回來，卻發現版本已經被覆蓋，找不到了…

2）原型有注釋

如果原型沒注釋，就跟上課不做筆記的后果一樣，很容易一轉頭就忘了。而且不在原型中注釋的稿件，如果給開發或設計執行時出錯了，最后吃虧的還是我們自己。

3）異常情況定義清楚

除正常的注釋之外，異常情況也需要在原型中定義清楚。

因為，有些開發在開發時，不一定會時刻盯緊文檔來看。所以，除了文檔中要說清楚異常情況的設計標準之外，最好在原型中也要注釋清楚，也是為了避免后面出現問題時，相互扯皮。

4）需求修改及時備注

如果需求在評審或開發過程中，有變更的情況，除了在文檔中備注之外，原型中也需要及時變更。

以上內容，都是我用血和淚給大家總結的經驗教訓，我剛入行的時候，因為偷懶，很多地方沒有做好，當時背過很多鍋，所以希望大家，千萬不要再重蹈我的覆轍了。

4. 建立數據反饋

一個好產品人，是會從更高的產品系統的層面，思考和解決問題的。

因此，為了更好地驗證目標的達成與否，我們需要建立數據反饋機制，給產品方案提供統一的衡量標尺。我們團隊建立數據反饋主要是通過兩點：

1）埋點

C端的功能型需求，是可以通過用戶反饋來迭代的。但除此之外，我們還要增加當前功能點的埋點，為產品后續優化提供更嚴謹的理論支持。

如果是剛上線的基礎功能，還未確定明確的業務指標，可以只增加基礎埋點。如：產品頁面曝光pv、曝光uv、點擊pv、點擊uv等。

將埋點數據統一上報到數據平臺中，定期觀測數據表現情況，以便優化后續產品。但如果是有上線有一段時間的產品，我們要從業務指標衡量標準出發，對產品數據埋點，進行二次或三次的拆解。

也可以參考前面的頁面流程圖，一般來說，有需要判斷的地方就要有埋點。我們只有知道每個節點數據流向，后續才能建立數據模型，分析用戶操作。

2）異常監控

產品要經常主動觀察數據表現，但人力有限，我們無法做到24小時實時盯著數據。所以，若功能中有影響用戶核心操作的功能點，還需要讓研發幫忙建立異常監控，以保證產品核心流程能夠滿足用戶正常使用。

如：我們團隊就有通過微信的開放能力，建立告警機制，一旦某個商家出現問題，就會出現如下圖所示的告警通知，以便我們的產品和開發團隊能快速發現并處理問題

這也是技術團隊在溝通方案時，要和技術一同關注的風險點。

5. 需求文檔

在全面思考以上的四點后，我才會遵循以下呈現方式，將它們統一收攏到文檔中，形成完整的產品方案。

首先，在文檔開頭，描述背景和目的，最好用調查過的數據，來論證需求實現的必要性；其次，將產品原型或交互設計稿放到需求模塊，要圖文結合，讓文檔的閱讀者能夠清晰地知道每個功能點，具體需要做什么。

如果涉及多端支持的需求，我會從支持端的角度來陳述需求。即前端要做什么，后臺要做什么，數據要做什么，支付要做什么。

然后，把接口文檔、原型、交互稿、設計稿等相關附件，都附在需求文檔中，以免遺失；最后，再補充一點，如果文檔有變更，要及時，立刻更新到文檔中，同步給各方，避免背鍋。

我的習慣是在開頭用紅色加粗字體，描述修改的需求點和修改日期。

三、需求評審

當完成上面所有內容后，我們的需求才可以進入到需求評審階段。需求評審的目的，是為了論證需求執行的必要性，方案落地的可行性，同時給要支持需求的各方，都能夠了解產品方案具體需要大家做什么。

所以，為了讓產品需求順利通過評審，我們要從評審目的出發，逐一打消評審方的疑慮。

1. 需求必要性評估

評審一開始，就要先陳述目的和背景。這里前面也講過，要用數據來論證需求必要性，調查的數據必須要足夠合理且嚴謹，才能有效通過評審，并拔高需求優先級。

2. 方案可行性評估

介紹完目的和背景，獲得評審各方的認可之后，就可以和大家介紹解決問題的需求方案，和數據埋點情況。

在陳述方案環節，我也遇到過需求被直接打回的。出現這種問題，可能是前期產品邏輯有問題，又或者是產品方案沒有和開發充分溝通，最終設計出不適合落地需求。

但一般能到評審會的需求方案，都通過了產品內部的評估，基本沒什么方向和邏輯上的問題，除非是自己偷懶。而技術層面能否通過評審，就依賴于我們在前期設計方案的時候，是否能多和開發溝通，明確技術細節，以保證方案是可以落地的。

3. 方案持續性介紹

一般前兩點評估通過，需求就是可以落地執行的了。但我在介紹完方案之后，還會補充介紹下后續的運營方案和產品的迭代計劃。

一來，可以給開發打個預防針，告知這個功能后續優化的可能性，讓他們提高對需求的重視程度；二來，系統全局的描述，也能體現你在產品能力。

每一個產品需求，都是我們展現自己的機會。在職場，只有緊緊抓住每一個機會，我們才有承接更大需求，在產品道路更進一步的可能。

三、寫在最后

產品方案，是從用戶、問題、場景的視角去切入需求，在更系統的產品層面和更長的時間維度上，全面思考，輸出的文檔。

以上內容，是我這兩年，把寫過的大大小小數百個需求，匯總整理出來的。包括目的、背景、產品邏輯、需求邊界、原型、數據、需求文檔這七點，我將這七點統稱為需求落地的“七要素”。