以瑞幸领券页面为例分析后台系统从到的产品设计过程

　　搭建后台系统是企业业务发展的必然，也是提高业务运转效率、节省人效，为市场、运营、BD等业务人员提供后台工具是必要的解决方案。既然搭建后台系统如此重要，我们该如何建设呢？笔者将举例为我们分析。
　　背景和目标
　　此处的后台系统指的是公司内部员工使用的工具。
　　搭建后台系统是业务发展的必然。因为人力资源总是紧缺的，为了提高业务运转效率、节省人效，为市场、运营、BD等业务人员提供后台工具是必要的解决方案。
　　虽然各类后台系统解决的问题不同，但本质上这些产品的核心功能点在增、删、改、查。
　　产品设计满足的需求有2个大类：
　　固定参数增删改：比如广告位管理系统，通常是对前端内容增、删、改
　　固定形式内容增删改：比如活动页面发布系统，但它的特殊性在于：要做内部工作人员、用户端2套产品设计，因为它既需要被工作人员使用，也要被普通用户使用
　　第一部分：确认需求列表
　　1。锁定目标用户
　　运营管理系统（通常包含活动页面发布系统、PUSH内容、广告位、优惠券、积分商城等管理系统）主要是运营部门的工具；发票工单审核系统很明显是财务部门的专属。
　　不同性质的产品模块目标用户影响后台系统核心功能需求、设计。
　　2。搜集需求
　　内部系统需求搜集的方式推荐访谈、调查问卷：
　　小团队面对面沟通需求反馈最快、效率最高、质量最好
　　大团队业务人员可能人数较多，可以通过设定调查问卷的问题来验证需求有效性、达成需求列表的共识
　　3。确认需求列表
　　作为产品经理，会在工作中收到无数产品设计建议，来自老板、上下游同事、用户。
　　KANO模型可以作为需求列表确认的方法：把需求分为必备型需求、期望型需求、兴奋型需求，在必备型类别中确认消耗时间多、使用频率高的具体需求。
　　以上2步即可帮我们列出亟待解决的需求列表。但是实际工作往往不会这么理想化，正因为后台系统的目标用户是公司内部同事，搜集需求时更有可能遇到的问题：
　　1。我觉得xx功能也需要做上去，对我来说很重要
　　分析：此类问题是典型的提解决方案，而非讲实际需求。
　　解决方案：和提出者确认到底要解决什么场景下的什么问题，而非直接列为需求列表
　　2。希望这些功能都能做上去一起上线
　　分析：此类问题是典型的一切功能都很重要
　　解决方案：产品设计必须权衡投入产出比。在有限的时间和资源中，按照原则开发优先级高的需求。同时产品设计保留扩展性，为后续优化留出位置即可。
　　第二部分：产品设计建议
　　1。用户信息系统通用，用户角色权限清晰
　　通常1个公司需要后台系统化的模块工具不止1个，比如发放优惠券、编辑广告位等；
　　为避免后期不同后台过于散乱、权限管理出现漏洞，在进行后台设计时通常要把用户登录注册信息设计为通用模块；
　　公司人来人往，某些重要模块的编辑发布权限只能某部分人拥有，防止出现混乱的情况；
　　比如超级管理员拥有最高权限：增删改查、编辑角色权限等；
　　2。记录必要日志，重要模块须有审核流程
　　记录日志便于在问题出现后定位问题出现的原因，后台必须记录的日志除了创建、更新时间，也必须记录下每1个操作人的日志。
　　优惠券发放是1个典型例子，因为关系到部门预算等现实的财务结算问题，优惠券的后台设计必须有审核流程。
　　3。程序判定优先于人为判定
　　操作后台需要业务人员编辑操作，人为操作出现问题的概率高于程序，所以尽量把程序可判定的工作交给程序，一来为达到核心目标：降低人力成本，二来降低出错概率。哪些问题适合程序判定呢？我自己的总结是：只要能定义清楚的内容交给程序，这后台产品设计中具象的设计有：
　　判断必填项目是否完善
　　判断填写内容是否超出设定长度、格式是否符合要求
　　4。设计兜底策略
　　如果PUSH消息推送后台编辑的消息有错误，应该有停止发送PUSH的功能；
　　如果发布的前端页面内容有误必须删除，应该有404NOTFOUND页面承接浏览；
　　总之，后台设计中若有这用户端展示的内容，请务必考虑兜底策略，假设不幸有错误消息发出但无法修改的场景下，如何将负面影响、损失降到最低；
　　案例分析：反推一个瑞幸领券活动模板的设计
　　前提：下方内容是个人从工作经验中反推瑞幸该活动模板形成的概况，没有细致到产品需求文档的细节，也不代表真实信息。
　　1。功能需求列表
　　2。活动状态流转
　　3。用户领券流程
　　4。字段设计
　　5。后台编辑界面
　　按照活动状态分类的列表页
　　按活动名称、活动时间、活动状态等查找历史活动页面，查找到对应页面后可进行编辑、审核、上线等操作。
　　创建编辑活动页面
　　根据设计后台系统踩过的坑看，活动系统有2大类交互方式：
　　一类是颗粒化更细的组件系统，把多个常用组件模板化，业务人员可以通过增删改组件来构建不同样式的页面；
　　一类是下方的页面模板系统，适合模式、样式相对固定的活动形式，仅允许编辑整套活动页面部分模块即可；
　　从使用瑞幸领券活动页面经历看，这个页面：背景图、优惠券配置变化多，其他地方变动少，适合用页面模板系统方式实现；
　　这个领券页面的配置信息，分成3大部分：
　　活动基础信息：开始、结束时间，页面url（若不需要设置可随机生成唯一链接）等
　　活动优惠信息、参与用户条件：优惠券到底配置哪个，哪些用户可以参与是活动策略的核心。假设业务需要不同用户领券不同代金券，则需要接入用户标签系统，在不同用户标签系统下配置优惠信息；
　　前端样式：具体到图片、按钮、输入框、文字样式的增删改；
　　结合上方的设计建议，在前端交互方面：
　　必填字段未完成，无法进入下一步，防止用户漏掉填写必要信息；
　　输入信息后及时校验格式、长度，并明示告知业务人员；
　　最好有即时保存功能，即时保存填写信息；
　　在信息完善后，可以发布到测试环境预览活动效果；
　　总结
　　一千家公司可能解决同一个问题的落地方案也不完全一致，但总体思考、设计思路是类似的。如果一开始设计时避开以下误区，可以少走弯路：
　　没有统一规划，后台分散导致业务人员完成1项事情要切换不同后台
　　需求求大求全，产品赘余
　　过于忽视交互和样式，导致业务人员使用时没有确定性，反而限制效率的提升