初級產品經理或許都有這樣的遭遇——由于產品規劃與設計時，覆蓋得不夠全面與嚴謹，導致產品方案錯漏百出。繼而陷入了低落與沮喪，不知道從何入手做出改進。而筆者就針對這一現象，總結出了六點產品設計心得，希望對你有所幫助。

對于一個剛入門的后臺產品經理進行產品設計或者寫PRD的時候，經常會出現覆蓋不夠全面，邏輯前后不一致等問題。

導致在需求評審時成為了眾矢之的——大家不斷發現你的疏漏，在現場對你提出問題，而你又沒有辦法立刻給出解決方案，極度尷尬甚至上升到非工作因素互懟局面。

或者剛上線的功能就出現線上事故，最終復盤下來發現是設計缺陷。

幾次之后，可能對產品的心理打擊非常大，不僅僅是大家甚至自己都開始懷疑自己是否還適合繼續這份工作。

那么產品經理就要在產品設計的時候做到全面和嚴謹，在達到驚艷或者巧妙之前，先讓產品方案可落地。今天總結下自己在產品方案設計的時候的一些心得。

一、主要流程與上下游邏輯貫通

為了保證方案的可行性，需要按照主要流程進行拆分，保證流程可以嚴謹地串聯起來。

以消息推送舉例，從發送、下發、到達、點擊等核心流程，要能夠完整地串聯起來，通過業務觸發系統觸發消息（包含業務ID與業務信息），流轉至消息發送平臺（包含消息流水號與業務ID），下發至通道（消息流水號與通道信息），并且通過連接或客戶端進行消息上報（消息流水號和點擊信息）。

這樣，就完成了消息的下發與轉化流程，并且通過了消息平臺的消息唯一流水號可以全鏈路關聯上起各個環節。

一般來說，系統間的對接都是由產品經理來對接，因此這些信息也有必要同步明確給研發。這樣自己對于系統也有了更深入的了解，研發對產品的好感也會比直接丟給研發一個接口定義文檔好很多。

對于上下游有很好的串聯，也可開拓自己的視野，更好地了解項目或者功能的全貌，擺脫大公司里螺絲釘的窘境。

對于復雜的系統或項目，需要從整體的流程開始設計，逐步細化拆分，以保證流程的通暢。如果在細節設計時發現無法實現或實現方案對整體流程有影響，需要及時反饋，調整整體方案后再次落實。

二、異常情況或缺省值的處理

正常的邏輯按照業務流程可以一步一步遞推出來，符合人們思考邏輯。

但是其實很多線上的問題都是由于異常情況考慮的缺失，而且后果輕則用戶體驗較差，重則導致產生的線上事故。異常情況的校驗，更是考驗產品經理的嚴謹，

比如系統的門戶設計有數據、公告、待辦審批等模塊，但是大部分用戶是沒有審核權限的，那么這個模塊的該怎么處理？是隱藏還是顯示一個“當前暫無審批待辦”的文案提示？

比較嚴重的是線上發布的營銷活動被黑產瘋狂“薅羊毛”，粗心的會按照自己的設想一步一步引導用戶完成業務轉化，然后給予用戶獎勵，并一心期待效果來完成KPI，但忽略了黑產利用了中間各個環節的漏洞繞過了你的業務門檻，直接領取了你的獎勵。

當然，異常情況是窮舉不完的，受物理環境、網絡情況、用戶行為等等許多因素影響，一切的異常情況都要基于用戶當時的場景來思考

三、數據概念

做產品經理要對數據有敏感性，對于線上數據結果的解讀來分析挖掘離不開數據的采集。因此，在產品設計時數據的需求也要同時明確，這也往往是后臺或者功能性產品缺失的能力。

1. 數據的流轉

要明確出來數據是從上游哪個系統過來，是通過什么方式傳遞，會涉及哪些字段，如果有特殊邏輯，是需要取哪些枚舉值，對應什么處理。

對于自己系統產生的數據，是否需要留存記錄？是否需要同步至下游系統或者公司的數據集市。

2. 數據的時效與更新方式

對于數據來說，要明確下數據的時效，是實時更新還是離線更新，是更新記錄還是新增記錄，保留變更記錄。提前說明數據需求，避免上線后出現看不到實時數據和歷史記錄的尷尬局面，但是也不是必須所有場景都需要實時數據，也要從實際需求和大批量數據實時計算的成本中平衡。

3. 數據的量級

數據量級要從業務的角度給一個預估值，以便研發在開發考慮系統的性能問題，是否有高并發的場景，避免出現對業務流量的預估不足導致出現線上服務不可用的情況。

4. 數據的統計與分析

哪些指標是可以來反應效果或監控異常的，口徑定義是什么？在哪里展示？是否需要添加報警機制？這些統計分析問題需要產品經理額外關注，這樣才能知道自己的系統運行情況怎么樣、線上的業務發展的如何。

四、一致性

一致性是指在涉及較為復雜的系統或業務邏輯時，多個環節、多個功能之間在交互文案或產品邏輯是否保持一致。比如，推送的“點擊率”與“打開率”，本身是一個含義，但是在不同的頁面展示的文案不一致，可能讓用戶或研發覺得這是2個不同的指標，產生歧義，需要支付額外的答疑成本。

更嚴重的是產品流程不一致，比如活動定向發布流程，一個入口先選擇人群——配置活動信息——配置權益預算；另一個入口先配置權益預算——配置活動信息——選擇人群。

兩個流程是有差異的，需要結合內部運營流程確定，避免出現多個入口流程不一致，導致運營的混亂。

五、牢記需求使命

在產品設計過程中，一定要牢記需求的使命，我們這么做到底是為了什么？

如果通過論證發現沒有辦法實現你的需求目的，或者是發現有更好的方案可以實現這個目的，那么就需要重新考慮方案，快速協調各個相關方進行討論確認，得到優化方案，避免出現為了做而做。

還有一種情況就是避免過于陷入細節或沉迷于自認為非常巧妙的方案導致自己偏離了這個需求的初衷，付出了很高的成本也沒有很好地達到預期目標。

六、明確差異與變化

這條原則主要適用于已經有一定基礎功能需要優化或拓展的需求，一定要明確差異與變化，強調下改動點和改動的原因與目的。如果你的系統的各種處理邏輯已經非常復雜，那么明確地區分出來改動點，可以降低研發同學的抗拒，也可以測試效率與提高交付的效果。

還有一種情況就是，對于一個現有系統來說已經有了一些邏輯和流程，如果不明確出來的話，大家可能還會按照原來的邏輯開發，導致無法銜接或者交付的內容并不是實際的需求。

當你逐步按照以上的原則來進行產品設計的時候，你就會發現你需要去提前想到很多情況，很多信息，這樣就降低了信息不明確帶來的后期交付質量差的風險。

同時，可以更好地為研發提供確定的信息，研發側對產品的好感也會提升，那么合作起來也會更加順暢。

更重要的是，當你正在做到如此嚴謹的時候，你會發現產品的每一個細節、每一處邏輯你都了如指掌，會有產品和人融合的感覺，這個時候你也可以更好地做宏觀產品規劃。

本文由 @卓別木 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議