一個好的產品經理，要有同理心，不僅要在用戶的角度，還要在設計的角度，開發的角度，運營的角度，還有老板的角度去思考。

我們都是善于望文生義的，再加上市場上大多數產品書籍和網絡上泛濫的產品文章的誘導，他們不是偏于宏觀的方法論就是偏于前端的UI和UE，導致入門者對產品經理這個職位是有誤解的，我也是從誤解走過來的。

前端好比衣服，而后端就如身體構造，衣服是有裝飾作用的，很容易因光鮮外表遮掩了更為重要的后端。

如果非要用一個數據去量化前端和后端相在產品設計中的比重，我傾向于用自己鐘情的二八定律去衡量。后端設計占80%，前端只有20%，接下來我將從前端和后端兩個維度來總結：

前端

原型?

相信大多數產品童鞋入坑都是從原型設計開始的，記得在一個產品群中看到一位童鞋說：當年花了5個小時研究了下Axure，然后就踏上了產品的不歸路。在我看來，原型是產品設計的載體而已，初學者往往會糾結于應該學哪種原型設計工具，如何通過原型工具設計包含更多交互效果的高保真原型。就算包含了90%的交互效果，原型終究只是個原型而已，或許你只是博取了自己的開心而已。

看過不少產品大牛的PRD文檔，發現他們更多的都是采用線框圖+注釋的形式。需要花十多分鐘才能做出來的交互效果分明一句話就說清楚了，而有些邏輯是原型表達不出來的。有一句話是這樣說的，任何最優秀的設計它在形式上一定是最簡單的，我想需求文檔也應該是這樣的。

最初寫需求文檔的時候花了大量的精力在優化原型圖，結果每次都被UI吐槽。后來才意識到，原型是給別人看的，原型只是一種傳遞需求的載體，我們不必拘泥于工具的使用。如果手繪就可以表達你的需求，何不去繁就簡呢。

產品規范?

雖然產品規范更多是UI和UE所關心的事，但是往往小公司是不沒有UE的，這就需要產品經理肩負交互設計的任務。

一個產品大牛曾給我講過，國內的產品大多是不講求產品規范的，只有大廠才會分別做IOS和Android端的產品區分。國內往往大多數產品兼具IOS和Android的設計規范，看過IOS和Android規范文檔的產品童鞋都會發現IOS和Android還是有很大差別的，今天暫不做詳細的總結。

頁面流程?

頁面流程是在用戶視角。是讓用戶更快的抵達自己的目的地，比如產品的核心功能。還是延長用戶的操作路徑，比如銀行卡的解綁，產品設計時會故意延長此功能的操作路徑，從而降低用戶的解綁率。

我想重點說說反饋頁面，因為這個頁面往往很容易被忽視，在產品交互中任何重要的事件都應該有相應的反饋，比如支付成功這個事件，通過一個頁面展示給用戶心理預期的反饋。需要注意一點就是，有成功的反饋就應該有失敗的反饋。

后端

業務流程?

業務流程是在技術視角。產品經理這個詞多少有點蠱惑人，據說互聯網類書籍中賣的最好的就是產品經理相關書了。我覺得叫業務經理更合適，產品應該是業務來驅動的，需求是通過業務流程的設計來解決的。而流程的設計絕對不是毫無根據的畫出來的，不僅要考慮到實際的應用場景還要考據技術實現的可行性。

• 自助點餐的流程設計
• 電商的退貨流程設計
• 醫院自主掛號流程設計
• 共享單車的使用流程的設計

規則?

相對于業務流程，如果業務流程是線的話，那么規則就是連接流程的節點。從某種程度上講，產品設計的如何，得看規則設計的怎么樣。從技術上層面上來看，規則就要用算法來實現了，算法是技術的一道分水嶺，不懂算法的程序猿不是一條好產品狗。

• 各種編碼的設計：身份證、銀行卡號、訂單編號
• 螞蟻信用等相關征信體系規則的設計
• 滴滴打車的的派單規則
• 訂單自動確認收貨的時間

異常邏輯?

異常流程遠多于正常流程，核心的業務往往只有一個，而錯誤的操作往往是多種多樣的。在設計產品的時候就應該站在測試的角度，一步到位，也是為了避免到時候被測試屌。所以，在一開始的時候就要考慮到各種異常情況，做一個邏輯嚴謹的產品經理。

• 正在生效的規則被刪除了怎么處理
• 微信掃自己的二維碼怎么處理
• 支付寶給自己轉賬怎么處理
• 上級用戶添加下級為邀請人怎么破

一個好的產品經理，要有同理心，不僅要在用戶的角度，還要在設計的角度，開發的角度，運營的角度，還有老板的角度去思考。

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

題圖來自unsplash，基于CC0協議