如何能保證一直產出高標準的方案是每個產品經理都需要思考的問題。方案設計是需要經過大量思考的，但我們不能亂想、硬想，不能指望靈光乍現來保證工作質量，而是應該有邏輯的去思考，有一套設計方法論在背后做支撐，這樣才能讓每一次方案設計都以一個高標準來產出，做到一直靠譜且高效。

接下來我們就從6個問題出發來探討如何從接到需求到產出靠譜方案。

一、收集需求：為什么要做這個需求？

眾所周知，需求來源有多種渠道，可能來自用戶、可能來自業務部門、可能來自老板，也可能是產品組內部規劃出來的。不管什么渠道，在收集階段要盡可能的多搜集和記錄，不要拒絕需求。在接到需求時，一定要問提出方或是問自己，為什么要做這個需求？

不清楚需求背景和要達到的目標，很可能從源頭上就思考錯方向，后面思考的再充分也無濟于事。為什么要做這個需求，我們可以從以下三個問題得到答案。

（1）做這個需求是為了解決什么問題？當前是怎么處理的？

如果這個問題對業務流程影響很大，并且當前沒有好的處理方式，必須用新功能來滿足，那么顯然這個需求是很緊迫的；如果當前的處理方式也能較好的滿足，則需求的緊迫性就相對低一點。

（2）做了這個需求能讓大部分用戶體驗更好嗎？

讓大部分用戶都能獲得更好體驗的需求顯然是我們更應該關注的需求；如果某個需求能提升一小部分用戶的體驗，但是會損害大部分用戶的體驗，則需要慎重考慮是否該做。

（3）做了這個需求能對業務產生什么影響？具體的業務目標是什么？

目標感能給我們一個思考標準，后續的思考和設計都會向著這個標準去靠攏；同時，知道具體的目標是什么也能在需求上線后以此來檢驗是否能達到預期，若達不到，則需要思考是哪里出了問題。

二、需求分析：這個需求為誰而做？

這是在確定要做某個需求之后最需要搞清楚的問題，如果不知道為誰而做，就不能設身處地的去思考使用場景，不清楚使用場景，那就只能拍腦袋做了，做出來的功能很可能不得要領，甚至根本沒法使用。

比如很常見的老帶新功能，就涉及到2個角色，老用戶和新用戶（這里為了便于說明思考路徑，并沒有交代具體是哪個行業的產品，實際工作中還需要結合產品本身的用戶特征去進一步分析）。接著再從角色的角度去思考他們關心的是什么？

老用戶最關心的是什么？顯然是邀請新人成功后能獲得什么好處，這是促使老用戶分享產品的最直接的原因。

新用戶最關心什么？新用戶不了解產品，最關心的當然是分享給我的產品是什么，有什么特色？或者直白點說，這個產品好在哪里？我為什么要買單？

老帶新有哪些場景呢？老用戶可能通過微信群、朋友圈或者面對面等多種場景去邀請新用戶。微信群邀請分享的一般是分享鏈接或圖片，朋友圈邀請分享用圖片更好，因為能展示更多信息；而面對面分享則只需要二維碼即可，因為老用戶一般在線下已經完成了口頭邀請，只是通過產品功能來走完線上流程。

三、流程梳理：涉及哪些角色任務，對其他模塊有什么影響？

思考清楚角色和場景之后，不要直接畫原型，而是先把流程梳理清楚。梳理流程可以讓思維從具體的細節方面跳脫出來，更容易思考重點和全局；梳理清楚流程也就理清了整個功能的脈絡，較為復雜的功能通過梳理流程來看到功能涉及哪些角色，每個角色是如何參與到產品中來的？當前功能對其他模塊會產生什么影響，需要做哪些調整等。

再以老帶新活動為例，假設這是一個K12教育產品，老學員通過邀請新學員來獲得贈課。我們可以梳理出以下流程：

通過梳理流程很容易發現這個活動的關鍵就在于如何判定新老學員、在什么節點建立新老學員的綁定關系、什么節點發放獎勵以及如何防止刷單。對其他模塊的影響則是通過邀請產生的贈課，它和正常購買的課時是一回事嗎，能直接使用嗎？如果不能，又需要對這些贈送的課時做怎樣的處理？

關于流程圖的繪制技巧，這里也簡單列出3點以供參考：

