首先我们来看看什么是后台产品。后台产品其实就是我们称作的后台管理系统、内部管理系统。简单而言,是给企业员工开发的办公性质产品,同时也是对用户使用的App,Web等产品的一个伴生产品。
我们会认为后台产品很难,本质原因是因为做后台产品的人很多 ,我们常常将后台产品交给新人来设计,用来练手,也用来学习。
后台产品的特殊性质,让我们可以将其交给新人练手,这个特殊性质在于他的用户身份,因为这是一款自己人使用的产品,我们能对其具备最强的包容心,即便他的体验不那么友好,他存在许多问题,我们也可以通过人为的方式来协调解决。
在实际项目中,我们往往会将后台系统设计的非常简单,最大限度的节省开发资源。同时也是为了节省产品经理的精力耗损。后台系统设计的好坏对于用户而言,损失较少,几乎可以不计,这是一个做好了没有人称赞,做差了,也没人责罚的产品。
后台设计的原则
多数后台都会遵守以下四个原则,实际上这是后台的基础设计原则。其中,最重要的是前三个原则。
可视化原则
典型的可视化原则便是后台产品里的数据统计部分,我们可以将其理解成一种暴露信息的机制。产品在运营过程中,必然会产生若干信息,但这些信息往往是我们看不见的,或者每一次的查看都需要研发进行支持的,为了方便我们的查看,就将这部分内容在后台里展示出来。
可视化原则的典型特征是只允许查看,各种维度的查看,但本身不具备更多的操作性质。
这部分功能的设计方法,只需要我们去考虑哪些信息是我们需要看的,又以何种维度进行查看就可以了。
我们上线一款活动,便需要在后台查看该活动的一些信息,诸如报名人数,实际参与人数,甚至于时长,当然,我们还可以把参与人员的地理分布统计出来,还有性别分别,年龄分布。
遵循可视化原则常见的功能,包括我们的多维度筛选,排序,导出,数据明细,饼状图,柱形图,折线图等等,这些功能都符合可视化设计原则,用最合适的方法,提高我们查看信息的效率。
数据源原则
几乎所有的后台系统都会扮演着数据源的角色。我们要在面向用户的产品里投放一个活动、放一个新的banner图、推荐一篇文章、推荐一个专题,都需要有一个录入信息的地方。而在后台里,符合数据源原则的部分便承担了这部分内容。
数据源原则的典型特征在于新增。除了常规的查看的能力,数据源部分必然包含新增功能,我们可以断言,不具备新增功能的后台,便不符合数据源原则。这表示该产品几乎不具备可运营能力,运营同学也无法通过后台对产品的内容,风向,活跃度进行干预。
以微信公众号的后台管理系统而言,我们新增的图文素材,新建的推送任务便是属于数据源设计原则的功能,可以将既定的信息主动的插入到面向用户的产品里。
这部分功能的设计主要是与面向用户的产品进行搭配,是一种配合形式的设计,后者需要预留支撑空间才行,诸如预留banner位,预留推荐标签,预留PGC的内容规则。
简单而言,数据源原则便是要求我们后台要具备“生产新内容”的能力。产品运营过程中,要具备能够生成新的主题,新的活动,新的通知能力。
他是与面向用户的产品进行配合而存在的一种后台设计原则。
版本更新通知,也是属于数据源原则的功能设计。当我们更新了一个新版本时,需要通知用户更新,此时,我们就需要新建一个版本通知。在该模块里,填写通知的内容,通常都是对新版本的简单介绍,在设定好通知对象,诸如1.x版本及之前的版本,我们还可以设置通知的形式,比如是强制性升级还是可取消的升级通知。
数据源原则的功能,难点在于参数的选择,我们要尽可能多的让运营同学在新建内容时,有更多的参数可以选择填写,这样才能满足他的灵活性, 毕竟这部分能力是官方向用户发出声音的能力。
来看看公众号新建一篇图文素材包含了那些参数:
可以试想一下,假如公众号能允许我们在新建图文素材时,增加小游戏的引用,公众号的玩法就会发生截然不同的变化,当然这需要面向用户的产品做出许多的支撑才行。
控制性原则
控制性原则是指后台操作人员能够对用户的部分信息进行修改。是一种保护机制也是一种应急机制,当用户发出了不好的内容时,我们能够有所作为,而不是只能看着。
在保护内容生态的同时,当用户执行了某些不可逆操作时,我们也需要有应急能力,来为用户修改某些信息。在一些小的产品里,甚至能够直接修改用户的账户或金币余额,尤其是一些游戏产品,这是为了更方面的打造“托”或者“特权账户”。
控制性原则的设计理念,在于保护和应急机制。通常来讲,这两种机制的功能包含屏蔽、黑名单、删除、修改,我们需要识别出面向用户的产品里,哪些内容是需要被保护的,哪些内容是需要建立应急机制的。
尽管,控制性的功能是不常使用的功能。实际上,我们并不希望这些功能被使用,但这些功能是必须存在的,当我们需要使用这些功能时,就表示出现了异常的状况,此时,这些功能就变得非常的需要了。
内部设置原则
如果说,可视化原则的设计对象是我们看不见的信息,数据源原则的设计对象是新建内容,控制性原则的设计对象是用户及用户生产的内容,那么内部设置原则的设计对象则是后台系统本身。
最常见的内部设置原则是我们的权限系统,他与面向用户的产品毫无关系。这部分功能的设计对象仅仅是明确操作者的权限范围,同类型的功能还包括操作记录等。
当然,后台的账号系统也是属于内部设置原则。
后台的账号是无法被申请,被注册的,这部分账号的来源往往是管理员账号生成的。一方面在设计系统时存在一个固定的超级管理员账号,通常是admin账号,这个账号可以生成其他的子账号,并为之赋予不同的权限。
企业邮箱是典型的案例,当我们入职一家较为成熟的企业时,都会按照我们的姓名或者工号生成一个独立的企业邮箱账号。
内部设置原则更多的是服务于后台产品本身的功能,他和用户,和我们面向用户的产品没有任何关系。
总结
真正复杂的后台系统非常稀少,在我们接触后台系统时,不需要太过紧张,也不需要太过恐慌,可以参照以上四个原则进行设计,这四个原则是后台设计的基础原则,复杂的后台系统也同样是建立在对基础的升级或者变化应用上的。