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

搭建后台系统是企业业务发展的必然，也是提高业务运转效率、节省人效，为市场、运营、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协议。