后台产品难做、要求高，这是有原因的

　　

后台产品难做、要求高，这是有原因的

　　

　　大家都说后端产品难度大，要求高。这是有原因的。而这个原因会超出我们的认知，一起来看看吧。

　　什么是后台产品

　　后台产品也被我们称为后台管理系统和内部管理系统。简单来说，它是为企业员工开发的办公产品，也是用户使用的App、Web等产品的配套产品。

　　我们也可以根据使用对象将后端产品分为两类。一种是我们使用的产品。事实上，任何产品都需要后端，包括我们的C端产品。另一种是针对客户的产品，多见于B端产品。

　　我们认为后端产品很难。根本原因是做后端产品的人很多。我们经常将后端产品提供给新人设计、实践和学习。

　　背景产品的特殊性让我们可以把它交给新人练习。这种特殊性就在于他的用户身份，因为这是我们自己人用的产品，我们可以对它有最强烈的容忍度。即使他的经验不是那么友好，他也有很多问题，我们也可以通过人工手段协调解决。

　　后端管理系统的大部分用户都是操作学生使用的，产品学生偶尔会用到，后端系统最终还是把学生坑在这两个位置上。这种坑最终会转化为仓位矛盾。

　　但是，在实际项目中，我们往往把后端系统设计得非常简单，最大程度的节省了开发资源。同时，为了节省产品经理的能耗，我们会将系统的设计任务交给新人来完成。

　　原因是后端系统设计对用户来说是好是坏，损失很小，几乎可以忽略不计。这是一款做的好没有人表扬的产品，做的不好也没有人惩罚。

　　在这样的环境下，后端系统的复杂性也会被夸大。毕竟，这是我们制作的第一个产品。毕竟，接触后端产品的朋友远远多于面向用户的产品。

　　事实上，确实有极其复杂的后端产品，其复杂度远远超过面向用户的产品，尤其是涉及算法的后端产品，没有专业的后端产品经理几乎是无法控制的。这样的后端产品很少，也很特别。

　　面向用户的产品也有极其复杂的逻辑。因此，我们不能断定面向用户的产品比后端产品难，也不能一味地断定后端产品比面向用户的产品复杂。这两种类型的产品都很难。等级。

　　现在的环境，对于产品来说，更多的是处于应用创新阶段，高复杂度的产品，其实很少有人接触到，不足以让我们断言背景更复杂，几乎80%的背景产品很简单。

　　这就像三个人变成了一只老虎。人们说背景很复杂。我们也先入为主地认为背景比较困难。再深入一点，难在哪里？很难说一两个。

　　如果你是一个不到2年经验的产品，这个时候需要设计一个后端产品，不用紧张，按需设计即可。您收到的任务具有风险规避因素。这听起来可能不太好，但我们很难将极其复杂的任务交给经验不足的您。这无疑会放大我们的风险。风险是我们可以避免的。

　　如果你是产品的新手，也接触过后台，那就专心研究吧。我特别乐意把后台任务交给新人，因为他比较固定，后台产品变化很少，有迹可循，他不像是面向用户的产品，变化很多，每一个变化都是隐藏的天使和恶魔会对我们造成真正的伤害。

　　当然，最重要的还是这个观点：公司和我们的上级在做任务分配的时候，难免会考虑风险因素，考虑失败或错误的代价是否在我们可以接受的范围内。因此，没有必要有太大的心理压力和负担。

　　背景设计原则

　　大多数后端都会遵守以下四项原则。其实这就是后端的基本设计原则。我把它定义为可视化原理、数据源原理、控制原理和内部设置原理。

　　其中最重要的是前三个原则。

　　可视化原理

　　典型的可视化原理是后端产品的数据统计部分。我们可以将其理解为一种暴露信息的机制。产品在运行过程中，难免会产生某些信息，但这些信息往往是我们看不到的，或者每次查看都需要研发支持，为了方便我们查看，我们将这部分展示出来背景中的内容。

　　可视化原理的典型特征是它只允许在各个维度上查看和查看，而没有更多的操作属性。

　　想一想，在我们接触到的后端产品中，哪些功能属于可视化原理。

　　数据统计、数据详情、用户列表、内容列表几乎都是基于可视化的原理。

　　这部分功能的设计方法只需要我们考虑需要看什么信息，在什么维度看。

　　当我们发起一个活动时，我们需要在后台查看该活动的一些信息，比如报名人数、实际参加人数，甚至时长。当然，我们也可以统计参与者的地域分布，以及性别差异。 ,年龄分布。

　　遵循可视化原理的常用功能，包括我们的多维过滤、排序、导出、数据明细、饼图、柱状图、折线图等，这些功能都符合可视化设计的原则，使用最合适的方法，提高我们查看信息的效率。

　　数据源原理

　　几乎所有的后端系统都会扮演数据源的角色。我们要发起一个活动，放一个新的banner地图，推荐一个文章，在一个面向用户的产品中推荐一个主题，所有这些都需要一个输入信息的地方。在后台，符合数据源原则的部分承担这部分内容。

