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

4 评论 6342 浏览 105 收藏 11 分钟

搭建后台系统是企业业务发展的必然,也是提高业务运转效率、节省人效,为市场、运营、BD等业务人员提供后台工具是必要的解决方案。既然搭建后台系统如此重要,我们该如何建设呢?笔者将举例为我们分析。

背景和目标

此处的后台系统指的是公司内部员工使用的工具。

搭建后台系统是业务发展的必然。因为人力资源总是紧缺的,为了提高业务运转效率、节省人效,为市场、运营、BD等业务人员提供后台工具是必要的解决方案。

虽然各类后台系统解决的问题不同,但本质上这些产品的核心功能点在增、删、改、查

产品设计满足的需求有2个大类:

  • 固定参数增删改:比如广告位管理系统,通常是对前端内容增、删、改
  • 固定形式内容增删改:比如活动页面发布系统,但它的特殊性在于:要做内部工作人员、用户端2套产品设计,因为它既需要被工作人员使用,也要被普通用户使用

第一部分:确认需求列表

1. 锁定目标用户

运营管理系统(通常包含活动页面发布系统、PUSH内容、广告位、优惠券、积分商城等管理系统)主要是运营部门的工具;发票工单审核系统很明显是财务部门的专属。

不同性质的产品模块目标用户影响后台系统核心功能需求、设计。

2. 搜集需求

内部系统需求搜集的方式推荐访谈、调查问卷:

  • 小团队面对面沟通需求反馈最快、效率最高、质量最好
  • 大团队业务人员可能人数较多,可以通过设定调查问卷的问题来验证需求有效性、达成需求列表的共识

3. 确认需求列表

作为产品经理,会在工作中收到无数产品设计建议,来自老板、上下游同事、用户。

KANO模型可以作为需求列表确认的方法:把需求分为必备型需求、期望型需求、兴奋型需求,在必备型类别中确认消耗时间多、使用频率高的具体需求。

以上2步即可帮我们列出亟待解决的需求列表。但是实际工作往往不会这么理想化,正因为后台系统的目标用户是公司内部同事,搜集需求时更有可能遇到的问题:

1.“我觉得xx功能也需要做上去,对我来说很重要”

  • 分析:此类问题是典型的提解决方案,而非讲实际需求。
  • 解决方案:和提出者确认到底要解决什么场景下的什么问题,而非直接列为需求列表

2. “希望这些功能都能做上去一起上线”

  • 分析:此类问题是典型的“一切功能都很重要”
  • 解决方案:产品设计必须权衡投入产出比。在有限的时间和资源中,按照原则开发优先级高的需求。同时产品设计保留扩展性,为后续优化留出位置即可。

第二部分:产品设计建议

1. 用户信息系统通用,用户角色权限清晰

通常1个公司需要后台系统化的模块/工具不止1个,比如发放优惠券、编辑广告位等;

为避免后期不同后台过于散乱、权限管理出现漏洞,在进行后台设计时通常要把用户登录注册信息设计为通用模块;

公司人来人往,某些重要模块的编辑发布权限只能某部分人拥有,防止出现混乱的情况;

比如超级管理员拥有最高权限:增删改查、编辑角色权限等;

2. 记录必要日志,重要模块须有审核流程

记录日志便于在问题出现后定位问题出现的原因,后台必须记录的日志除了创建、更新时间,也必须记录下每1个操作人的日志。

优惠券发放是1个典型例子,因为关系到部门预算等现实的财务结算问题,优惠券的后台设计必须有审核流程。

3. 程序判定优先于人为判定

操作后台需要业务人员编辑操作,人为操作出现问题的概率高于程序,所以尽量把程序可判定的工作交给程序,一来为达到核心目标:降低人力成本,二来降低出错概率。哪些问题适合程序判定呢?我自己的总结是:只要能定义清楚的内容交给程序,这后台产品设计中具象的设计有:

  • 判断必填项目是否完善
  • 判断填写内容是否超出设定长度、格式是否符合要求

4. 设计兜底策略

如果PUSH消息推送后台编辑的消息有错误,应该有停止发送PUSH的功能;

如果发布的前端页面内容有误必须删除,应该有404 NOTFOUND页面承接浏览;

