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

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

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

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

一、前期準備

1. 明確需求目的

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

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

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

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

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

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

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

2. 了解需求背景

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

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

1）數(shù)據(jù)論證

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

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

2）競品調研

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

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

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

二、方案設計

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

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

1. 邏輯梳理

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

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

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

1）產品方案邏輯

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

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

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

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

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

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

2）頁面流程

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

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

如果是功能點優(yōu)化，可以從用戶和數(shù)據(jù)交匯核心頁面出發(fā)，梳理頁面流程。

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

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

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

3）注意事項

• 工具無優(yōu)劣

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

• 方案多選擇

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

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

• 善于求助

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

• 流程多討論

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

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

2. 確定邊界

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

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

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

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

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

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

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

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

3）復用：組件化開發(fā)

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

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

4）便捷：配置性功能開發(fā)

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

這也是節(jié)省了研發(fā)后續(xù)的工作量，你跟他提，他會比較樂意幫助你的。

3. 原型設計

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

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

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

1）原型分版本保存

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

2）原型有注釋

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

3）異常情況定義清楚

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

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

4）需求修改及時備注

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

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

4. 建立數(shù)據(jù)反饋

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

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

1）埋點

C端的功能型需求，是可以通過用戶反饋來迭代的。但除此之外，我們還要增加當前功能點的埋點，為產品后續(xù)優(yōu)化提供更嚴謹?shù)睦碚撝С帧?/p>

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

將埋點數(shù)據(jù)統(tǒng)一上報到數(shù)據(jù)平臺中，定期觀測數(shù)據(jù)表現(xiàn)情況，以便優(yōu)化后續(xù)產品。但如果是有上線有一段時間的產品，我們要從業(yè)務指標衡量標準出發(fā)，對產品數(shù)據(jù)埋點，進行二次或三次的拆解。

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

2）異常監(jiān)控

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

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

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

5. 需求文檔

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

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

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

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

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

三、需求評審

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

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

1. 需求必要性評估

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

2. 方案可行性評估

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

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

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

3. 方案持續(xù)性介紹

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

一來，可以給開發(fā)打個預防針，告知這個功能后續(xù)優(yōu)化的可能性，讓他們提高對需求的重視程度；二來，系統(tǒng)全局的描述，也能體現(xiàn)你在產品能力。

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

三、寫在最后

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

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