优惠券--逛过淘宝、京东的小伙伴们，对它都不会陌生吧？不就是一张一张可以领来抵扣现金的券吗，很简单的啦~，确实挺简单的，但是做起来并一定如想象的那样。
假设你现在是一个移动端（H5产品，使用H5描述不准确，但是只要大家明白即可）产品经理，现在要你设计一个优惠券的功能，你会怎么做？ 前台应该如何交互才能符合用户的使用习惯？应该如何展示才更酷炫？后台如何操作才能最大程度上方便运营管理？如何帮助运营评估优惠券的实际效果？
下面本人将以自己设计优惠券的经历，带大家一窥优惠券需求是如何落地的。当然，很多产品小伙伴应该都有此经验，那么不妨和自己设计思路进行对比、取长补短，所以对于这样的你，这篇文章仅作抛砖引玉之用；对于没有相关经历的你，可以作为参考借鉴。
如果你没有时间看完此文，也可仅看下面的思维导图，本文将以它为架构进行展开：
产品汪和程序猿这对上辈子的冤家，从来都不缺互怼的话题。有一句话说的好：“产品汪跑偏了？因为他一直在画高保真原型啊！”
能画得一手漂亮的原型这应该是件值得表扬的事情，但是如果产品经理一开始想的不是产品架构、业务逻辑、实现可行性，而是马上动手画高保证原型的话，那真的会被屌，因为你没有从产品整体去思考，决定你只见树木不见森林。
也就是说，设计需求第一步，我们应该从整体上思考该产品需求包含哪些部分。设计产品包含哪些部分时，应该符合MECE原则，即：“相互独立、完全穷尽” 原则，对于优惠券来说：创建->投放->领取->使用->统计，按照优惠券的产生到结束的时间顺序设计应该是最好的选择，当然也可以有其他方式，欢迎大家提出。那么根据这个架构，我们就知道整个优惠券需求设计时，需要做哪些工作，然后针对每个部分各个击破。大家注意到思维导图上没有统计部分，因为统计功能我把它设计到专门的统计模块里，所以在此不做详细讨论。
一、创建优惠券
如何创建一个优惠券？
首先想到的应该是：这是后台的功能，后台又是通过数据库支撑的，数据库又是一个个字段组成的，所以我们就需要知道优惠券具备哪些字段（属性）？当我们不知道有哪些的时候，但是已经有现成可以参考的产品，切记不要自己造轮子，下面是几个平台的优惠券：
粗看上面两个图，我们就可以知道，一个优惠券它应该具备的属性：名称、面值、门槛、有效期、适用的商品等。因为职业习惯的原因，比较忌讳诸如：等、可能、也许、大概 这些字眼，特别是在需求文档里出现的话是不可忍的，你下意识的使用这些字眼就暴露了你的不清楚、不明白、不了解，这些对于程序猿、测试来讲就是拿来怼你的不二法则。上面提到的属性（字段）就是优惠券的全部了吗？不然。。。
我应该怎么分析它到底需要哪些属性？
我们分析问题的时候有很多方法可以借鉴，比如5W1H、SWOT、波士顿矩阵和马洛斯需求层次理论都是我们可以用来分析问题的工具，它们可以帮助你全面的分析和解决问题，只是我们需要找到对应的方法。
以5W1H来分析优惠券到底需要哪些属性
why：为什么用优惠券？- 运营需要
what：优惠券是什么？- 用来促进用户消费的代金券
where：在什么地方用到？- 根据运营目的，可以针对商品可以使用该优惠券即优惠券的商品属性
when：什么时候可以用？ 即：优惠券的有效期属性
who：谁可以用？即优惠券的用户属性（可以是，新用户、老用户、不同积分等级用户，根据需求方而定）
how：怎么用？用于抵扣现金，既然用户可以用来抵扣现金，那么就一定有面额（面值）和使用门槛，即金额属性；用户使用的时候能用/领多少？即数量属性
所以根据此分析结果我们就可以得出思维导图中的第一部分“创建”优惠券的结构，一个优惠券就应该至少具备：商品属性、有效期属性、用户属性、金额属性和数量属性。如下图：
那么这就万事大吉了吗？只能说完成了一半，为什么这么说呢？
以商品作为一个限制属性，在使用的时候方式会有多种，比如：可以按照商品分类、商品品牌这种集合的方式进行使用，所以在设计商品属性时，就需要考虑平台支持哪些商品的集合。
以有效期作为一个限制属性，在设计的时候大多数人很容易只考虑一种情况，即：从什么时候开始到什么时候结束，作为一个逻辑严密的产品汪，我们在设计任何一个字段时都应该思考有没有其他方式，上面这样设计的时间段是固定的，那有没有可以活动的时间段呢？当然有，我们只固定时间长度不就好了，至于什么时候结束，根据用户领取时间而定。同时，作为一个时间属性，那它必然存在相应状态：未开始、进行中和已过期，也就意味着，在设计优惠券时必须考虑这三种状态，同时状态又和操作相关联，即：什么状态下可以做什么操作（领取），领取的前置条件是什么（需要判断是否满足条件）、领取的后置条件是什么（需要给出何种反馈）
以用户作为一个限制属性，它和商品属性有类似之处，我们可以将用户根据不同规则分类到一起，比如新用户、老用户、根据积分规则划分等级的用户，我们实现了这些，就可以帮助运营喵任意使用了。
金额属性：面值是肯定的，它作为一个限制属性，我们需要限制门槛。
数量属性：以数量作为限制属性，需要限制一个用户可以领多少张、全部用户总共可以领多少张（发行张数）、一个订单可以使用多少张。
所以当我们思考清楚上述问题之后，我们就可以罗列出所有优惠券属性：
我们要这个东西干嘛？很简单，对于你来讲，你可以拿着它开始设计产品原型了；后台的攻城狮们需要拿着这个设计数据表结构了。
好了，我们还要做一件事，那就是对所有这些属性进行分类：
基本属性：优惠券名称、优惠券面值、发行张数和优惠券说明。
限制属性：有效期（分为两种）限制、商品限制（商品、分类、品牌）、金额限制（可使用门槛）、数量限制（每个用户可领取张数）、用户限制（新、老、等级划分用户）
这时候，你应该会问，为什么要分成两个属性呢？
我会说我无法回答这个问题，所以只能直接跳过（欢迎大神来解释）
创建阶段最重要的一部分：这时候你需要决定将基本属性和限制属性都集中在优惠券上，还是分开（请花5分钟思考将基本属性和限制属性分开和合并在一起各自优缺点）。
我想很多人会选择合并在一起，因为根本没有考虑过这个问题嘛...
第一种，所有属性都赋予优惠券
优点：操作方便，一个萝卜一个坑、一次性完成创建步骤
缺点：用句通俗的话说，优惠券被做死了
场景：这个优惠券就类似于很多店铺发的代金券，在你不注意的角落写满了各种限制条件
第二种，优惠券仅建立基本属性，限制属性在活动内定义
优点：数据模块化、可扩展性强，将基本属性和限制属性分开，在创建促销活动的时候定义限制条件，然后在活动中调取相应优惠券即可。多个活动可以调用同一优惠券
缺点：需要先创建优惠券、再创建活动、再通过活动关联优惠券，流程略显复杂
场景：这个优惠券，类似于钞票，不附加任何限制条件。
这两种方式，无所谓好坏，因为都能实现最终需求。区别在于一个用户操作简便（产品思维），另一个可扩展性强（程序猿思维）。综合权衡需求方和可扩展性两方面，我最终选择的是第一种方案（具体原因不做详述，有兴趣可以私聊）
好了，产品汪思考到这里，优惠券创建的工作就基本完成了，这时候才应该是你着手画原型的时候（严格来讲这时候还不是，但是限于文章篇幅原因，以每个阶段为终点）。有了上面这些分析数据，画原型是不是感觉轻松了很多，因为你不需要边画边思考有没有遗漏的，有没有思考不完全的。
根据上述分析设计原型：
优惠券添加页面
优惠券列表页面
以上是优惠券的创建过程产品分析思路，下周日将重点阐述后续部分的投放、领取和使用部分设计过程。有兴趣的小伙伴欢迎持续关注。
