搭建后台系统是企业业务发展的必然，也是提高业务运转效率、节省人效，为市场、运营、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项事情要切换不同后台 需求求大求全，产品赘余 过于忽视交互和样式，导致业务人员使用时没有确定性，反而限制效率的提升
