【来源 | 人人都是产品经理】

【作者 | 枯叶】

【编辑 | 第十七】

 

 

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

 

什么是后台产品

 

后台产品也被我们称为后台管理系统、内部管理系统。

 

简单而言，是给企业员工开发的办公性质产品，同时也是对用户使用的App，Web等产品的一个伴生产品。

 

我们还可以将后台产品按照使用对象分成两种：

 

其一是自己使用的产品，实际上，任何一个产品都需要一个后台，包括我们的C端产品。

 

另一种是客户性质的产品，多见于B端产品。

 

我们会认为后台产品很难，本质原因是因为做后台产品的人很多 ，我们常常将后台产品交给新人来设计，用来练手，也用来学习。

 

后台产品的特殊性质，让我们可以将其交给新人练手，这个特殊性质在于他的用户身份——因为这是一款自己人使用的产品，我们能对其具备最强的包容心，即便他的体验不那么友好，他存在许多问题，我们也可以通过人为的方式来协调解决。

 

后台管理系统的用户大部分都是运营同学使用，产品同学偶尔使用，而后台系统最终坑的也是这两个岗位的同学——这种坑最终会被转化成岗位之间的矛盾。

 

然而在实际项目中，我们往往会将后台系统设计的非常简单，最大限度的节省开发资源。同时也是为了节省产品经理的精力耗损，我们会将该系统的设计任务交给新人完成。

 

原因在于：后台系统设计的好坏对于用户而言，损失较少，几乎可以不计；这是一个做好了没有人称赞，做差了，也没人责罚的产品。

 

在这样的环境下，后台系统的复杂度也会被夸大，毕竟是我们做的第一款产品，毕竟接触后台产品的朋友要远远的多过面向用户的产品。

 

实际上，确实存在极为复杂的后台产品，复杂度远远超过了面向用户的产品，尤其是牵扯到算法层面的后台产品，不是专业后台产品经理几乎无法驾驭——这样的后台产品是极为少数，极为特殊的。

 

面向用户的产品，也存在极为复杂的逻辑，我们不能因此就断定面向用户的产品比后台产品难，也不能盲目的断定后台产品比面向用户的产品复杂，这两类产品都具备难度等级。

 

现在的环境，对于产品而言，更多的是应用创新阶段。高复杂度的产品，其实很少人能接触到，实在不足以让我们断言后台更复杂，几乎80%以上的后台产品都是很简单的。

 

这就好比三人成虎，人们都在说后台复杂，我们也就先入为主的认为后台更难，深入一点，到底哪里难了呢？却很难说出一二。

 

如果你是一位2年经验以内的产品，而这时，你又需要设计一款后台产品，无需紧张，按需设计就可以了。

 

你所接到的任务本身是存在风险规避因素的，这话可能不中听，但我们很难将极为复杂的任务交给经验尚且不足的你，这无疑将会放大我们的风险，而这种风险是我们原本可以避免的。

 

如果你是一位产品新人，你也正在接触后台，那就潜心去研究吧。

 

我特别乐意将后台任务交给新人，因为他更加的固定，后台产品的变化很少，是有迹可循的，他不像面向用户的产品，有很多变术，而每一个变术都藏着天使与恶魔，将会给我们造成实实在在的伤害。

 

当然，最重要的，任然是这个观点：企业和我们的上级在做任务分配时，必然会考虑风险因素，考虑失败或者犯错的成本是否在我们可接受的范围。因此，无需有太大的心理压力及负担。

 

后台设计的原则

 

多数后台都会遵守以下四个原则，实际上这是后台的基础设计原则。我将其定义为可视化原则、数据源原则、控制性原则以及内部设置原则。

 

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

 

可视化原则

 

典型的可视化原则便是后台产品里的数据统计部分，我们可以将其理解成一种暴露信息的机制。

 

产品在运营过程中，必然会产生若干信息，但这些信息往往是我们看不见的，或者每一次的查看都需要研发进行支持的，为了方便我们的查看，就将这部分内容在后台里展示出来。

 

可视化原则的典型特征是只允许查看，各种维度的查看，但本身不具备更多的操作性质。

 

想想看，在我们接触到的后台产品里，都有哪些功能是属于可视化原则的。

 

数据统计部分、数据明细部分、用户列表、内容列表几乎都是属于可视化原则的。

 

这部分功能的设计方法，只需要我们去考虑哪些信息是我们需要看的，又以何种维度进行查看就可以了。

 

