編輯導語：在產品經理的日常工作中，往往需要了解和收集許多的用户需求，那麼，如何將這些需求進行分析篩選，然後轉化成為一份產品方案呢？本文作者結合自身的經驗，從前期準備、方案設計、需求評審三個層面，為我們介紹瞭如何對需求進行產品化設計並通過需求評審。
在《用户體驗要素》一書中説到，產品是由戰略層、範圍層、結構層、框架層和表現層這5層組成。
而之前的文章中，給大家介紹了做產品要如何貼近用户、如何評估需求的。即從戰略層和範圍層的角度，去解決問題，定義需求。那在需求明確後，我們又該如何將需求轉化成產品方案呢？
這篇文章，將從前期準備、方案設計、需求評審三個層面，給大家介紹下該如何從結構層，框架層和表現層，對需求進行產品化設計，並通過需求評審的。
大家如果有需要的話，可以先收藏，後續設計方案時，再一一核對參考，保證我們在設計方案時，做到不重不漏。
一、前期準備1. 明確需求目的目的，是產品方案的指向標。我們通過各種渠道，獲得需求後，我們首先要明確，做這個需求的目的是什麼，是為了解決什麼問題，滿足什麼需求而出發的。
因為，我們在需求產品化過程中，會產生很多“新點子”。但這些點，是否適合放到產品方案中，就需要我們立足於需求目的，去通盤考慮，平衡投入產出比，輸出符合預期的產品方案。
總的來説，需求或版本的目的可分為以下三類：
- 用户體驗優化：已有功能點優化、增加操作入口、增加功能等；
- 提高內部效率：增加內部平台某種能力、給運營增加推廣渠道、功能組件化開發等；
- 商業化：增加會員模式、增加對接廣告接口等。
為了保證產品人對需求有足夠的深入的思考，一個版本或一個方案，都只要解決一個主要問題。因此，我們在定義目的時，也要儘可能收攏到一個核心觀點上，讓整個方案都圍繞目的服務。
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. 方案持續性介紹一般前兩點評估通過，需求就是可以落地執行的了。但我在介紹完方案之後，還會補充介紹下後續的運營方案和產品的迭代計劃。
一來，可以給開發打個預防針，告知這個功能後續優化的可能性，讓他們提高對需求的重視程度；二來，系統全局的描述，也能體現你在產品能力。
每一個產品需求，都是我們展現自己的機會。在職場，只有緊緊抓住每一個機會，我們才有承接更大需求，在產品道路更進一步的可能。
三、寫在最後產品方案，是從用户、問題、場景的視角去切入需求，在更系統的產品層面和更長的時間維度上，全面思考，輸出的文檔。
以上內容，是我這兩年，把寫過的大大小小數百個需求，彙總整理出來的。包括目的、背景、產品邏輯、需求邊界、原型、數據、需求文檔這七點，我將這七點統稱為需求落地的“七要素”。
本文由 @豆奶 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。