最近刚做完公司的内容管理系统，我总结了一些经验，分享给大家。

后台产品也分很多种，从使用者的角度会分，公司内部人员使用的运营管理系统，面向合作伙伴的CRM系统，还有的公司就是专门销售管理系统的，典型的如OA。

我在这里讲的只是面向公司内部人员使用的系统。

在做后端产品的过程中我更加理解了产品理念的重要性，很多事如果我们的理念相同，会极大的降低沟通成本，沟通的双方会很快达成共识。

1、名词概念统一

在产品设计时我们会给不同的功能定义不同的名词，有些名词已经非常通用，大家一说都明白，例如删除，添加。但由于各个公司的运营需求不同，对功能要求也可能不一样。即便都叫运营管理系统，但也需要针对公司自身的情况开发一些定制功能。

名词的定义除了关系到使用者的理解之外，也会关系到跟技术人员的沟通。要不然就会出现大家心中想的是一个事情，但是语言用词上不一致，造成一些误会不说，可能还需要每次沟通前都得把名词强调一遍。所以产品经理在开发前就应该跟技术人员先把名词定义好。

有些功能可能一时想不到适合的词汇也没关系，只要大家在内部对名词的理解统一即可。

2、节省效率

先说一下产品背景，拿CMS产品来说，主要是用来供公司运营人员使用的，用来发布并管理内容。这类产品有个很重要的原则是一定要快，节省使用者的工作效率。其实不光CMS，很多系统也都会坚持这个原则，例如超市的收银系统，即使结一单只提升几秒，一天下来可能就会节省几十分钟。

我见过有的产品经理会因为一个电脑页面显示不完，为了样式的好看而隐藏一些用户所关心的信息。这样在操作的时候大家还得去点击详情查看，需要二次操作。不要因为样式上的美观而降低效率。后台系统中肯定会有很多列表，不同的列表会显示不同的信息。如果一个列表中运营人员所关心的信息太多，那么全部显示出来即可。所以在界面设计上也要尽量利用空间，这个思路跟手机界面的留白就不一样了。

为了节省效率还有一个很重要的原则就是优先显示运营人员关注的信息。例如信息审核系统，对于运营人员而言，他们最在乎的是待审核的信息（提交的用户还在等着呢)。所以应该优先显示这类信息，这是急切需要运营人员操作的，而审核通过和审核失败的，可能只是在需要时才会查询一下。

举个例子来说明为了效率提升，产品设计的改变。在信息操作的时候，我们可以将操作目的直接做成按钮，而不需要使用单选按钮再点击提交操作。

3、严谨，准确性，降低误操作

从某种程度上说这一点跟第二点是相矛盾的。如果你在用户进行某项操作时还需要他进行确认操作，这个过程势必不会那么顺畅。

但确认操作又是必须的。之所以需要确认操作主要是为了降低运营人员因为误操作而带来的损失。当然这并不能保证万无一失，只是降低出错的风险。

产品经理在设定某个功能需要确认操作时也要考虑清楚，什么样的功能该有确认操作，什么样的功能不需要。要是所有的功能都需要确认操作，那真的就没效率可言了。

判定的标准就是看能功能产生的影响。之前媒体有报道过惠普和当当网有标错价格的情况，把几千块钱的商品标注成了几块钱，面临的是经济损失。这应该是误操作带来的最严重的影响了。对运营系统而言，更多的情况是给页面显示带来一些错误，例如把本来不该显示的信息提前上架了。还有可能是误删除了信息，这时候就要自己重新添加了。

如果某些信息操作后的效果并不严重且有补救措施，那就可以没有确认操作。

4、该不该用技术的方式约束人性

该不该用技术的方式控制人性，这也是一个挺纠结的问题。还是拿我上面举的确认操作的例子来说，有的人会觉得其实这个是使用者自己的行为，他们在操作前本身应该看清楚，何况后台系统都有操作日志，如果谁犯错了，看下操作日志找到当事人，给予相应的惩罚。这样也会提醒别人，大家以后误操作的几率也会降低。这个观点也会成为我们砍掉某些功能的理由。

这种话我多半以为都是气话。且不说在工作中实际操作性有多大，即便可以对员工罚款，但是事件对外界造成的影响呢？即便有人负责也晚了，所以还是要提前避免。

有一点，对于信息的管理，只要是人控制的就充满了太多不确定性。通过在技术上加以限制还是有必要的。但也要有度，有些限制做不好会适得其反。

讲一个案例，一家公司的信息审核系统，运营人员在审核信息时，系统设定了60秒的时间，不管运营人员有没有看完信息，审核通过的按钮只有在60秒后才能点击。本意是希望让运营人员必须查看后才审核，防止他们办事马虎。但实际过程中却发现这种做法降低了运营人员的效率，因为他们看完一条信息不需要60秒。有的人可能会说那就设为30秒，由于经验不同，运营人员的审核效率不同。而且出于信任有的用户的信息运营人员的审核也会松懈很多，时间设置太短也没有意义。后来就干脆把这功能撤下了。

5、目的达到即可，节约开发成本

在设计后台系统时，除了从使用者的角度去考虑外，也要为技术人员的实现方式和开发成本考虑一下。不要因为无所谓的功能，而给技术人员增加工作量，很多时候只要达到目的即可。

曾经做过一个上下架功能，需要用到一个日历插件，选择时间，当时产品经理非得让技术人员把日历上的已过去的时间置灰。日历插件主要是用于选择上下架时间，而已过期时间是否置灰对于这个功能都不会有影响。当然如果做了，用户体验会更好。但有些后台产品毕竟只是公司内部使用，只要目的达到了即可，没必要让技术人员去做一些锦上添花的功能。

积少成多，单个功能简单，时间短。但做多了，成本也就不低了。

结语

之前，有很多人讨论说产品经理要不要懂技术，像这种问题都没有标准答案，每个人都有自己的看法。我觉得最好还是要懂得，当然不需要深入的了解，只要懂一些技术原理就可以了。

在跟技术沟通的过程中，如果是前台产品我们的说服理由中还可以有终端特性和交互上的炫酷。但做后端产品，业务上的逻辑就更加重要了。

#专栏作家#

云瑞，微信公众号：马虎眼，人人都是产品经理专栏作家。片刻产品经理，五年产品人，走在内容社交产品路上，死磕产品设计，喜欢玩各种APP，玩桌球，打羽毛球，欢迎与大家交流。

本文原创发布于人人都是产品经理。未经许可，禁止转载。