总之,后台设计中若有这用户端展示的内容,请务必考虑兜底策略,假设不幸有错误消息发出但无法修改的场景下,如何将负面影响、损失降到最低;

案例分析:反推一个瑞幸领券活动模板的设计

前提:下方内容是个人从工作经验中反推瑞幸该活动模板形成的概况,没有细致到产品需求文档的细节,也不代表真实信息。

1. 功能需求列表

2. 活动状态流转

3. 用户领券流程

4. 字段设计

5. 后台编辑界面

按照活动状态分类的列表页

按活动名称、活动时间、活动状态等查找历史活动页面,查找到对应页面后可进行编辑、审核、上线等操作。

创建/编辑活动页面

根据设计后台系统踩过的坑看,活动系统有2大类交互方式:

  • 一类是颗粒化更细的组件系统,把多个常用组件模板化,业务人员可以通过“增删改”组件来构建不同样式的页面;
  • 一类是下方的页面模板系统,适合模式、样式相对固定的活动形式,仅允许编辑整套活动页面部分模块即可;

从使用“瑞幸领券活动页面”经历看,这个页面:背景图、优惠券配置变化多,其他地方变动少,适合用页面模板系统方式实现;

这个领券页面的配置信息,分成3大部分:

  • 活动基础信息:开始、结束时间,页面url(若不需要设置可随机生成唯一链接)等
  • 活动优惠信息、参与用户条件:优惠券到底配置哪个,哪些用户可以参与是活动策略的核心。假设业务需要不同用户领券不同代金券,则需要接入用户标签系统,在不同用户标签系统下配置优惠信息;
  • 前端样式:具体到图片、按钮、输入框、文字样式的增删改;

结合上方的设计建议,在前端交互方面:

  • 必填字段未完成,无法进入下一步,防止用户漏掉填写必要信息;
  • 输入信息后及时校验格式、长度,并明示告知业务人员;
  • 最好有即时保存功能,即时保存填写信息;
  • 在信息完善后,可以发布到测试环境预览活动效果;

总结

一千家公司可能解决同一个问题的落地方案也不完全一致,但总体思考、设计思路是类似的。如果一开始设计时避开以下误区,可以少走“弯路”:

  • 没有统一规划,后台分散导致业务人员完成1项事情要切换不同后台
  • 需求求大求全,产品赘余
  • 过于忽视交互和样式,导致业务人员使用时没有确定性,反而限制效率的提升

 

本文由 @iampm  原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 看完后对优惠券系统后台逻辑有了初步的认识,有个问题想请教下,就是优惠券ID这个字段是用来区分优惠券类型的吗?因为同种类型的优化券,可以有很多个,那每一个券对应的ID与上文提到的优惠券ID有联系吗?

    来自广东 回复
  2. 优秀!学习到了主要思路,有几个问题还需要请教一下:
    1、活动配置活动链接的目的是什么?不是所有活动共用一个页面链接,只是后台生效了哪个活动而已嘛?
    2、优惠券生成时一般是有数量控制的,而活动领取的人数是不确定的,用户领取时该批次优惠券已无可领取数量怎么办?

    来自广东 回复
    1. 第一个问题:不同活动的链接通常是不一样的,比如五一活动、十一活动,肯定从页面URL地址区分开,去不同目录下取不同文件。

      第二个问题:优惠券本身有自己一套规则:生效时间、失效时间、使用门槛、发放数量、单人领取数量,它是个独立的模块。我我这边设计的是:优惠券单独申请后生成一个标识(类似id),填写到领券活动页面的商品id中(看具体业务是否要求有其他类型的商品),这样把领取+奖品关联到一起。

      不知道咱们理解的是不是 一个意思。

      来自北京 回复
    2. 功能上是两个兜底:1、用户进入该领取页面之前判断优惠券活动是否在生效中且是否存在剩余发放数量,是,则成功进入领取页面,否,则进入提示页 2、用户点击领取时,校验条件同上,成功,则发放成功,否,则进入提示页,根据业务定义,可以和上面不一样的提示页 (为了避免用户长时间停留该页面,前端需要去做轮巡掉后端接口,更新页面状态:比如,用户在活动有效期进入该页面迟迟不领情,可能过了几天活动结束了,那么该页面需要自动失效处理更新页面状态,也可以不做这个处理)

      来自上海 回复