abtest（关于后台设计的思考）

编辑导语：在后台的设计中，功能性被十分看重，后台的功能很大程度上决定了软件的可操作性，本文作者就此做了一定的介绍和对后台功能设计的分析，一起来看看吧。

后台，在互联网软件中一般指对于软件中的数据进行管理的平台。随着技术的发展，后台也代指未直接面向产品创造价值的用户，在幕后提供能力对软件进行支持的平台。不论何种定义的后台，共同点都在于后台是一种偏向支持性的功能产品，而至于是对某个软件的数据进行管理的操作平台，还是提供功能对软件进行支持的功能性平台，只是后台的不同阶段。

今天我想分享的思考，是关于后台设计的思路以及一些启发。那么就从“什么是后台”开始吧。

一、什么是后台

1. 服务于一款产品的数据管理平台

我第一次接触后台，是刚工作之时遇到的网页内容管理后台。彼时的我负责游戏门户网站建设的工作，对于网站中特定的功能以及发布的文章内容有对应的数据管理平台，这就是我接触的第一个后台。这类后台很好理解，区别于网页直接呈现给使用者，后台是对呈现的内容进行管理调整的地方。这个后台并不算特别复杂，主要就是内容的录入，然后根据网站的结构结合网站界面进行封面图配置、缩略标题等功能配置的地方。

后来团队开始基于我们负责的游戏门户网站，开发了自己的游戏资讯社区类安卓应用，我又参与了这款应用的后台设计。这个阶段的后台目的很明确，通过可视化的界面设计，将网站或是应用日常运营所需的图片、文案或是其他的数据配置通过填写、选择的方式供运营人员使用，提升网站、应用的数据管理效率。

2. 服务于一类产品的数据管理平台

因为工作重心从网站运营转移到了移动应用，不同类型产品的数据需求不同，服务于对应产品的后台也不同。但是由于二者经常共用一些资讯文章以及游戏列表，使得两个产品的后台之间经常有联系，此时的后台开始将很多重复用于两个产品或是内容重复的数据独立出来，专门设计独立的功能后台进行管理，例如网站与移动应用都会用到游戏列表，都会展示登录的用户昵称头像等信息。

为了更好的同时服务网站与移动应用，后台开始不局限于以具体的界面提供数据管理，也会有更加抽象的接口能力进行支持。此时的后台将通用的部分整理出来，不仅可以进行数据内容管理，为了服务于不同产品，也提供了更加灵活的功能支持，以满足同一类产品的数据需求。

3. 开放自身能力，服务于更多人的功能平台

随着网站和移动应用的火热发展，我们开始了自己的商业化之旅，就是通过网站的文章对游戏进行推广，在移动应用中对游戏提供下载与游戏开发商合作。为了便于游戏开发商接入我们的产品，我们专门打造了一个后台，供游戏开发商提供游戏接入，同时我们还提供了在我们的产品中游戏下载数据的数据统计后台以及一些运营支持能力。这时我们要不断的更新我们可以为游戏开发商提供的能力，供他们的使用。

此时的后台便不再像之前一样仅局限在服务于产品的数据管理，转变为提供能力给其他的产品开发者使用帮助他们完成游戏运营推广、游戏下载流程。

4. 做个小结

不同角色在看待后台时有不同的定义，本文探讨的后台是根据业务所需的产品形态不同，在不同时期下服务于产品数据管理平台、服务于产品的功能支持平台这样比较广义的定义，时下则称之为了中台抑或是中后台。前文的三个阶段，也是我所理解的后台发展过程。不同阶段，因为目标不同，所以后台的设计上偏向性也不同。在前两个阶段，为了服务网站与移动应用，后台更多的是服务于二者的数据管理。

随着二者的互动增多，后台在数据内容管理的基础上，也要进行更加强大的功能支持。而随着业务的范围扩大，服务的对象拓展，后台开始不局限于产品的运营人员，当更多人参与到产品中时，对于其他角色也需要拓展相应的能力支持，此时后台便开始往开放平台的方向发展了。