1. 當某流程出現選擇或決策結果時，需要認真走查，避免出現漏洞，導致流程無法形成閉環，功能缺失。
2. 繪制時，考慮流程圖全局，合理安排繪制路線，盡量繪制的簡單明晰。繪制必須遵從從上自下，從左至右的順序。
3. 處理程序需要形成閉環。堅持一個入口，盡量避免路徑交叉，使得流程圖在邏輯上不出現缺失。

四、原型設計：每個頁面的任務是什么？重點信息什么？

流程梳理清楚后就可以針對具體頁面進行原型設計了，這時候要考慮的是頁面元素、信息展示以及交互邏輯的問題。通常的思考路徑是圍繞任務設計元素輔助用戶完成任務，填充完元素后再將元素轉化為一個個控件如點擊按鈕、文本框、文字或圖片等。

1. 將當前頁面需要展示的信息都羅列出來；
2. 判斷哪些是用戶要知道的重要或必要信息，哪些是輔助信息；這里還需要思考信息的數據來源，有些數據若系統本身并未記錄則要考慮如何采集數據；
3. 將重要或必要信息要占據在顯眼位置，輔助信息則可以安排在邊緣位置，顏色和大小也要做適當區分。

具體的樣式可以不用考慮，但是重點信息或元素一定要心中有素，要明確傳達給設計師。這里我們以叮咚買菜的老帶新活動為例：

對于邀請頁，老用戶的任務是分享海報。重要的信息是傳達給老用戶邀請成功后他能獲得什么好處，輔助信息是邀請流程及一些營銷信息，而必要元素則是各場景的邀請按鈕。

對于接受邀請頁，新用戶的任務是接受邀請。重要信息是傳達出產品的核心賣點或用戶的核心痛點（這里叮咚買菜主打的用戶痛點就是用戶自己去菜市場買菜很麻煩，拎菜很重，包括配圖也用了配送小哥肩扛大米的圖，讓用戶一眼就能想到自己買米，拎米的痛苦，這點非常贊）；其次才是接受邀請能獲得的好處以及平臺等保障退款等次要和輔助信息；而必要元素則是小程序二維碼，新用戶需要通過掃碼后才能繼續下一步，接受邀請。

五、方案檢查：細節是否思考到位？

原型初步設計完成后，先不要急于撰寫prd文檔，盡量多檢查幾遍，避免思考遺漏?？梢詮囊韵聨讉€方面來做檢查：

1. 頁面是否簡潔：太過復雜的設計會讓用戶迷惑，也缺乏美感；應當盡量做到簡潔，但是需要掌握好尺度，不能為了追求簡潔而喪失完整度；
2. 交互是否易于理解：互聯網發展到現在這個階段，不管是web端還是移動端，交互設計已經很成熟，用戶也養成了使用習慣，最好不要創新出很奇怪的交互，尤其是需要用戶猜的交互；
3. 功能與其他模塊是否滿足一致性：做某個需求的時候我們不能只局限于功能本身，也要考慮到整個產品，當前的功能或頁面要與產品整體風格一致，這樣才不會造成突兀的感覺（如果出現菜市場里賣衣服就會讓用戶感覺很奇怪了）；
4. 細節方面的檢查：所有的異常情況是否考慮清楚，該有的判斷或者提示是否都有，原型所涉及的數據是否是真實的比例（真實比例能讓團隊小伙伴更容易理解和接受，也更適合方案評審時講解），文案是否有歧義等等。

六、文檔撰寫：寫起來夠輕松嗎？

以上步驟都完成了，就可以著手prd文檔的撰寫啦。此時我們會發現撰寫prd是很輕松的事，因為我們在前面幾步已經做了充分的思考，這會兒就是把我們思考的結果寫出來而已。如果這一步 做起來還很費勁，那么證明前面幾步并沒有思考清楚，建議返回前序環節繼續思考。

文檔撰寫最重要的是盡量做到詳細，不能馬虎：

1. 無論是業務邏輯的判斷還是交互邏輯的細節都要有明確的表達；
2. 整體結構要做到清晰，主次分明，讓開發、測試同事閱讀起來無障礙；
3. 做好版本管理，有更新之后需要有對應的說明，更新時間、更新原因以及更新內容等。

最后，方案整理完畢，不要忘了定一個本次需求的考核指標，用以檢測功能上線后是否達到業務預期。若未達到，則需要分析原因，并且在后續的迭代中不斷優化調整方案。如此，才能讓我們逐步提高自己方案設計水平，最終實現“方案一直很靠譜”的目標。

本文由 @言歸鄭傳 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議