数极客首页

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

数极客,拥有16种数据分析模型的新一代用户行为分析平台!

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

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

背景和目标

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

搭建后台系统是业务发展的必然。因为人力资源总是紧缺的,为了提高业务运转效率、节省人效,为市场、运营、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. 功能需求列表

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

2. 活动状态流转

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

3. 用户领券流程

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

4. 字段设计

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

5. 后台编辑界面

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

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

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

创建/编辑活动页面

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

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

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

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

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

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

  • 必填字段未完成,无法进入下一步,防止用户漏掉填写必要信息;
  • 输入信息后及时校验格式、长度,并明示告知业务人员;
  • 最好有即时保存功能,即时保存填写信息;
  • 在信息完善后,可以发布到测试环境预览活动效果;
以瑞幸领券页面为例,分析后台系统从0到1的产品设计过程
以瑞幸领券页面为例,分析后台系统从0到1的产品设计过程
以瑞幸领券页面为例,分析后台系统从0到1的产品设计过程

总结

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

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

 

本文由 @iampm  原创发布,未经作者许可,禁止转载。

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

数极客是新一代用户行为分析与数据智能平台,支持用户数据分析运营数据分析留存分析路径分析漏斗分析用户画像SEM数据分析等16种分析模型的数据分析产品,支持网站统计网站分析APP统计APP分析等分析工具,以及会员营销系统A/B测试工具等数据智能应用,支持SAAS和私有化部署,提升用户留存和转化率,实现数据驱动增长!

发表评论

相关文章