后台不仅仅是一个内容管理平台，随着技术与产品需求的发展，后台的核心是背后的功能流程，通过对功能流程的整理，进而将功能流程中的数据、信息流转途径具象化体现，供使用者对数据、信息进行管理，从而帮助使用者提升效率。

二、后台设计思路与小结

在产品的不同发展阶段，对于后台的功能需求是不同的。后台能力的发展趋势，大致是从服务于一款产品的内容管理，到服务于一类产品的内容管理，最终到将内容管理的能力整理后开放，供其他人使用的过程。这是一个从我开始，到帮助他人的过程，我将这个发展过程总结为从内容管理到功能开放。

根据我工作经历中总结的后台发展过程，这个过程中变化在于产品与使用者在发展过程中，产品功能增多、使用者角色增加时，随之迎来了后台的改变。因此在后台的设计中，不同阶段下，后台的设计思路不同。

1. 框架设计

当后台还是服务于具体产品时，后台功能的表现体现于产品的内容数据管理，例如常见的图文配置，数据统计。此时在后台的设计上需要根据使用者的角色分类、数据的操作与查看权限以及操作过程中的效率将后台进行分类，具体要做的就是将不同后台分割、在一个后台中根据操作类别整理为不同的菜单。那么先从后台框架的后台分类开始。

（1）后台的分类与菜单的划分

最基础的后台一般是基于产品的内容管理平台，在这个后台中做的最多是内容配置，例如图文配置，视频上传。此时的后台主要是服务于产品的运营人员，不论图文、视频数据服务的是何种类型的内容，在后台设计之时因为涉及到操作，就会有不同的分工，也许不同的分工之间还存在不同的权限，不可以互相查看或者互相操作。

此时如果不同分工之间的联系并不紧密，或是后台功能的服务对象不同，例如某个营销工具类产品团队，一部分负责工具内的图文内容配置，一部分则负责营销客户的数据管理，此时二者需要分开管理，各自互不相同，则需要考虑分为两个单独的后台进行各自的数据管理。

若放在同一个后台中，则需要考虑将两个功能管理划分在不同的菜单下，此时可以使用一级菜单对功能分类，将各类管理操作放在二级菜单中。这一点在很多软件的设计中均有体现，例如下图VScode的设计，从上至下、从左至右根据功能等级进行了划分。

后台的分类相较菜单的分类标准更简单，根据功能的关联性定义即可。而后台中的菜单划分，主要的标准则是团队的工作流程。假设现在需要对营销工具APP中不同的页面的轮播图进行内容配置。如果团队是根据不同人员负责不同的页面，此时则以页面为单位进行菜单划分，即可保证各自负责的人员在权限设计时更为独立，避免相互影响。

若团队是根据功能划分负责范围，例如轮播图由专门团队进行管理，而其他的功能配置由其他的团队负责，此时的菜单划分则根据所负责的功能来定义。总结一下，后台的分类与菜单的划分主要的定义原则是：

