產品設計之抽象思維（下）

前陣子，一直想寫需求分析的文章，就是平時收集到的小場景業務的那種。這種需求最多，也瑣碎。正好抽象思維在需求分析應用得的多，就結合一起講了。

看個例子。

流程不複雜，路徑清晰。按照一般的方法來做需求分析，先一步步分解業務操作，理清主幹，再畫出流程圖。

上面的流程儘可能照顧了每一個業務細節，這也符合完整流程設計要求，看起來讓人放心，沒有遺漏。現在要隱藏業務細節，僅保留關鍵業務對象信息，將上面的流程簡化成下面的模型：

這個流程模型看上起來粗糙，沒有安全感，不能幫助正常的流程梳理。實際，上面的流程圖並不是對第一次的隨意簡化，而是作了刻意處理：

1. 隱藏業務操作細節，保留業務對象。比如登錄網站，準備結算。
2. 將提取的業務對象抽象化。比如把優惠券抽象為卡券。

同上個流程相比，這個模型簡單，不能直接輔助產品人做流程設計，但給了產品設計者絕佳視角。因為只有關鍵的業務對象和業務操作，我們可以把注意力放在產品結構上，來簡化流程設計。

上面模型里，有4個清晰的業務對象：用戶，卡券，商品，賣場（網站）。這個流程圖反映的是不同業務對象之間的事件流轉，正是因為不同的對象之間的業務關聯操作形成了事件流，然後就有了流程。想像下面場景，一個叫小明的顧客走進了賣場，進門時領了優惠券，然後使用了優惠券買到了個想要的東西。在這一刻，小明是個具體的普通顧客角色，但來賣場買東西不一定都普通顧客，還有大買家。設計角色的時候自然要考慮這種情況，跳出具體對象。

先以用戶對象為例分析，上述兩種不同角色的屬性和業務操作不一樣，普通顧客只會發生一般性購買業務，價格是固定的。而大買家是批量採購，他會希望以優惠的價格購買某一商品，另外要享受企業級的售後服務。基於這兩種角色來抽象設計業務對象時，要模糊兩者之間差異細節，讓這個對象具有更強適用性，既能代表小明那樣的普通客戶群，也能代表大買家的客戶群。

對優惠券來說是一樣。在上面的流程里，優惠券被抽象為卡券。為什麼啊，現在是一張明確的滿100-10的優惠券，但以後有活動推廣需要，還會做2折折扣券，代金券等等。但系統不可能為每一種券都重新設計一次程序。就像富士康，它的生產線，肯定不會是只能加工生產iPhone外殼，而生產不了其它電子設備外殼。不然的話，你需要為一種外殼做特定的生產設備，顯然是巨大的浪費。所以在做產品時，設計好合適的業務對象，能節省成本。出於產品結構設計考慮，你還需要將這些需求告訴研發團隊，不然等到後期需要快速迭代時，你可能會被告知『你以為直接拿過來就可以我復用啊，前期也沒需求說要考慮這些東西』。

再複雜的業務流程，分離業務對象之後，再根據事件把業務對象連接起來，業務操作作按業務對象作好相應的歸屬，整個流程看起來就清晰得多。不是像剛入行做流程設計，僅僅把實際操作步驟以流程的形式畫出來，業務操作與業務對象混在一起，沒有做任何的解構和分享，業務流程圖看起來跟實際操作流程圖好像沒有任何區別。

這樣設計的好處是，前期，產品可以做得足夠簡單，也能滿足用戶需求。後期呢，產品保持足夠穩定性，還能適應產品快速迭代需要。

2B的產品工作中，一般接到的需求和業務場景都是明確的，需求方甚至會說，我需要你如何如何做，來幫我達到怎樣的目的。我的做法是：

1. 從業務流程出發，提取主要業務對象，再對其進行抽象化。
2. 將抽象化的業務對象代入到產品結構中。
3. 然後再從業務對象出發，看業務對象的變化在系統中會引起哪些影響，需要考慮哪些內容。
4. 將業務對象重新代入業務流程中，將流程轉化為不同業務對象之間的數值傳遞。

知乎上，看有人說抽象是不斷去除不重要的東西，提取本質，去偽存真的過程。這個觀點，我不認同。抽象化是為了獲取主幹信息，降低複雜度。抽象過程好比爬梯子，一端指向抽象化，另一端指向具象化，我們總是需要在梯子反覆地爬上爬下，就像PS畫圖，有時要縮小，俯瞰全貌看看整體效果是不是在控制之中。有時要放大，深入局部看細節有沒有畫到位。幫我們實現：站在高處，把控和規劃好產品的發展。落在實處，能夠設計易用的功能和優秀的交互體驗。

推薦閱讀：