本文是我过去两个月工作内容的回顾总结，和1点小经验的输出。
笔者目前就职于1家做儿童机器人产品（嗯，其实就是带屏幕的玩具兼教具）的公司，此前有过两年多的用户端产品经验，后台产品经验为0。
1、起：自己的需求自己做
我们的儿童机器人要上线1套多级架构的课程体系，并配合该体系架构推出1个多级售卖策略；目的是引导用户先购买低价课程商品来试用，然后再去购买上1层级的打包课程商品（家长用户是1波又理性又感性的生物，“理性”在不轻易下手，“感性”在看到成效后很舍得砸钱）。
这类售卖策略会带来1个问题：用户买了某个课程商品，再去购买上1层级的打包课程商品时，要不要做价格扣减？
综合斟酌目标用户的购买路径，并本着对用户友好的原则，扣减是必要的。
那末问题又来了：如何实现这类价格扣减？
方案有2：
- 针对不同用户做价格调剂，这需要商品后台支持根据用户购买行动来灵活调价；
- 商品定价统1，通过赠送优惠券来解决，这需要新做1个优惠券后台。
当时正好另外一个业务部也有优惠券的需求，因而几方大佬拍板做优惠券后台。
问题又又又来了：谁来做？
要知道，当时全部电商后台处于无PM的自运行状态——哪一个业务部提的平台需求，就哪一个业务部的产品经理来做。
就是这么随性。
2、承：后台PM初体验
刚接到这个任务还是蛮兴奋的，1个全能的PM就是要前后端通吃，正好借此机会提升1下我的逻辑思惟能力和对技术的理解。
作为后台PM小白，怎样展开工作呢？
首先，不懂就问，不会就查。
感谢人人都是产品经理的专栏作者们，让我在短时间内对优惠券有了1个全面认识。
（图片来自《优惠券系统细节剖析（1）：关于优惠券分类及对应设计思路》）
固然，尽信书不如无书，世上没有1个优惠券后台是普适的，“抄”也要有选择性、有针对性的“抄”。
结合我对本身业务的理解，和运营同学的需求，梳理出了来自业务真个需求：
- 用户购买定价x元的商品a后，立即赠送他1张面额x元的优惠券，该张优惠券可在用户购买包括商品a的商品b时使用。
- 老版本下购买过定价x元的商品a的用户，在更新到+优惠券功能的新版本后，将取得1张面额x元的优惠券，该张优惠券可在用户购买包括商品a的商品b时使用。
- 其他针对特定用户发放优惠券的需求，比如做活动挑选出的特定用户、下单未支付的用户等。
根据上文中作者提供的优惠券系统5大子模块理论，并结合本身的情况，梳理出了新建优惠券的4大步骤11个属性项，原型图奉上：
作为用户端PM，1向比较关注用户体验，在后台设计中，也尽可能在细节上做到提升用户体验。
比如，将新建优惠券流程拆分成多步骤，便于及时保存操作；优惠券的每条属性都要标注是不是必填，并标注明确的输入要求和注意事项；需要用户谨慎确认操作的弹框要把肯定按钮放在左边等等。
注：后面会准备1篇文章详细说1下优惠券后台的设计，比如优惠券列表页应当展现哪些信息，应当有哪些操作，优惠券有几种状态，每种状态下有哪些可用和禁用操作等，这些都是在开发和测试进程中积攒的宝贵经验，希望能分享给大家。
很快，优惠券后台1.0上线了，但此时用户真个优惠券功能还未上线，没法联调。
此时的优惠券后台就像是1部没拿到龙标的电影，等待，等待。
3、转：从步步舒心到步步惊心
优惠券后台交付开发的时候，我开始做用户真个优惠券功能设计。
在熟练掌握优惠券的各个字段数据来源后，输出的PRD简直赛高：
- 优惠券11个属性，其实不需要全部在用户端展现给用户，只展现用户关心的项。
- 优惠券后台输入项与接口返回数据，和用户端界面展现其实不完全1致。
这些信息都需要尽早提供给UI设计师和用户端开发，穷尽所有案例，不致于到测试阶段才暴露出问题。
本以为交付UI和开发后就能够安枕无忧了，谁知道问题是层见叠出的。
日子就是问题叠着问题，要挺胸抬头去面对嗯，许3多说的。
没想到优惠券后台的改版来得这么快。
1. 配合销售的需求，买机器送课程兑换卡。
解决方案：优惠券后台增加导出券码的操作，码换券，然后用券0元买课。
感谢我们机灵的后台开发老司机，早早埋下了这个接口。不过，从用户体验角度来看，用兑换码直接换课是最好的，但是斟酌到开发周期和既有功能，还是决定采取码换券再买课的策略。
2. 由于用户端上的优惠券界面是放在对应课程里面的，而优惠券后台的优惠券是针对全平台的，这就致使用户真个优惠券界面可能会显示无关优惠券。
解决方案：优惠券后台增加类目管理，用户端开发根据类目id来调取相应优惠券。
因而，优惠券后台2.0紧急开发上线。
4、合：产品大和谐
终究终究，眼看着1切数据都跑通了，1个个BUG被消灭，老母亲留下了激动的泪水。
在之前的工作经历中，更关注用户体验和交互设计，疏忽了接口数据的重要性；现在回想起来，实际上是之前的开发同学默默帮我做了很多工作，感谢他们的体谅和包容。
同时做用户端产品经理和后台产品经理是甚么体验？
是精神分裂的体验：
- 时而代入家长用户，想象他们的购买心理；
- 时而代入运营人员，想象他们在使用后台时会发出的吐槽；
- 时而代入儿童，想象他们的使用路径；
- 时而代入开发，想象遭受数据接口要求异常时的抓狂；
是耳聪目明的体验：
当测试排查BUG时，能明确指出多是哪一个字段出了问题，应当给哪位开发提BUG（嗯，测试同学是新来的）；
是显微镜下看载玻片的体验，是血管显像仪下看血液流通的体验，是在大自然里静听自然之声的体验。
写到这里，突然生出1种感觉：所谓代码，所谓创造，其实1切都是自然——始于自然，归于自然。
咦，我顿悟了？
学习是没有尽头的，这辈子都没有尽头的。
参考文章：
优惠券系统细节剖析（1）：关于优惠券分类及对应设计思路
优惠券系统细节剖析（2）：优惠券后台创建流程设计
作者：英