我们上线一款活动，便需要在后台查看该活动的一些信息。诸如报名人数、实际参与人数、甚至于时长；当然，我们还可以把参与人员的地理分布统计出来，还有性别分别、年龄分布。

 

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

 

数据源原则

 

几乎所有的后台系统都会扮演着数据源的角色。

 

我们要在面向用户的产品里投放一个活动、放一个新的banner图、推荐一篇文章、推荐一个专题，都需要有一个录入信息的地方。而在后台里，符合数据源原则的部分便承担了这部分内容。

 

数据源原则的典型特征在于新增。除了常规的查看的能力，数据源部分必然包含新增功能，我们可以断言，不具备新增功能的后台，便不符合数据源原则。

 

这表示该产品几乎不具备可运营能力，运营同学也无法通过后台对产品的内容，风向，活跃度进行干预。

 

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

 

这部分功能的设计主要是与面向用户的产品进行搭配，是一种配合形式的设计，后者需要预留支撑空间才行，诸如预留banner位，预留推荐标签，预留PGC的内容规则。

 

简单而言，数据源原则便是要求我们后台要具备“生产新内容”的能力。产品运营过程中，要具备能够生成新的主题，新的活动，新的通知能力。

 

他是与面向用户的产品进行配合而存在的一种后台设计原则。

 

版本更新通知，也是属于数据源原则的功能设计。

 

当我们更新了一个新版本时，需要通知用户更新；此时，我们就需要新建一个版本通知。

 

在该模块里，填写通知的内容，通常都是对新版本的简单介绍，在设定好通知对象，诸如1.x版本及之前的版本；我们还可以设置通知的形式，比如是强制性升级还是可取消的升级通知。

 

数据源原则的功能，难点在于参数的选择——我们要尽可能多的让运营同学在新建内容时，有更多的参数可以选择填写，这样才能满足他的灵活性， 毕竟这部分能力是官方向用户发出声音的能力。

 

来看看公众号新建一篇图文素材包含了那些参数：

 

 

可以试想一下，假如公众号能允许我们在新建图文素材时，增加小游戏的引用，公众号的玩法就会发生截然不同的变化，当然这需要面向用户的产品做出许多的支撑才行。

 

控制性原则

 

控制性原则是指后台操作人员能够对用户的部分信息进行修改。

 

是一种保护机制也是一种应急机制，当用户发出了不好的内容时，我们能够有所作为，而不是只能看着。

 

在保护内容生态的同时，当用户执行了某些不可逆操作时，我们也需要有应急能力，来为用户修改某些信息。

 

在一些小的产品里，甚至能够直接修改用户的账户或金币余额，尤其是一些游戏产品，这是为了更方面的打造“托”或者“特权账户”。

 

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

 

同样是以微信公众号为例，我们可以在公众号后台设置黑名单，那这部分用户将不能再向公众号发信息，也不能发留言了。我们还可以将已经发布的文章删除掉，这样，这篇文章就无法再被查看了。

 

控制性原则的设计理念，在于保护和应急机制。

 

通常来讲，这两种机制的功能包含屏蔽、黑名单、删除、修改，我们需要识别出面向用户的产品里，哪些内容是需要被保护的，哪些内容是需要建立应急机制的。

 

尽管，控制性的功能是不常使用的功能。

 

实际上，我们并不希望这些功能被使用，但这些功能是必须存在的，当我们需要使用这些功能时，就表示出现了异常的状况。此时，这些功能就变得非常的需要了。

 

内部设置原则

 

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

 

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

 

当然，后台的账号系统也是属于内部设置原则。

 

后台的账号是无法被申请，被注册的，这部分账号的来源往往是管理员账号生成的。一方面在设计系统时存在一个固定的超级管理员账号，通常是admin账号，这个账号可以生成其他的子账号，并为之赋予不同的权限。

 

企业邮箱是典型的案例，当我们入职一家较为成熟的企业时，都会按照我们的姓名或者工号生成一个独立的企业邮箱账号。

 

内部设置原则更多的是服务于后台产品本身的功能，他和用户，和我们面向用户的产品没有任何关系。

 

结尾

 

真正复杂的后台系统非常稀少，在我们接触后台系统时，不需要太过紧张，也不需要太过恐慌，可以参照以上四个原则进行设计。

 

这四个原则是后台设计的基础原则，复杂的后台系统也同样是建立在对基础的升级或者变化应用上，并不是全新的。