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

對于一個剛?cè)腴T的后臺產(chǎn)品經(jīng)理進行產(chǎn)品設(shè)計或者寫PRD的時候，經(jīng)常會出現(xiàn)覆蓋不夠全面，邏輯前后不一致等問題。

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

或者剛上線的功能就出現(xiàn)線上事故，最終復(fù)盤下來發(fā)現(xiàn)是設(shè)計缺陷。

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

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

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

為了保證方案的可行性，需要按照主要流程進行拆分，保證流程可以嚴謹?shù)卮?lián)起來。

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

這樣，就完成了消息的下發(fā)與轉(zhuǎn)化流程，并且通過了消息平臺的消息唯一流水號可以全鏈路關(guān)聯(lián)上起各個環(huán)節(jié)。

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

對于上下游有很好的串聯(lián)，也可開拓自己的視野，更好地了解項目或者功能的全貌，擺脫大公司里螺絲釘?shù)木骄场?/p>

對于復(fù)雜的系統(tǒng)或項目，需要從整體的流程開始設(shè)計，逐步細化拆分，以保證流程的通暢。如果在細節(jié)設(shè)計時發(fā)現(xiàn)無法實現(xiàn)或?qū)崿F(xiàn)方案對整體流程有影響，需要及時反饋，調(diào)整整體方案后再次落實。

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

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

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

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

比較嚴重的是線上發(fā)布的營銷活動被黑產(chǎn)瘋狂“薅羊毛”，粗心的會按照自己的設(shè)想一步一步引導(dǎo)用戶完成業(yè)務(wù)轉(zhuǎn)化，然后給予用戶獎勵，并一心期待效果來完成KPI，但忽略了黑產(chǎn)利用了中間各個環(huán)節(jié)的漏洞繞過了你的業(yè)務(wù)門檻，直接領(lǐng)取了你的獎勵。

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

三、數(shù)據(jù)概念

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

1. 數(shù)據(jù)的流轉(zhuǎn)

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

對于自己系統(tǒng)產(chǎn)生的數(shù)據(jù)，是否需要留存記錄？是否需要同步至下游系統(tǒng)或者公司的數(shù)據(jù)集市。

2. 數(shù)據(jù)的時效與更新方式

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

3. 數(shù)據(jù)的量級

數(shù)據(jù)量級要從業(yè)務(wù)的角度給一個預(yù)估值，以便研發(fā)在開發(fā)考慮系統(tǒng)的性能問題，是否有高并發(fā)的場景，避免出現(xiàn)對業(yè)務(wù)流量的預(yù)估不足導(dǎo)致出現(xiàn)線上服務(wù)不可用的情況。

4. 數(shù)據(jù)的統(tǒng)計與分析

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

四、一致性

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

更嚴重的是產(chǎn)品流程不一致，比如活動定向發(fā)布流程，一個入口先選擇人群——配置活動信息——配置權(quán)益預(yù)算；另一個入口先配置權(quán)益預(yù)算——配置活動信息——選擇人群。

兩個流程是有差異的，需要結(jié)合內(nèi)部運營流程確定，避免出現(xiàn)多個入口流程不一致，導(dǎo)致運營的混亂。

五、牢記需求使命

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

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

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

六、明確差異與變化

這條原則主要適用于已經(jīng)有一定基礎(chǔ)功能需要優(yōu)化或拓展的需求，一定要明確差異與變化，強調(diào)下改動點和改動的原因與目的。如果你的系統(tǒng)的各種處理邏輯已經(jīng)非常復(fù)雜，那么明確地區(qū)分出來改動點，可以降低研發(fā)同學(xué)的抗拒，也可以測試效率與提高交付的效果。

還有一種情況就是，對于一個現(xiàn)有系統(tǒng)來說已經(jīng)有了一些邏輯和流程，如果不明確出來的話，大家可能還會按照原來的邏輯開發(fā)，導(dǎo)致無法銜接或者交付的內(nèi)容并不是實際的需求。

當你逐步按照以上的原則來進行產(chǎn)品設(shè)計的時候，你就會發(fā)現(xiàn)你需要去提前想到很多情況，很多信息，這樣就降低了信息不明確帶來的后期交付質(zhì)量差的風(fēng)險。

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

更重要的是，當你正在做到如此嚴謹?shù)臅r候，你會發(fā)現(xiàn)產(chǎn)品的每一個細節(jié)、每一處邏輯你都了如指掌，會有產(chǎn)品和人融合的感覺，這個時候你也可以更好地做宏觀產(chǎn)品規(guī)劃。

本文由 @卓別木 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議