今天简单讨论下一个不管做电商还是做金融还是医疗、教育行业都需要的一个模块，涉及到支付的模块没有不做这个的，那就是优惠券。今天Kevin谈谈自己是怎么做的，案例分析！
优惠券一提到，你首先会想到什么？但切记下面一句话：
优惠券不是优惠卷不是推荐码
一、优惠券的使用场景
谈及优惠券，我们首先使用的场景想到的是支付，那么通过支付就可以衍生很多的版块或功能来进行提供。
【常见的优惠券使用场景】
优惠券既然出现在支付页面在业务逻辑上也是必须的，系统能够“自动匹配”相应的优惠券列表，不需要用户再次点击，绞尽脑汁或者用眼光去看到底那张优惠券用的话性价比最高。
那么对于Kevin的案例来说，这里我们要做的是一款金融类产品的优惠券，其目的是很简单，最终的目的肯定是为了提高转化率，用户能够使用优惠券促进购买下单。
那么我们的页面应该怎么展示？刚刚提及了几个场景，还有一些元素。这里我们综合一下：
发放优惠券——领取优惠券——支付——订单——详情
对，我们的优惠券这个时候既然要匹配相应的详情或订单，那么优惠券就要有分类，其次相应的属性应该很快想到，一张优惠券到底可以用几次？时间多少？名称多少？额度多少？优惠券的使用规则？如何领取优惠券？优惠券如何发放？
上面Kevin提了7个问题，请各位读者认真想想，其实这就是Kevin在设计优惠券的时候所想的问题
其次，首先我们的工作量就是2个，一个是前段展现与业务逻辑一个是后台的逻辑规划。
当然这里优惠券也需要运营方一同完成，上面的其中问题，优惠券的领取规则、使用规则就是需要运营方去提供，针对不同的玩法来完成促进转化。
【腾讯云优惠券展现形式】
当然优惠券的展现形式有很多标准化的，之所以为标准化，就是因为优惠券已经有一套成标准的逻辑和展现形式。
1.前端
【滴滴打车下单列表】
这里Kevin借鉴的滴滴打车的优惠券使下单列表，可以看到优惠券的展现形式非常简洁，可能用户都没有“感觉到”，优惠券就被使用了，对于一些新用户或小白用户，优惠券直接达到不需要用户去担忧如何找到优惠券使用的方法，而是直接可以支付。并且进行一些列表展现，这都是比较简单的方式，那么Kevin这里给出的原型如下
【优惠券列表移动端】
这里Kevin稍微不同的是对优惠券进行了优化，以优惠券图片的形式进行展现，并且增加了优惠券的规则引导。另增加订单的一些信息展示，方便用户能够知道自己购买的东西是否正确，毕进行了放大。
好，说到这里优惠券可能有的朋友就说移动端应该差不多了吧，但其实不然，移动端还需要考虑优惠券的展现形式，形成“闭环”。优惠券的逻辑无非就是：
领取优惠券——使用优惠券——领取优惠券
那么要形成闭环，现在展现的是使用优惠券，如何展现领取优惠券？这里就需要设置一个相应的入口，那就是对没有优惠券的用户进行引导。
【引导领取优惠券】
当然这里只是一方面，更多的需要运营方在活动、外链接上进行。当然作为产品的设计上，我们也需要考虑产品的闭环，形成良好的生态。
接下来就是对于优惠券的列表，刚刚之前说到的优惠券有相当多的属性（时间、分类、额度、条件），那么如何进行展现？这里Kevin的设计如下：
【代金券展现列表】
这个时候就可以看到，闭环的生态重要性。优惠券的列表增加优惠券的使用入口，引导用户使用优惠券最终进行转化率的提升，但要注意的是这里你的场景！场景至关重要，比如你的优惠券可能一张券可以用到多个对象或用户，那么毫无疑问这个时候点击立即使用，用户需要去选择相应的场景，这无非是给用户增加一个选择题，并且开发的难度也大大提高。
因此建议对于像场景简单，比如跳转到相应的单一产品页面、或单一场景的页面，这样可以快速进入下单页面，方便用户进行下单。
2.后台
既然优惠券的前端已经出来了，这个时候后台相应的思路Kevin已经有了一些眉目，那读者呢？你有吗？
好，Kevin继续分享下后台怎么设计的，现在尤其是在产品这一块，后台产品经理是非常吃香的，其难度和业务逻辑的要求都是非常之高，不懂后台产品经理的可以百度一下~
简单的思考逻辑就是：
【后台逻辑思考】
那么这里我们首先要考虑我们的用户，对于优惠券我们的用户有运营人员、使用者、白名单（可能是公司内部员工或老板等）。
场景，也就是我们优惠券的逻辑，发放优惠券、领取优惠券、优惠券过期、优惠券使用、优惠券未使用逻辑
字段这里简单的说就是优惠券的字段，优惠券号码、订单号码、额度、条件、优惠券分类等
【其他平台优惠券后台】
因为工作原因，Kevin就不透露优惠券的相应后台情况，但是在网上找了一个类似的优惠券管理平台，经过Kevin的分析，我相信这些元素与字段搭配很快就可以想到。优惠券的名称、类型、期限都与优惠券前端的字段显示紧密相关！
好，是不是感觉优惠券已经完？绝对没有这么简单！
二、 优惠券的匹配算法
算法的存在场景：
1.下单的时候优惠券匹配算法
这里，Kevin首先抛出一个问题，当你下单的时候，我们作为PM来说肯定不希望用户需要花费大量时间去选择并去计算使用哪种优惠券对于当前来说最划算。
这个时候就有两种情况：
第一种情况：优惠券有通用券和相应产品优惠券，那么这个时候用户购买的A产品，但先有通用券和A产品优惠券，额度相同，那么优先使用哪一个？
第二种情况：就是额度不同，当前的订单额度为100，但是优惠券有一张150，另外一张 100另外一张80，又该怎么匹配？
为此，Kevin借鉴的是滴滴打车的算法，自动匹配额度最高、同类优惠券的优惠券，但当优惠券的额度大于支付额度弹出提醒框，确认是否使用。
2.优惠券的动态与静态算法
优惠券我们一般收到的都是有效期，那么如果我们的优惠券需要在一定条件下才能失效，不仅仅是时间，有可能是用户需要某种条件 （新用户、非代理商）等情况进行判断，这个时候我们需要考虑动态优惠券。
可以指定优惠券的使用情况，当然这个也需要运营方提出来。根据需求来对前端和后台的设计，因为新的条件需求涉及一些字段，那么对后台也是需要考虑的，考虑资源分配是优先，以免程序员罢工！
好，今天的案例分享完毕，有一点长，但是希望能够为带来一些帮助。
这一期间完成3篇关于APP设计技巧的总结，大家有兴趣可以看看。后续Kevin会多分享一下自己的工作案例来谈谈产品的成长。
2017年，让我们继续前进！
分享干货我们是认真的，更多干货尽在爱盈利！
