后台产品，顾名思义就是不直接面向用户的产品。我总结了一款后台的产品可以从以下两个个方面去衡量：

第一、满足的需求更多的是业务需求而不是个人的诉求。

第二、产品使用的目的性极强。后台产品在使用的时候一般都带有极强的目的性，或需要完成业务方面的操作，或需要完成某些流程的审批，总之在使用的时候一般不会因为个人情感方面的原因去使用。

根据上面这两点，同样是在点餐，你去餐厅服务员用手中的手机给你点餐的系统就是一款后台产品，而你自己点外卖或者扫码自助点餐就不是。我之前做的一款PDA系统，里面有个流程与淘宝购物流程十分相似，但它由于是为了辅助业务而开发的所以也是一个后台产品。基于这两点，我在我做过的产品中归纳了一些几种不同的后台产品形态，并且给它们分了类。

工具类

去年的时候，我做过两款我们平台内部的应用，一个是平台的品控系统，另外一个是称重系统。同时最近在做ERP项目的时候做了PDA端的部分。如果按分类来说的话，我将这几个系统称之为工具类系统。类似的还有出去吃饭的时候店员在用的点餐系统，我们在收快递的时候快递小哥手里拿的PDA里面的系统。

我总结了工具类产品的几个特点：

1.使用端一般为移动端。

由于工具类产品的特殊性，所需要的便捷性特别重要，往往需要在不同的场景下使用，使用工具类后台产品一般都为移动端产品。比如PDA,PAD,手机APP等。所以一般在设计的时候，一定要根据不同的业务场景选择合适的操作端进行设计。

2.操作性特别强。

相对于其他的后台产品，工具类产品的操作性特别强。具体来说工具类产品应该是为了满足某些操作流程，规范化，智能化，集约化所开发的产品。所以这个时候，使用工具类后台产品的操作就至关重要，同时也是其唯一的目的。

在设计工具类产品的时候，需要考虑以下几个方面：

①操作的步骤，输入按钮等交互需要多加考量。由于工具类的产品核心功能是操作，如何能在该场景下简单便捷的达到操作目的，是需要设计者去思考的。

②工具类产品很多时候使用的场景是移动的，而不是和其他后台产品一样在电脑上操作的。所以这个时候就需要考虑到工具类产品的使用场景问题。比如在一个大一些的市场里面使用PDA时信号可能不太好，那么弱网环境下的体验应该如何，图片是否加载，操作步骤是否要简化；再如一个饭店的点菜宝，使用者在饭店这样嘈杂的地方提示音的音量是不是应该大些。

3.相对于其他后台产品权限较低，整体比较简单，功能较单一。

我们一般在提到后台在产品的时候，第一印象可能就是复杂与繁琐。但是由于工具类产品的操作人员一般为实际的业务操作人员，所以其权限一般来说会比较低。同时也因为它可能只是为了满足某些需求而要做的一套工具。所以由于以上几个原因工具类产品会比一般后台产品简单，功能也会较为单一。

记录类

记录类产品指的是在业务人员进行操作的时候，为了以后操作的可溯性，以及工作后期的查漏补缺，当前所需内容的一些记录等所开发的产品。比如在我最近做的ERP系统里面，商品的到货以及入库都需要进行记录，同时新采购的商品需要进行录入，而这些都属于记录类的产品。一般来说记录类的产品不会单独存在，而是作为某一套大的系统中的一小部分。

我总结了记录类产品的几个特点：

1.在规划字段的时候，记录类产品应该加上标识字段。

由于记录类产品很大程度上会作为今后某些工作的参考记录，其数据的流转性，与其他数据的整合的可能性较高，业务人员的审查更改几率也交大，有时也会有存档的需要。所以一般记录类的产品都需要加上一个标识字段，通过设置好规则的编码方式给其确定唯一ID。

2.产生新记录数据时应该思考全面。

在设计记录类产品的时候，每一条数据的产生方式都是需要仔细思考的。因为其实你整个页面就是每一条新纪录的叠加生成的，所以一定要在源头把控好。