　　数据源原理的典型特征是加法。除了传统的查看功能外，数据源部分还必须包括新功能。我们可以断言，没有新特性的后端不符合数据源原则。这意味着该产品几乎没有操作能力，操作学生无法通过后台干预产品的内容、风向和活动。

　　对于微信公众号后台管理系统，我们新增的图文素材和新的推送任务是属于数据源设计原则的功能，可以主动将既定信息插入到面向用户的产品中。

　　这部分功能的设计主要是为了配合面向用户的产品。它是一种设计形式。后者需要预留支撑空间，如预留banner位置、预留推荐标签、预留PGC内容规则等。

　　简单来说，数据源原理要求我们在后端具备“产生新内容”的能力。在产品运营过程中，需要具备生成新主题、新活动、新通知的能力。

　　他是与面向用户的产品一起存在的后端设计原则。

　　版本更新通知也是数据源原理的功能设计。当我们更新新版本时，我们需要通知用户更新。这时候，我们需要创建一个新的版本通知。在这个模块中，通知的内容通常是对新版本的简要介绍。设置通知对象后，比如1.x版本和之前的版本，我们还可以设置通知形式，比如强制升级仍然是可取消的升级通知。

　　数据源原理的作用，难点在于参数的选择。我们应该让操作学生在创建新内容时有更多的参数可以选择填写，以满足他的灵活性。毕竟这部分能力是官方给用户发声的能力。

　　来看看公众号新图文都收录哪些参数：

　　

　　

　　

　　试想一下，如果公众号允许我们在创建新的图文素材时添加对小游戏的引用，那么公众号的玩法将会彻底改变。当然，这需要很多面向用户的产品的支持。只是工作。

　　控制原理

　　控制原理是指后台操作者可以修改用户的部分信息。它是一种保护机制，也是一种应急机制。当用户发送不良内容时，我们可以做一些事情，而不仅仅是观看。

　　在保护内容生态的同时，当用户进行某些不可逆转的操作时，我们也需要应急能力为用户修改某些信息。在一些小产品中，甚至可以直接修改用户的账户或金币余额，尤其是一些游戏产品，这是一种更尊重的方式来创建“信任”或“特权账户”。

　　典型的控制原则体现在黑名单、内容屏蔽、内容修改三个功能上。

　　以微信公众号为例。我们可以在公众号后台设置黑名单。那么这些用户将无法再向公众号发送消息或留言。我们也可以删除已发布的文章，这样就不能再查看这个文章了。

　　控制原理的设计理念在于保护和应急机制。一般来说，这两种机制的功能包括屏蔽、黑名单、删除和修改。我们需要明确面向用户的产品中哪些内容需要保护，哪些内容需要建立应急机制。

　　虽然，控制函数是很少使用的函数。其实我们不希望使用这些函数，但是这些函数必须存在。当我们需要使用这些功能时，就意味着出现了异常情况。这时候，这些功能就变得非常必要了。

　　内部设置原则

　　如果说可视化原理的设计对象是我们看不到的信息，数据源原理的设计对象是新内容，控制原理的设计对象是用户和产生的内容由用户，那么内部设置原则的设计对象就是后台系统本身。

　　最常见的内部设置原则是我们的权限系统，与面向用户的产品无关。这部分功能的设计目的只是为了明确操作者的权限范围，同类型的功能还包括操作记录。

　　当然，后台账号系统也是一个内部设置原则。

　　后台账号不能申请注册。这部分帐户的来源通常是由管理员帐户生成的。一方面，在系统设计的时候，有一个固定的超级管理员账号，通常是admin账号。这个账号可以生成其他子账号并赋予不同的权限。

　　企业邮箱就是一个典型案例。当我们加入一家更成熟的公司时，我们会根据我们的姓名或职位 ID 生成一个独立的企业电子邮件帐户。

　　内部设置原则更多是服务于后端产品本身的功能。它与用户或我们面向用户的产品无关。

　　结束

　　真正复杂的后端系统非常罕见。当我们接触到后端系统时，我们不需要过于紧张或恐慌。您可以参考以上四个原则进行设计。这四个原则是后端设计的基本原则。 , 复杂的后端系统也是基于应用的基础升级或变化，并不是全新的。

　　其实后端设计有很多技巧。后续文章我会继续分享一两个。

　　下一篇文章，我们来讨论后端的易用性设计。我会提到合理设计、路径设计、步骤设计、频率设计和后端主页设计。

　　#专栏作家#

　　Dead Leaves，微信公众号：Dead Leaves Cafe。每个人都是产品经理专栏作家。近6年经验的产品经理，擅长社交、社区、细分群挖掘。

　　本文原创发表于人人是产品经理。未经许可禁止转载。

　　奖励作者，鼓励他努力！

　　欣赏

　　4 人获得奖励