作者通过辨析后台产品与B端产品、后台产品与前台产品的区别，帮助我们来更深入的理解后台产品，并阐述了后台产品的意义和八大设计原则。希望能对正在阅读的你带来帮助，一起来看看吧~
一、理解后台产品
1. 后台产品的定义
后台产品，简单来说就是后台系统产品，主要是用于 支撑小程序、APP等前台产品 ，且通常是 面向企业内部员工 的，如常见的内容配置后台、题库后台等。下面主要通过辨析 后台产品与B端产品、后台产品与前台产品 的区别，来更深入的理解后台产品。
2. 后台产品与B端产品的区别
（1）定位不同 ：后台产品主要用于支持前台，多为 自用 ；B端产品用于为一个行业场景提供解决的全流程方案，多为 商用 。当然在某些情况下，可能会把 后台“前台化”，升级为B端产品 ，用于售卖。
（2）范围不同 ：从产品涉及到的范围看，后台产品基本指的是 后台系统的相关方案及设计 ；B端产品根据行业及客户需求不同，可能需要提供 前后台在内的产品服务 。
（3）用户不同 ：后台产品多为自用，用户多是 公司内部员工 ；B端产品根据业务场景不同， 既可能是客户企业的内部员工，也可能是客户企业的用户。 这也决定了两者的 需求来源不同 。
3. 后台产品与前台产品的区别
（1）职能不同 ：后台产品主要用于 支持前台的功能实现 ；前台产品则用于 直接服务其产品的目标用户 。简单来说， 前台是面子，后台是里子 。就跟舞台上的万众瞩目离不开台下的辛苦付出。前台丰富的功能交互，也离不开后台系统的支持。
（2）用户不同 ：后台产品的用户为 公司内部员工 ；而前台产品面向的则是 公司产品的目标受众。
（3）关注点不同 ：由于职能和用户不同，两者在产品设计中的关注点也不同。后台产品 更关注业务流程的合理性和效率性，而对交互体验等要求不高 ，人员有限的项目组后台产品可以直接不经由设计人员的页面加工美化。相比之下，前台产品直接面向用户，除了基本的流程和逻辑外， 更关注UI交互及体验 。毕竟用户用着不爽可能立马就转向竞品的怀抱了。
二、后台产品的意义
1. 前台产品的数据来源
通俗来讲， 前台产品页面上的数据、内容大多数情况下都取自后台。 淘宝上看到的形形色色的商品，包含着商品的名称、价格、介绍图等，这些都不是凭空而来，而是运营利用后台系统进行内容配置的结果。所以，涉及到后台系统时，往往离不开数据的 “增、删、改、查” 。
2. 为未来业务发展赋能
后台产品作为前台产品的支撑，需要 比前台多想“一步” ，从而为支持未来前台业务的变化提供更大的 可能性和灵活性 。
互联网机会转瞬即逝，后台只有具备足够的灵活性和可拓展性，才能避免前台业务功能迅速更新迭代时，不受“僵硬”后台的牵制而错失机会，影响业务发展。
可见， 只有熟知业务，并对未来业务发展有一定的预判，在后台设计中预留适宜的“口子”，才能避免前台业务发展受后台牵制，为未来发展赋能。
三、八大设计原则
由于工作需要，为支持前台产品功能，笔者页接触并参与设计了各种各样的后台产品，包括题库系统、商品系统、活码及各类内容配置系统等。在做了这么多后台产品后，笔者抽象出了以下 后台产品的八大设计原则 。
1. 独立性：彼此独立
独立的才是灵活的，才是可扩展的。 这里可以借用开发人员常用的一个概念—— 模块化 ，来理解独立性的意义。
简单来说， 模块化是指在解决一个复杂问题时，自顶向下逐层把系统划分成若干更好的可管理模块的过程。模块间独立性强，既可独立运作，又可灵活组合，能够达到1+1＞2的效果。
如何合理模块化，抽象出独立的系统模块？ 一方面，梳理业务流程，关注流程关键节点；另一方面，合理抽象共性，找到异同。
2. 连接性：1+1>2
独木难以成林， 一个好的产品应当是一个生态系统，他们互相连接，迸发出更大的价值。
相互独立的系统之间应当 通过某一共有对象直接关联 或 通过映射关系间接关联 。
不同系统之间的不同组合模式，才能带来真正的灵活性，满足不同业务场景的需求。我们不能在每一次业务场景有变化时，都去对后台大刀阔斧的调整。 合理对系统进行模块化，并予以关联，能够让我们游刃有余地应对一些场景的变化。
以电商后台为例，商品系统、优惠券系统、活动系统以商品或商品类型等相互关联，运营就可以在不同促销场合下，对不同的商品灵活创建不同的促销活动，提供不同的优惠方案。如果只给某几个商品做一次促销活动，或许一个系统就可以把内容配置完成，但若想进一步满足不同促销场景下的不同优惠方案，独立的系统相互链接才有更多的灵活性。
3. 抽象性：归纳本质
后台设计的一个关键内容是 字段 的创建。在创建字段时，需要全面考虑前台业务场景中可能涉及到的字段，不可出现缺漏的情况。 这些字段就是通过总结归纳，提炼出共性，进行合理抽象后的结果。抽象的目的，就是为了用最简单的结构和字段涵盖最大可能性。
以题库为例，题目中有“考点”、“难度”、“推荐答题时间”等题目属性，但不同项目的题目所包含的属性不同，如何对各种各样的题目属性进行抽象以满足不同项目的需求呢？笔者借鉴统计学中定类、定序、定距、定比的数据类型，将题目属性分为四种类型：分类属性、序列属性、字符属性、数值属性。在创建项目时，可先为项目所对应的题库创建所需的题目属性，这样不同项目的题库都可以设置选用不同的属性。
4. 结构性：内部结构清晰
后台是前台数据交互的来源，而数据是具有结构特性的，因此我们在进行后台系统设计时，必然要考虑到数据的结构属性，理清它们之间的逻辑结构。数据之间是并联关系还是父子级联关系？数据有几个层级？不同数据之间是否关联？如何关联？在设计后台系统时，需要多与后台开发人员讨论数据结构，理清数据的流转交互关系。
以教育产品中常见的教材同步习题为例，教材与教材之间是并列关系，教材下包含了章，章下又包含了节，而节下又包含了一定量并列的题目。为了初始化时给用户的推荐更精准，教材又可能通过教材年级与用户的年级相关联。
5. 推展性：为业务发展留余地
前台业务会随着对用户洞察的深入等不断发生变化，没有一个产品会一成不变。后台作为支撑前台业务的重要支柱，需要 支持前台业务的变化。
但是后台作为架构性的支撑，其调整变化常常会涉及到逻辑、数据等的调整。因此，在进行前台设计时，一定要长远思考，尤其是涉及到数据结构、逻辑等部分时，要 为业务未来的发展留有可拓展的余地。 一句话： 前台简，后台活 。
以笔者所设计的题库为例：由于是从0到1的新业务，第一期的刷题小程序只需要满足刷题功能即可，不需要显示类似“难度”、“推荐答题时间”、“考频”题目属性等次要功能，但前台产品未来规划中必然会涉及到这些内容。因此，哪怕第一期的前台小程序并不会展示以上相关内容，但是在题库系统第一版中就应当加入这些字段。总不能让运营录完题目上线后，再单独录一次题目属性吧？
6. 状态性：状态清晰有反馈
我们常说“ 事事有回应，件件有着落 ”，一个好的后台系统也应当如此。用户在操作完毕后，一定要有所反馈。根据不同的业务场景，这里的反馈可能包括： 操作成功提示、操作失败及原因提醒、下一步操作指引等 。
此外，后台业务流程复杂， 同一事物在不同的环节下，可能存在不同的状态 ，这种状态随流程的变化也需要及时、清晰的予以展示和反馈。
比较常见的例子就是商品后台中商品的上下架状态变更。再以题库系统为例，题目创建成功后，需要提交审核，审核状态及审核结果都应当予以反馈。
7. 限制性：避免误操作
后台作为前台页面内容显示的数据来源， 一旦操作有误，就很有可能会对前台用户体验带来很大影响，甚至会影响公司利益。 人非圣贤，很难保证不犯错误。这种情况下就需要 从技术上设限，以避免误操作带来的不良后果。
以电商后台为例，商品价格设置错误会直接影响到用户购买，因此，在价格设置中，类似于“原价应大于现价”、“价格不得为负”这种功能限制是必要的。再以题库系统为例，在录入真题时，题目的题干、选项等不能为空的内容，需要限制用户必须规范填写后，方能成功提交。
8. 效率性：操作高效简单
后台是给公司内部人员使用的，往往涉及到大量的内容、信息的输入及配置。因此，一定要充分 考虑场景，提高操作效率 。对于 高重复率的工作一定要尽量让计算机取代人力 。
另一方面，后台系统充满各种逻辑和流程，尤其是复杂业务，因此如何 让后台操作起来更简单、更好理解 也是一门大学问。 清晰简洁的文案、必要的注释提醒、合理的流程划分、编写操作文档和培训 等都十分必要。
举个例子，题库的题目录入场景，通常是运营将老师整理好的word文档中的题目复制到题库中，其中的选项如果要分别复制的话就很麻烦，因此后台设计中通过特殊字符区分，提供了复制所有选项后自动识别区分成多个选项的功能。大大减少了人力成本。再举个例子，一个用于为书刊生成二维码的活码系统，生成的二维码需要下载下来提供给出版社进行印刷，面对那么多书刊，批量导出二维码的功能就极其有必要。
作者：卷心菜，微信公众号：卷心菜的产品手账
本文由@ 卷心菜 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。