一般来说如果是通过外界业务的原因直接推进到系统做记录的话，是可以通过在页面增加新增按钮来进行新增的，此时应该用弹窗还是新页面的方式，某些字段是填写还是选择等都需要去思考。如果是在系统内部由于一些业务的流转直接生成的记录，那么从另一个页面带过来哪些字段，去掉哪些字段，同时需要补录什么信息就是比较重要的点。

另外，在产生数据后这条数据是直接叠加到列表最上面还是有状态有位置。新增数据后有没有审核的流程，审核需要几步，审核过程中数据是否展示出来，展示在什么位置都有许多可以细化的点。

3.做筛选与搜索要精简准确。

做记录类产品，为了更加精准的定位到所需要的数据，一般都会做筛选与搜索。从条件上来说，页面里面所有的字段都可以作为筛选与搜索的条件，但是我们在做的时候，不能仅凭个人习惯来做定夺。要多和业务人员进行沟通，找出他们在操作此类信息最敏感的字段是什么，最好辨别的字段是什么，差异性最大的字段是什么，然后来做删选与搜索条件。筛选与搜索做的特别精简但是所能达到的目的却十分准确才是一个好的筛选搜索。

4.边界条件，输入字段，操作等限制条件要做到位。

由于记录类产品的特殊性，需要操作人员输入大量的数据，这个时候如果不慎操作失误但是却没有发现，就可能出现错误，耽误业务。所以在设计的时候，一定要考虑到这些限制条件。比如该字段的边界值为多大多小，字段允许输入的合法字符是什么，一共需要输入几位等等这些可以通过正则表达式等技术手段减少错误的限制要做到位。同时，不同条件下的该条记录可能操作也不一样。这个也需要考虑到。这一点也适用于下文要说到的配置类产品。

5.排序，操作交互等其他小的功能点要考虑全面。

记录类产品每一条数据的字段类型都是相同的，所以有时候会涉及到排序功能。那产品经理应该考虑到数据的正常记录方式是如何的，时间正序还是时间倒序，哪些字段允许排序，排序的方式是什么。操作的交互需要思考设计，这个操作是在列表页面就让其操作还是需要点进详情页必须看完详情后才可以操作。以及要不要做批量操作的功能等等其他一些这样小的功能点，产品经理也要根据业务考虑全面。

配置类

配置类产品可以说是后台产品中较为常见的一种，同时也是涵盖内容较广的一种。内容管理配置，活动配置，人员管理配置等等都叫做配置类产品。关于这个系统不同角色的权限配置，以及其他页面下拉框的选项配置等等。所以作为一个后台系统，配置类的项目应该是必不可少的。

常见的单独配置类产品比如CMS，这个应当就完全属于配置类产品了。那我在平时的工作中也总结了几个关于配置类产品的特点：

1.一般有配置项，所以不会是单独存在的。

配置类的的产品一般都是为了达成系统中其他的一些功能点，或者配置另外一些网站等之类的东西所开发的模块，一般不会单独存在。所以在做配置类产品的时候，我们做的时候不能简简单单的将自己目前所做的东西做完就好了。一定要联动着看配置类产品以及它所配置的系统所更改东西的变化，大局观更重，所要考虑的东西也更多。

2.思考的广度不能停留在表面。

在做配置类产品的时候，对应的配置项可能不是特别复杂，但是产品经理在做的时候却要慎重思考。比如在做CMS配置商城抢购的时候，前端需要所操作的页面可能会比较简单，用户所要接收到的信息也不会特别复杂，但是在进行后台配置的时候，却要将所有的信息都考虑到。即便用户只有1%的操作几率，那也要配置到这1%时候的操作结果。再如做角色划分的时候，有些角色可能暂时用不到，但是为了整个系统未来的迭代等考虑要将其做进去。

3.角色处理时数据要做整理，流程要走通。

