如何設計移動端H5產品優惠券（上）

優惠券--逛過淘寶、京東的小夥伴們，對它都不會陌生吧？不就是一張一張可以領來抵扣現金的券嗎，很簡單的啦~，確實挺簡單的，但是做起來並一定如想象的那樣。

假設你現在是一個移動端（H5產品，使用H5描述不準確，但是隻要大家明白即可）產品經理，現在要你設計一個優惠券的功能，你會怎麼做？ 前臺應該如何互動才能符合使用者的使用習慣？應該如何展示才更酷炫？後臺如何操作才能最大程度上方便運營管理？如何幫助運營評估優惠券的實際效果？ 

下面本人將以自己設計優惠券的經歷，帶大家一窺優惠券需求是如何落地的。當然，很多產品小夥伴應該都有此經驗，那麼不妨和自己設計思路進行對比、取長補短，所以對於這樣的你，這篇文章僅作拋磚引玉之用；對於沒有相關經歷的你，可以作為參考借鑑。

如果你沒有時間看完此文，也可僅看下面的思維導圖，本文將以它為架構進行展開：

優惠券產品需求結構

產品汪和程式猿這對上輩子的冤家，從來都不缺互懟的話題。有一句話說的好：“產品汪跑偏了？因為他一直在畫高保真原型啊！” 

能畫得一手漂亮的原型這應該是件值得表揚的事情，但是如果產品經理一開始想的不是產品架構、業務邏輯、實現可行性，而是馬上動手畫高保證原型的話，那真的會被屌，因為你沒有從產品整體去思考，決定你只見樹木不見森林。

也就是說，設計需求第一步，我們應該從整體上思考該產品需求包含哪些部分。設計產品包含哪些部分時，應該符合MECE原則，即：“相互獨立、完全窮盡” 原則，對於優惠券來說：建立->投放->領取->使用->統計，按照優惠券的產生到結束的時間順序設計應該是最好的選擇，當然也可以有其他方式，歡迎大家提出。那麼根據這個架構，我們就知道整個優惠券需求設計時，需要做哪些工作，然後針對每個部分各個擊破。大家注意到思維導圖上沒有統計部分，因為統計功能我把它設計到專門的統計模組裡，所以在此不做詳細討論。

一、建立優惠券

如何建立一個優惠券？

首先想到的應該是：這是後臺的功能，後臺又是通過資料庫支撐的，資料庫又是一個個欄位組成的，所以我們就需要知道優惠券具備哪些欄位（屬性）？當我們不知道有哪些的時候，但是已經有現成可以參考的產品，切記不要自己造輪子，下面是幾個平臺的優惠券：

優惠券1

優惠券2

粗看上面兩個圖，我們就可以知道，一個優惠券它應該具備的屬性：名稱、面值、門檻、有效期、適用的商品等。因為職業習慣的原因，比較忌諱諸如：等、可能、也許、大概 這些字眼，特別是在需求文件裡出現的話是不可忍的，你下意識的使用這些字眼就暴露了你的不清楚、不明白、不瞭解，這些對於程式猿、測試來講就是拿來懟你的不二法則。上面提到的屬性（欄位）就是優惠券的全部了嗎？不然。。。

我應該怎麼分析它到底需要哪些屬性？

我們分析問題的時候有很多方法可以借鑑，比如5W1H、SWOT、波士頓矩陣和馬洛斯需求層次理論都是我們可以用來分析問題的工具，它們可以幫助你全面的分析和解決問題，只是我們需要找到對應的方法。

以5W1H來分析優惠券到底需要哪些屬性

why：為什麼用優惠券？- 運營需要

what：優惠券是什麼？- 用來促進使用者消費的代金券

where：在什麼地方用到？- 根據運營目的，可以針對商品可以使用該優惠券即優惠券的商品屬性

when：什麼時候可以用？ 即：優惠券的有效期屬性

who：誰可以用？即優惠券的使用者屬性（可以是，新使用者、老使用者、不同積分等級使用者，根據需求方而定）

how：怎麼用？用於抵扣現金，既然使用者可以用來抵扣現金，那麼就一定有面額（面值）和使用門檻，即金額屬性；使用者使用的時候能用/領多少？即數量屬性

所以根據此分析結果我們就可以得出思維導圖中的第一部分“建立”優惠券的結構，一個優惠券就應該至少具備：商品屬性、有效期屬性、使用者屬性、金額屬性和數量屬性。如下圖：

優惠券屬性