后台的框架设计包含不同功能的后台划分，每个后台在根据各自的功能进行菜单划分，根据功能的关联性分类。例如操作类后台与数据统计类后台二者在功能操作关联性上不强，为了权限以及效率考虑，可以考虑为两个后台，或同一后台中的不同模块；后台的菜单以及功能设计基于团队的工作流程，虽然有各种分类方式，如果后台分类以及菜单的划分不能满足工作流程或保证工作效率，则需要考虑框架结构的设计是否合理，后台的本质是为了提升效率。
因为面向的业务内容不同，这里的工作历程需要结合各自的业务来定义，沟通是非常必要的。
（2）后台的账号体系
后台的分类以及菜单的划分更多是对业务的功能进行拆分，而账号的设计则是对操作权限以及团队人员进行设计与管理。一般来说，后台初始的状态是一个人为管理数据流转的过程，例如资讯内容类网站或者应用中，运营人员对功能模块的图文、视频配置。因为分工的不同，每个操作人员可拥有的操作内容以及可查询的内容是不同的，此时我们需要对操作的人进行角色的定义。
当做好了基于功能的后台以及菜单的划分后，则需要为后台创建可操作的单位，这个单位就是账号。之所以账号是放在后台框架设计之后来定义设计，是因为如果未考虑好后台的框架结构，若在后续增加了新的后台以及功能时，又需要重复使用之前的账号，则需要对账号功能进行升级，让新的后台可以使用之前账号的数据。
此时不如就先把后台的框架设计与账号设计各自分开，并根据业务的需求先对功能分类，然后根据工作流程设计账号，将两部分功能独立进行管理，此时也可以将账号体系理解为后台能力的一种。
三、基于后台的其他的功能设计
1. 权限设计
之前已经对后台和菜单进行了分类，又创建了账号，此时就需要对每个账号在后台中的行为进行权限管理了。目前常用的权限功能是RBAC模式，即各类权限定义在角色上，然后再为每个账号赋予角色。这种模式的优点是效率高，不用单独为每一个角色定义权限，当有大量的人员需要配置相同或类似的权限时，此时对于管理员来说操作就很繁琐。而对相同或类似的操作赋予在角色上，然后再把角色赋予账号如此一来效率就高了很多。
2. 功能流程的记录
不论是后台主要功能为内容配置，还是发展到后台开始提供对外的功能服务，都需要对功能流程进行记录与管理。为什么要对功能流程进行记录与管理，记录人员的操作行为或是对外的能力使用情况，是为了便于出现问题时的定位，谁、在何时、在哪里进行了何种操作，方便后台策划方了解是否存在问题、隐患。所以在一些操作类的菜单内容设计，以及操作日志的设计中，除了展示主要的操作数据之外，建议加上操作者、最近一次操作时间。
像广告投放这样会有回顾创建与修改对比的数据时，在菜单内容的展示中，还可以考虑加上创建时间，修改人，通过对比不同人不同时间的操作，来进行对比调优。后台的操作流程最好根据划分好的菜单将数据操作分开，同一类数据的操作最好不要分散在不同的菜单或者后台中，避免权限管理混乱以及多人重复操作等衍生的管理问题。
3. 操作日志管理
其实功能流程中记录的部分内容就已经组成了操作日志基础，只不过是针对当前功能菜单的操作日志。而更为综合的整个后台的操作日志同样重要。操作日志则可以更统一的记录操作人、操作时间、操作人IP、操作数据变更情况，通过这些数据的记录可以全面的反映后台的操作，也便于之后的查询。
当后台发展到对外之时，例如广告平台的开放平台，对于每个接口的调用情况同样需要记录，只不过未必需要像操作日志一样用后台体现出来，此时需要技术开发人员来进行服务端的记录与监控。
四、后台设计的思考与启发
后台的发展从面向单一的产品变为面向更多的开发者，这是一个内容管理到功能管理的转变，是一个将内容管理能力对内服务到对外开放的转变。后台的发展可以从很多产品的发展中找到轨迹，以国内的微信为例。最初的微信是一个类似QQ的即时通讯工具，随着微信发展出了公众号、微信支付、小程序等等，就是一个从服务于单一产品到开放的过程。
这个过程中，微信账号从服务于微信APP本身，然后开放服务于其他的微信类服务，例如公众号、小程序、微信开放平台等等；微信账号在此后继续开放，可供其他平台接入成为其他平台的账号体系组成之一；微信支付从服务于微信，到开放可以服务于商家以及其他平台；这样的后台能力发展，其实就是产品能力的发展。好的后台设计，除了体现在保证效率之外，也许还可以提供更多的价值。互联网软件的发展趋势是逐渐平台化，所谓平台化就是从单一服务逐渐成长为综合服务，可提供的功能更加丰富和综合。此时后台的价值也会随之提升。
而如果仅仅是服务于单一产品的简单后台，则相对简单的多，只需要针对单一后台设计账号体系与权限。此时对于后台的策划人员来说，要求也相对更低。但是随着产品功能的成长，后台也需要随之提升。产品平台化的同时，也应该让后台跟随平台化。例如各家广告平台开放平台，提供各自的广告能力，让广告主可以自行选择能力，定制开发更加适用于自己的投放平台，而非拘泥于平台官方提供的能力，能够有效地帮助广告主提升效率。
后台最重要的内容是没有体现在菜单展示内容，而是幕后的功能设计。例如一个ABtest后台，后台中配置的内容并不多，操作也不复杂，重要的是背后的用户分流逻辑、监控指标的计算流程，这才是后台策划人员需要重点思考的内容。后台的体现很简单，下拉框、表单组成的流程是表现，重要的是背后的功能是否足够强大，体现的简单需要背后严谨的思考和功能的健壮。
后台的策划工作对策划者而言得到的成就感，比起所谓to C(面向大众消费者)类的产品日活百万这样的感受是难以被感受到的。很多人将后台策划归类做to B(面向企业用户)，是因为企业类消费者的工作更多集中在协作以及需要提升效率的工作中，而后台常见的功能流程以及表单的数据体现，都是为了效率而言。
对于这一点，我的想法是不要局限于常见的分类，并没有绝对的企业用户就和不同的消费者用户在需求上有本质的不同，在使用后台类服务时都是为了解决问题、提升效率。也许没有大用户量带来的直接成就感，但是做好每一个细节，帮助使用者提升效率，用更短的时间完成同样的任务，也是一件非常难办到的事情，总之就是平常心吧。
后台中的菜单、菜单中的展示内容只是后台能力的直接表现，而非后台本身，这只是后台的呈现方式之一。不要局限在提升后台的操作流程交互，也应该去考虑后台背后的功能，通过扮演不同的后台使用角色，去发现问题，解决问题。不同于to C类产品用用户量、时长、留存等用户行为类指标检验产品成果，后台类产品的成果检验更加委婉。我的建议方式是用户访谈，问卷调查，净推荐值三种方式来收获使用的反馈，以此来判断后台的不足与用户的评价。
最后还是要强调一点，后台所呈现的内容只是表现形式，并不是说后台策划的工作就是设计菜单中的内容，应该是像开放平台一样去思考，我可以提供怎样的数据给使用者，他们可以使用我给的数据帮助他们提升效率。不同业务所需要的后台不同，就和社交类产品、游戏产品一样，有联系，但并不可统一而论。
最后的碎碎念
这是一篇结构松散的总结，鉴于能力我难以用更精彩的内容为读者带来惊喜。关于后台的策划工作，其实我总结起来更多的是缺少成就感、难以整理出经验的失落。记得我某次面试，我向对方展示我曾经设计的后台之时，面试官轻描淡写的说了一句都是表单和下拉框吧。当我想说明后台背后的功能流程，以及我设计这些功能的思考与过程时，对方并没有什么兴趣，觉得并没有什么特别的。
后台设计是一个枯燥的工作，却是一个极需强大的沟通能力与分析能力的工作。你需要游走在不同的角色间听他们的反馈，自己亲自操作或是带入到角色中去使用后台发现问题，但你面对的并不是业务创造价值的直接用户，而是作为中间的操作者。
后台是一个做的好或者不好并不是那么界限分明的产品类型，毕竟难用也能用。在此过程中我经历过很多沮丧与失落，更多的是自我怀疑。但是曾经收获过的一句“你们把我想要的都已经做出来了”，让我很长一段时间内收获了力量。请原谅我用松散的文字做的总结，希望能对你在后台设计时提供些许帮助。
本文由 @问梦孤独原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 pixabay，基于 CC0 协议