如果我们在做一套特别复杂的系统的时候，配置项往往都会决定着你的系统是否易用，因为可能不同的角色看到的会是不同的操作内容。而这些操作内容对于该角色来说都会是一个有机的整体，要让他们觉得这个系统不突兀，所有的流程都要流畅，不觉得哪里少点什么，怪怪的。所以我们在进行配置设置的时候，不能简单的做字段的增删，功能的显示隐藏，要将系统的易用性放在重要的位置考虑。要在隐藏字段与操作的同时将与之关联的内容都进行配置。这样才可以让不同的角色使用时都会觉得自己用的是一套完整的系统。

关系类

关系类产品可以说和上面的几种产品的分类定位不一样。无论是配置类还是记录类，都是通过其操作方式来划分的。而关系类是通过功能来划分的。只是因为自己最近在做关系类产品，所以拿出来单独说一下。

市面上目前比较典型的关系类产品就是CRM了，许多公司通过自己的CRM来管理与客户之间的关系。我们最近在做一个关于合作伙伴的管理系统，所涉及到的关系主要是商场与商场入驻店铺之间的关系管理，设计一个关系管理产品的时候，思路是什么样的呢？

我觉得，既然是关系管理系统，那么产品经理第一步要做的就是理清他们的关系，虽然可能一开始的关系会特别的复杂，而且难度更大的是可能有时候不止是两者的关系，会有三种甚至多种角色的交叉关系，这个时候，开头的工作一定会很艰难。

一般在做的时候，第一步要将这角色之间发生的所有交流都整理出来，在何种情境下这两方会发生交流，然后在系统中会有哪些交流。这一步异常重要也十分复杂，需要产品经理极具耐心和细心。

其次，在将关系整理完毕后，需要整理出一条主线，即为什么这两者可以发生关系？之间怎么传递的？传递的过程中会带来哪些信息？需要进行什么样的操作？比如一个电商的客户管理系统，其主线就是客户购买商品，所以这个就是它的主线。在数据内容方面，客户购买完商品之后，我就有了客户的购买数据，可以整理出客户的RFM数据模型，可以为每个用户进行画像。在营销方面，我可以根据客户的购买的状态及记录进行相应的操作。可以通过其客单价复购率等为客户进行VIP的评级，不同优惠的制定等等。通过这条主线进行发散，将整套系统的架子先搭起来。然后再填充上无法通过此流程进行关联的内容，比如客户信息的录入等等。

然后，再根据业务的重要性调整位置，填充具体内容。

最后，将整体流程跑一边，看一下有没有遗忘的流程，再和需求方业务方对接。

内部应用，外部应用

内部应用与外部应用说的主要是我们提供的服务对象。内部就指的是公司内部用的，而外部可能就会作为一个B端产品面向市场或者合作伙伴。

在做我们网站首页的CMS时，第二部分的广告条数量一开始是打算限制的，后台对接的时候负责CMS的运营说我们不会傻到加100条的吧，网站的内容也是我需要负责的啊；在做品控系统的时候，需求对接的十分顺畅，因为其实这些东西都是他们实实在在迫切要用到的，然后推到我们这边来做。

所以在做内部应用的时候，相对来说压力和挑战都稍微少一些。一是本身就是自己的同事需求方面会尽可能的满足你，二是既然公司要做这个系统就说明了的的确确公司需要这样的一套系统。

然而外部系统却不是这样，因为这个时候我们面对的时候客户，如果碰到一些本身自己需求就不明确的客户，或者市场上有和我们在竞争的客户，这个时候如何博得客户的欢心，得到市场的认可也异常重要，与C端产品的研究用户就有一拼了。

以上是我总结的一些不同类型的后台产品及其特点。可能划分的方向不尽相同，有些也会有些重复，但是都是作为一个单独具有该类型鲜明特点的后台产品，这也是我在平时工作中所总结出的它们的特点。一套后台系统往往的复杂的，庞大的，单独以此作为一套系统的其实不是很常见。将这几个小块根据业务内容实际整合到一起，也是考验产品经理能力的地方。