那麼這就萬事大吉了嗎？只能說完成了一半，為什麼這麼說呢？

以商品作為一個限制屬性，在使用的時候方式會有多種，比如：可以按照商品分類、商品品牌這種集合的方式進行使用，所以在設計商品屬性時，就需要考慮平臺支援哪些商品的集合。

以有效期作為一個限制屬性，在設計的時候大多數人很容易只考慮一種情況，即：從什麼時候開始到什麼時候結束，作為一個邏輯嚴密的產品汪，我們在設計任何一個欄位時都應該思考有沒有其他方式，上面這樣設計的時間段是固定的，那有沒有可以活動的時間段呢？當然有，我們只固定時間長度不就好了，至於什麼時候結束，根據使用者領取時間而定。同時，作為一個時間屬性，那它必然存在相應狀態：未開始、進行中和已過期，也就意味著，在設計優惠券時必須考慮這三種狀態，同時狀態又和操作相關聯，即：什麼狀態下可以做什麼操作（領取），領取的前置條件是什麼（需要判斷是否滿足條件）、領取的後置條件是什麼（需要給出何種反饋）

以使用者作為一個限制屬性，它和商品屬性有類似之處，我們可以將使用者根據不同規則分類到一起，比如新使用者、老使用者、根據積分規則劃分等級的使用者，我們實現了這些，就可以幫助運營喵任意使用了。

金額屬性：面值是肯定的，它作為一個限制屬性，我們需要限制門檻。

數量屬性：以數量作為限制屬性，需要限制一個使用者可以領多少張、全部使用者總共可以領多少張（發行張數）、一個訂單可以使用多少張。

所以當我們思考清楚上述問題之後，我們就可以羅列出所有優惠券屬性：

優惠券屬性

我們要這個東西幹嘛？很簡單，對於你來講，你可以拿著它開始設計產品原型了；後臺的攻城獅們需要拿著這個設計資料表結構了。

好了，我們還要做一件事，那就是對所有這些屬性進行分類：

基本屬性：優惠券名稱、優惠券面值、發行張數和優惠券說明。

限制屬性：有效期（分為兩種）限制、商品限制（商品、分類、品牌）、金額限制（可使用門檻）、數量限制（每個使用者可領取張數）、使用者限制（新、老、等級劃分使用者）

這時候，你應該會問，為什麼要分成兩個屬性呢？

我會說我無法回答這個問題，所以只能直接跳過（歡迎大神來解釋）

建立階段最重要的一部分：這時候你需要決定將基本屬性和限制屬性都集中在優惠券上，還是分開（請花5分鐘思考將基本屬性和限制屬性分開和合並在一起各自優缺點）。

我想很多人會選擇合併在一起，因為根本沒有考慮過這個問題嘛...

第一種，所有屬性都賦予優惠券

優點：操作方便，一個蘿蔔一個坑、一次性完成建立步驟

缺點：用句通俗的話說，優惠券被做死了

場景：這個優惠券就類似於很多店鋪發的代金券，在你不注意的角落寫滿了各種限制條件

第二種，優惠券僅建立基本屬性，限制屬性在活動內定義

優點：資料模組化、可擴充套件性強，將基本屬性和限制屬性分開，在建立促銷活動的時候定義限制條件，然後在活動中調取相應優惠券即可。多個活動可以呼叫同一優惠券

缺點：需要先建立優惠券、再建立活動、再通過活動關聯優惠券，流程略顯複雜

場景：這個優惠券，類似於鈔票，不附加任何限制條件。

這兩種方式，無所謂好壞，因為都能實現最終需求。區別在於一個使用者操作簡便（產品思維），另一個可擴充套件性強（程式猿思維）。綜合權衡需求方和可擴充套件性兩方面，我最終選擇的是第一種方案（具體原因不做詳述，有興趣可以私聊）

好了，產品汪思考到這裡，優惠券建立的工作就基本完成了，這時候才應該是你著手畫原型的時候（嚴格來講這時候還不是，但是限於文章篇幅原因，以每個階段為終點）。有了上面這些分析資料，畫原型是不是感覺輕鬆了很多，因為你不需要邊畫邊思考有沒有遺漏的，有沒有思考不完全的。

根據上述分析設計原型：

優惠券新增頁面

優惠券列表頁面

以上是優惠券的建立過程產品分析思路，下週日將重點闡述後續部分的投放、領取和使用部分設計過程。有興趣的小夥伴歡迎持續關注。