B端产品的配置应如何设计

3: 不同公司在使用同一个功能的时候，保存操作的时候后端对应的验证逻辑，以及计算逻辑不一致，需要进行配置，这里面有两个情况，可以采用不同的对应策略：

4:导入导出模版，不同公司可能导入数据文件格式不同，另外输出报表格式也不相同。

5: 对于一些流程驱动的功能，不同公司可能对应有不同的流程，可以在公司级别进行配置。

6：另外就是一些通用的设置，比如说页面风格，密码过期规则，备份规则等等。

上面的这些都是基于公司的配置，一般就是产品公司的实施人员在上线的时候基于客户情况进行配置的修改，为了节省实施的工作量，可以考虑设置一个或者多个基库版本，实施在基库的基础上面进行简单调整就可以。

基于公司的产品配置一般都是供应商公司来实施配置，还有一部分配置的功能是开放给客户自己进行配置的，这部分配置一般来说不是功能级别的内容，而是客户数据级别的需要配置的内容，可以分成几类：

1: 角色，角色权限，这个部分如果业务可以将角色标准化固化下来尽量标准化下来，如果不能，就需要允许进行配置。

2: 用户对应角色，用户数据权限。

3: 一些跟客户业务相关的数据字典。

这个部分的配置一般由实施人员在上线的时候帮助客户初始化配置完成，以后如果万一有调整的时候，可以由客户自行配置或者寻求产品支持。

关于产品配置模块的设计一般需要把握如下的几个原则：

把握产品灵活的程度是B端产品设计的最高技巧之一，只有综合业务发展，产品发展，技术实现以及扩展，团队情况的多个因素来能来找到相对最佳路径。有些人可能会说，考虑那么多干嘛，我直接做一个最灵活的版本，一切可以配置，一切可以个性化不就好了，这种思路有如下几个问题：

产品不能太灵活，也不能太死，要能够支持目标客户群不同的客户需求，这就需要对目标客户群的已有业务非常了解，对目标业务市场发展方向非常了解，知道什么地方是行业标准，可以做得贴身，什么地方是有不同要求，怎样基于不同的要求抽象出刚刚好的可配置功能，不多也不少，需要极致的思考，才能在无数条可行的路径中找到最佳的答案。从而在兼容性，客户易用性，开发性价比，配置工作量，可扩展性等方面综合指标最佳。

最近看到一个白鸦的观点是每个客户应该都是独立的个性化的，我觉得这个观点的正确依赖于相对局限的产品定位和场景。根据笔者的经验，线下的操作因为有很大的灵活空间，所以操作习惯的形成跟实际操作的人的能力，习惯，对业务的理解有很大关系，在进行线下业务线上产品化的时候，还是要尽量要标准化。当然这里要仔细辨别是用户习惯，用户水平导致的不同操作习惯，还是业务本身不同所导致的。如果是定位的目标公司业务确实有不同的需求，那还是要做成灵活配置的功能，事实上相对大一部分不同的需求都是因为操作人的不同习惯以及认知导致的，实际上是可以标准化的，否则产品会变得越来越复杂，实施配置工作量也越来越大。

王兴说过，战略就是分类。实际上产品设计的一个核心能力也是分类，怎样分类是最舒服，从业务角度，从用户角度是最容易理解的分类，功能需要分类，每个功能页面上面的元素布局也需要分好类，

配置功能的分类维度一般有二种方式，一般这二种分类方式需要结合起来，一个作为主分类，一个做为二级分类。

根据业务模块进行分类，比如说客户管理，订单管理，商品管理，用户管理等

根据功能的类别来进行分类，比如说界面显示，计算逻辑，输出，输入模版等等。

为了减少实施的工作量，做好默认基础配置库，在实施的时候在基础库的基础上面进行修改。产品的一个核心指标就是将实施的工作量降到最小，最佳的方式的不需要实施，基本上客户基于自己的情况选择几个类别，或者在运营系统上面录入客户的信息，所有的配置功能就完成了，这样的境界就是将产品的不同情形抽象到了极致的情况。

最易用易懂的配置是所见即所得，就是修改配置的时候能够看到配置会引起的变化，当然大多数TO B的产品因为太复杂，很难做到这一点，那就先取一些人能够看懂的名字，以及做好相应的解释，

不要看起来像天书一样。怎样做好产品的MVP以及让产品简单易用，可以参考我前面写过的一篇文章“怎样定义B端产品的MVP”。

作者：李东林（微信公众号：SaaS产品说；微信号：jianguzhuxin）