ps：此代金券系统的规划是建立在SDK的产品上
一、代金券需求
近期，公司的游戏产品需要做折扣系统，目的提高付费率。简单来说就是玩家购买游戏商品获得一定的折扣。
二、关于折扣形式
这里折扣形式可以有：
- 直接在产品进行打折；
- 发放活动券；
- 提供充值返利；
- 代币等。
1.直接在产品进行折扣处理
这种方法最为简单，无论是技术实现还是产品角度都是最方便的，但是用户体验感也是最不好的。用户很直观看到有打折，打折仅仅打折并没有拿到实际的东西，用户得不到真实的感知质量，这就是用户感知性；
2.发放活动券形式
这种是我们目前采用的一种方法。考虑到满足用户的感知性另外活动券还能够完善游戏产品的折扣体系，为以后其他的游戏产品打算做折扣活动的时候埋下基础。
3.充值返利
我们对于这种返利通常会面向大R用户做的线下返利。简单来说就是买赠活动，金钱上并没有少，反而赠送一些有价值的产品。但是并不是每一个用户都会需要，同样这种形式无法满足普遍大众用户的需求。
4.代币
所谓代币就是和QB同一个道理。这种情况比较复杂，针对公司目前支付体系以及游戏产品的充值体系，同样排除这种做法。如果条件允许，还要考虑代币和游戏币之间的权重。
三、代金券需求
1.代金券需求分析
在上面折扣形式中，我们经过一轮分析后决定采用活动券作为折扣活动的一种形式。我们将采用代金券这种券类进行设计。（折扣券分优惠券，代金券，满减券。大同小异，效果都一样）
所以有如下代金券的需求分析：
- 角色：玩家
- 场景：游戏内购买商品
- 路径：玩家购买商品后选择相应的代金券进行支付
（代金券属性分析）
- 代金券名称：根据不同的活动或者产品名称自定义，或者仅作为后台生成代金券的一种记录手段
- 来源：代金券是通过何种手段发放到玩家手里。线上线下？兑换码？后台领取？
- 价值：代金券的抵扣金额数
- 使用范围：即代金券只能在特定的产品或者渠道上使用
- 有效时间：顾名思义
- 发放规则：这里指玩家能够自动分配或者手动领取。而状态表示代金券的领取状态。
- 使用规则：指的是满足一定的条件才能够生效。而状态表示代金券的使用情况，这里说明下
- 可用：指的代金券可用
- 已绑定：指的是代金券与订单号绑定（已绑定状态还可分订单的状态进行再区分：玩家未付款，玩家超时未付款）
- 已使用：代金券已经使用，订单号已完成
- 已失效：指时间过期
8.权重：每个代金券只能绑定一个交易订单号；每个代金券只能使用一次
（代金券功能需求规划）
在画脑图之前先YY下代金券该有的功能需求，包含前后端。这里不考虑数据库之间的交互模块。将所有满足代金券功能需求的模块画进去后，再进一步分析出哪些是必要的，不必要的，哪些是MVP的功能。
当然，你会遇到以下的问题。然后需要解决。
- 玩家点击代金券，无法领取
- 玩家使用代金券后超时未付款，下一步如何处理
- 玩家在哪里领取代金券
- 玩家在哪个地方选择代金券
- 代金券重复领取了咋整
- 代金券数量不够
- 代金券怎么设置生效时间，上架时间，发布时间
……
TIP：所有有可能出现的问题，都必须进行穷举。不断穷举会不断发现新问题，产品功能的完善也就更进一步。这里的穷举不分前后端，是整体的穷举。包括不同的角色在使用该功能时会产生什么样的问题，会遇到什么困难，需要如何解决。
2.代金券后台功能规划
代金券系统后台功能主要4大功能模块：创建模块，搜索模块，状态透视表以及数据分析。
1.创建模块是第一步，这里需要考虑到前端展示。
让用户能够更直观的领取和使用代金券。创建模块等于赋予代金券属性，上面提及的代金券属性分析中都必须从这里创建。另外这里还需要考虑代金券的上架时间，明确发行代金券的操作人员，以及设立一个数量预警功能。
2.搜索模块：根据不同维度在代金券系统中搜索想要获取的信息
3.状态透视表：后台操作者想要看到目前代金券的一个使用情况就通过数据表进行表达。
数据表应该包含的最基本的是该代金券目前的使用情况，期限，数量以及可操作的功能
4.数据分析：数据分析是作为运营的重要指标，该批代金券是否对产品带来收益或者该代金券在本次活动是否有效果。
都可以通过分析代金券的使用情况，分析代金券过期未使用或者绑定未使用等用户行为，对后期做进一步的用户指导。
（创建代金券模块，相关字段原型图）
四、前端规划
代金券前端规划
前端规主要考虑用户体验那么就需要考虑下面几个问题：
- 代金券如何出现？
- 如何让用户去认识代金券？
- 用户从哪里找到代金券？
- 用户怎么使用代金券？
TIP：结合原型分析代金券前端该有的因素，以及用户如何实现使用代金券的操作步骤，尽可能减少用户操作但又要确保操作顺畅。接着需要揣摩你设计的每一个页面之间的跳转逻辑，穷举一切可能出现的操作，进一步完善产品功能。
（前端界面“代金券中心”原型）
基于该代金券系统是用在SDK产品上，前端的设计自然要考虑到产品的特性进行设计。与移动互联网大体上也是没什么区别，该有的功能都有，只是前端展示不同。
TIP：领券失败会有什么情况。网络原因？代金券不足？已下架还在展示？已删除还在展示？……我的代金券中，代金券无法使用？使用无效？……等情况都需要考虑分析。
最后将UI设计稿交付给设计师。如果没有UED或者UX只能自己进行布局，再交由UI部门进行切图设计。再讲切好的PNG交给开发人员。然后跟进开发，在开发中解决开发们对文档的疑惑。
TIP：点击一个按钮如何跳转？会产生什么效果？触发某事件会提示什么？如何提示？等等
结语
市场分析和竞品调研这里就没有做过多的记录。因为产品是SDK产品，对于技术层的要求和了解自然要多。对于接口的定义，数据库字段等等这里就不一一说明，说到底还是要多和开发交流，多看书，多在网上看别人分享的东西，在自己总结分享出来。
写这篇文章的目的是分享下自己在规划SDK代金券系统时候一个大概的思路，同时让自己知道做了什么如何去做，也在各位大牛们身上收获不少，自然希望能够帮助到其他人。当然可能写这篇文章会有部分逻辑有问题，欢迎指正一起学习。
（数据库的交互整体结构图）