編輯導語：微信卡包是幫助用戶管理虛拟卡券，可以聚合用戶傳統實物錢包裡存在的優惠券、電影票、會員卡、登機牌等信息的卡包。本文作者介紹了微信卡包的設計理念，并且對優惠券産品的設計思路進行了分析。

昨天阿強送了我一張購車的優惠券，甚是勾起我要買車的欲望。一個純鋼的男子漢，沒有一輛像樣的汽車，就像老孫少了金箍棒一樣，談何雄起！此刻，望着這張優惠券，腦子裡面想到的竟然不是飛馳人生，卻勾起了我對年少頭發飄逸時候做的那套優惠券産品的冥想…

一、優惠券的回憶

那是2016年的第一場雪，稍微比以往時候來的晚一些。公司産品疊代方向需要轉戰至微信卡包，那個年度最火的新産品，導火線是公司利用微信卡包生産的全網第一張電子診療卡。

那時，大家都要相信微信平台的巨大流量帶來的紅利，也就是要相信，微信卡包将可能會是下個風口吧！那麼我要做的，在這張卡片的理念基礎上，去建立整個優惠券的産品體系。

1. 項目慣性思維

既然要結合微信卡券設計産品，首先，就是要做微信平台開放API能力的調研，理解平台産品的設計邏輯。

從文檔中輕松的理解到其卡包的設計邏輯：

主流程：創建——投放——領取——核銷。

當然，創建優惠券，并非是一張實際的優惠券，而是一個優惠券的模闆，待用戶領取後，根據當前優惠券模闆設置好的參數，再生成一張具體的券——一張如同在店鋪門口小姐姐給你發的那個券，可以打印出來的券！

創建的渠道，除了可以通過微信平台自己的後台進行創建，還可以開放式的，允許第三方系統通過API接口進行創建，考慮到第三方系統本身可能已經存在優惠券的闆塊，API還要允許第三方系統自定義券碼（會不會有人不知道券碼是個什麼東西哇？）。

投放渠道任意，隻要觸達用戶即可。如微信公衆号消息、短信、第三方系統的APP等，提供給用戶去領取。但是有個問題，這裡的領取要考慮到添加到微信卡包，所以領取渠道有所受限，因此要放投放渠道的鍊接放到微信體系裡面去。

領取，點擊——添加到卡包。

核銷的話，也是根據不同場景的需求，設定卡券的使用場景，如線下掃碼核銷、商城支付時，選擇優惠券核銷等等。

2. 我設計的産品解決方案

我這樣設計了我們系統的優惠券闆塊：

後台創建優惠券時，完全對接微信卡包開方的API，從創建、投放、核銷、管理全方位接洽。我家後台亦可管理我們的優惠券，且做到優惠券和微信上的優惠券實時同步。

3. 失敗場景舉例

後來支付寶也出了卡包，我才醒悟過來，我的上面設計的産品被微信綁架了。或者說，我的産品就是微信卡包的一個弟弟，還是親生的那種，還不能夠再契給支付寶做契弟。

二、實景操作

1. 想起了來自店長老阿姨傳授的經驗

那天老闆專門給我找了個老阿姨，給我介紹他們店裡面做優惠券活動的方式：

1. 做好活動預算，預計投入多少錢做優惠券，和财務報備；
2. 設計好優惠券的形态：10元、50元、100元等；
3. 定好每個級别的優惠券要派多少張，且每張定好其唯一的優惠券編碼（這個就是券碼），且錄入系統中；
4. 找UI小妹妹設計個樣闆，打印出紙張；
5. 讓店鋪的小姐姐去門口派發給路人或者在收銀台顧客消費的時候再給用戶發兩張；
6. 做好優惠券核銷記錄，跟蹤整個活動數據；
7. 做好經營報表，給一份給财務同事。

有些步驟因為公司的業務流場景不一樣有所不同，比如我們公司對優惠券的預算就沒有要求，随便運營怎麼操作，最後考核指标按照毛利率和銷量進行考核就好了。

2. 産品抽象性思維

阿強曾經多次和我強調過，如今互聯網看到的基本上所有産品，其實都是以前實物場景的複制。

我仿佛大徹大悟過！的确，在互聯網盛行之前，這個實景的業務都進行了多久了！比如說商城購物，就是超市的購物流，你看看那個購物車！比如美團的外賣，從原來是店裡的外賣仔延伸到共享外賣仔！等等……

所以一款産品，不應該停留在構思其功能上的表現形式，從其本身的實景業務從出發，理解其操作流，更加便于我們進行互聯網的産品化！

回過頭來看微信的卡包。我想起來我的錢包，除了錢，什麼銀行卡、網吧上網卡（你和我一個年代的話，你也有）、某某會所會員卡，還有剛剛老阿姨店裡送的優惠券，都塞進去了，這個就是卡包的概念。

而這裡每一張塞進卡包裡面的卡，卡上面的唯一标識号，就是制卡商系統中唯一的識别号。比如銀行卡号（當然卡包沒有加入銀行卡類型），對應在銀行系統中的唯一識别号；比如票證裡面的電子社保卡、發票、甚至電子身份證的，也是有其對應的系統的。

于是微信的卡包，我想到的這個模型：

3. 我從實景出發思考設計的優惠券方案

深入思考下，微信平台的卡包和我系統優惠券的關系，結論是，他們家是他們家，我們家是我們家，一定程度上面來講，微信卡包跟我平台毛線關系沒有，所以：

平台自己玩好可以了，從創建、投放、領取、驗收，一條龍搞定。但是老闆講，一定要放到微信卡包裡面去啊，看起來就高大上好多！絕對沒有毛病，我可以讓你放到N多個卡包裡面去，什麼支付寶卡包、微信卡包，都可以：

非必要時，不對接微信卡包。在有用戶需要添加優惠券到微信卡包時，可以在這個時刻進行微信卡包對接初始化，也就是從創建、投放、領取一步到位。

當然，在開始之前，根據微信平台的要求，還需要上傳一些素材的，比如卡券的背景圖片或者圖片之類的。記住，這個時候微信那邊暫時的優惠券券碼，就是我平台上的優惠券ID了。我才不要再把産品寄生蟲到别人家的産品中，畢竟，我需要保證我的産品體系閉環先。

4. 想起了一個更垃圾的優惠券産品

講到這裡，我想再分享一張産品圖：

不要講什麼券碼的，拼音創建的那個優惠券，就是優惠券，這樣有沒有什麼毛病？

那麼就是每個用戶領取的優惠券都是都是一個ID，那麼這個東西對接不到微信的卡包去（他們不支持你給每個用戶的券碼都一樣），每個用戶不可能領取多張券，這個根本就不是優惠券。

就算那麼多那麼，這個産品在一個企業裡面，竟然被用了6年，且沒有疊代更新過！設計的那麼垃圾，他的确很垃圾嗎？

三、最後

搞産品時，結合實際場景出發，把現實的場景抽象到産品中去，這個我把它稱之為抽象性思維。

比如如今的火火熱熱的中台的概念，把這個中台比喻成一個插闆，這個原理會不會有些類似，然後再思考下其工作的原理，再設計下。

為功能做功能的行為，可恥！

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

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部