关于一个优秀的2B产品设计，如何从流程、角色、批量、个性化4个重要关键词入手呢？
一、通过流程理解业务
2B产品设计是从理解业务开始的。不论是行业垂直还是业务垂直的2B产品，大多都是强业务属性的。
要完成一项特定的业务，可能是一个复杂的过程，需要多个人协调配合。比如说资产的全生命管理是一个很长的过程：采购->入库->领用->跟踪->维护->报废，涉及到的角色可能包括：采购人员、资产管理员、普通员工，如果需要审批的话那还涉及到部门领导、财务人员等等。
可见业务有两个特点：过程复杂、角色多，那我们在理解业务时也试着从这两个角度来考虑，即流程和角色。如果把流程和角色看做两个维度，就可以得到泳道图，which is 常用的业务逻辑梳理工具。
下边的泳道图例子是一个餐厅从顾客点单到结账的流程，涉及到顾客、服务员、厨房三个角色，如果按点餐的阶段也可以分为用餐前、用餐中、用餐后。
如何梳理业务流程：从宏观到细节
复杂的业务系统梳理往往不是一蹴而就的，为了让自己的理解更系统、更有条理，可以采用从大到小，从宏观到细节的顺序分析和梳理业务流程。
比如上边举的餐厅的泳道图栗子，其实是一个比较宽泛的整体流程。在有了这个流程之后，我们可以更进一步的梳理顾客“点餐”的流程：
我一般会把流程拆分成两个部分：业务流程（宏观）和功能流程（细节）。
业务流程对应宏观的流程，如果输出PRD的话，可以放在产品概述的部分，让自己和同事首先对业务有个宏观的认识；
功能流程可以针对一个小的功能点，也可以针对“点餐”这样的功能模块，功能流程最好尽可能的详尽，应该包括各种各样的异常处理，原则是RD小伙伴能按照这个流程就开发出来相应的页面和功能。
流程另一种含义：操作流程
上边讲到的业务和功能流程更多是我们定义产品、设计产品时候帮助自己或同事理清思路的一种方式。
这里要说的另一种流程是有关用户体验的“操作流程”。由于2B业务本身的属性，要完成某些任务，过程可能涉及到多步操作，操作流程会比较长、比较繁琐。出于产品易用性的考虑，在设计这种功能的时候尽量让用户的操作流程化。
在表单设计中我们总结过让用户填写信息“分块分步”，其实就是操作流程化的思路。把繁琐的表单填写细化成几个步骤，用步骤条指明当前所处的位置和接下来要进行的操作。这样流程化的操作可以让用户很顺利的完成填写表单这个比较复杂的任务。
再举个例子，在一个数据采集产品中，采集数据人员要完成图像数据的采集工作需要完成上传数据、填写基本信息、填写业务信息、数据标注、数据校验几个步骤，这几个步骤其实并不具有严格的先后顺序（可以先填信息也可以先标注数据），所以我们设计的第一版产品中这些功能是一个一个分散在页面中的。
经过用户调研，我们发现这种设计会让用户进入页面后不知所措，不知道自己该做什么。所以改进的版本中我们把杂乱的功能都列在了一起，看起来像是一个todo list，这样即使是第一次使用产品的用户也能快速上手完成采集数据这项任务。
二、角色、用户、权限
什么是角色？用户？权限？
在上边点餐的栗子中，顾客、服务员、厨师是角色；顾客小李、顾客小方分别用不同的账号登录，分别点餐，他们是两个用户；顾客可以查看菜单、点餐，可以说顾客有“查看菜单”、“点餐”的权限。
角色很多时候对应着2B业务中的某类工作岗位，每个工作岗位负责的工作不同，我们就把他们叫做不同的角色，比如最常见的“普通用户”、“管理员”等等，都是因为业务中负责的工作不一样所以区分成不同的角色。
用户很好理解，一般每个人都有自己的账号登录系统，每个人都是一个用户。
权限呢？其实就是每个用户可以看到的东西（数据权限）、可以操作的功能（功能权限）。正因为每个工作岗位负责的工作不同，工作岗位A的工作内容不希望让工作岗位B的人看到（比如公司CEO能看到的数据和操作的功能肯定和一个普通员工不一样），所以我们需要通过权限来控制每个用户能的视野大小。
RBAC模型
细心的小读者会发现，角色就是用户和权限之间的桥梁，一个用户可以查看的数据权限、操作的功能权限是通过角色来配置的。
那我们不禁会问，为什么要通过角色建立用户和权限的关系呢？为什么不直接给用户赋予相应的权限呢？
也不是不行，比如在很简单的权限系统中，只有普通用户和管理员两种角色，我们就可以省去角色，直接给管理员用户赋予相应的权限，其他所有用户保持基本权限即可。
但在2B产品中，角色往往不止一种，用户也有非常多，逐个给用户设置权限是件非常繁琐的事情。既然有些用户的工作类似，所需要的权限也一致，我们就把这些权限打包成一个组合，赋给需要这组权限的用户。
所以从这个角度看，角色也可以叫做“权限组合”。如果一个角色的权限发生变化，只需要修改该角色的权限范围即可，不用挨个用户去修改权限；如果一个用户的角色发生变化，只需要修改这个用户的角色，不用再去单独配置他的权限。所以通过角色来管理用户的权限效率会提高很多。
上边讲的这种模式就是RBAC（role based access control）模型。虽然RBAC是个比较偏技术的模型，但它为我们定义产品提供了一种思路：从角色和权限的角度梳理功能。
梳理角色和权限
在RBAC中，角色更偏重“权限组合”的概念。在定义产品时，角色更偏重“业务中的某类工作岗位”的概念。两个概念其实是一致的，但在产品定义阶段，我们先按照工作岗位的思路来梳理角色。相应的，权限在这个阶段也可以理解为该角色看到的内容和操作的功能。
梳理角色和权限也可以分为两个维度，宏观和细节。
宏观的角色梳理对应到工作中大概是调研阶段。2B产品调研更多的是对业务的调研。在我们梳理业务流程的过程中，其实对业务涉及的角色、各角色负责的工作已经有了一个大概的认识。角色、工作、流程三种是密不可分的，它们一起组成了上边提到的泳道图。泳道图这种输出在产品体验要素中的应该更靠近战略层，目的是让我们对产品给谁用、解决什么问题有明确的认识~
细节的角色和权限梳理就要精确到每一个页面的每一个功能了，所以对应产品体验要素中的范围层。
在产品设计阶段，我们要决定每个功能给谁用，不给谁用；数据给谁看，不给谁看。比如说，在资产管理中，删除、编辑的操作是不能开放给普通员工的，因为如果每个人都可以随意修改资产信息会造成整个数据的错乱。但修改和删除功能是有必要的，所以我们只把这些功能开放给管理员用户。
梳理功能权限我常用的就是两种方法：如果每个角色的差异较大，基本没有重合的工作，从角色角度分类，分别梳理各个角色的功能就可以了。
如下图：
如果角色间工作重叠较多，那么可以把角色和所以功能列成一个二维表格，然后逐一考虑这个人需不需这个功能。
如下图：
有朋友可能会有这样的疑问：2B产品的权限系统完全开放给用户，由用户去配置具体的角色、权限就好了啊，为什么还需要花这么大力气来梳理角色和权限的关系呢？
我的理解是，梳理的过程也是帮助我们理解业务的过程，是磨刀不误砍柴功。如果没有梳理清角色、权限、流程，那设计出来的产品很大概率会有这样那样的逻辑问题，后边再去修复既费时又费力。
而且我们梳理的角色权限类似一个“标准版”，是适用于大多数情况的一种配置。如果用户有个性化需求，在这个“标准版”基础上进行修改也会更加容易。
三、批量操作
亲身体验！“批量”的思想在2B产品设计中真的很重要！先来康康一些简单的批量操作功能。
（邮件的批量删除）
（批量增加需求）
（批量审批）
其实“批量”的思想在很多地方都有体现，除了上边这几个栗子，还有个非常常用的批量功能就是excel导入。那么到底什么功能需要“批量”呢？
什么功能需要批量？
我的一点点经验是可以从使用频率和功能复杂程度的角度来考虑，显然应该优先考虑使用频繁而且功能复杂的功能的批量化。
举个例子，在一个历史数据采集平台（核心功能是人工把各种存量历史数据上传到系统中）里，最最核心、高频的操作就是上传数据。但上传数据的同时还要填写一些数据信息描述，相对来说操作比较复杂。
于是除了单个数据上传外，我们设计了两种批量上传数据的方式：
方式一是先批量上传多个数据，然后分别填写描述信息；
方式二是先填写部分共同的描述信息（比如一批数据可能属于相同任务、时间和作者），然后批量上传数据，描述信息会分别赋给每个数据。
批量功能的设计套路
这小节总结一下比较常见的批量功能实现方式~
（1）导入
通过excel导入大量的数据是非常好用的批量手段，尤其是有历史数据需要导入产品时，历史数据很有可能是通过excel保存的，所以excel导入这样的方式能兼顾用户的使用习惯又能提高录入数据效率。
导入功能可以分为模板下载、文档上传和错误数据处理三个部分。有几篇文章（浅析批量导入的功能设计、批量导入的详细设计说明）已经总结的很清楚啦，推荐推荐，这里就不赘述了。
（关于模板设计还是赘述一个小tip吧，因为上边推荐的两篇文章好像没提到）如果某个字段对应到系统中是枚举类型的（类似下拉框选择的选项，选项是有限固定的），可以考虑在模板中填写时就采用下拉选择的形式，防止由于名称不规范等原因出现导入错误。
（2）列表+批量
批量操作也经常在列表的基础上实现，列表主要负责展示数据的概况，勾选多条数据后可以对勾选的数据做批量操作，比如上边举例中的批量删除、批量审批就都属于这种。
再举个栗子，在资产管理中，可以在资产列表中选择多个要处理的资产，然后同时对它们进行领用、借用、归还等操作。
（3）表单+批量
表单的批量操作一般是新增数据时候使用，比如同时新增多条数据。单条新增数据的问题主要是填写信息较多而且一次只能添加一条数据，如果新增数据是高频、大量的操作（比如添加资产一次可能要增加几十台设备）用户体验会很差。
表单的批量操作我见到过的主要是两种形式，一种是精简填写内容后把本来多个的表单合成一个大表单，所有内容默认同上，如下：
第二种形式是创建“模板”后，以模板内容为基准，用户只需要调整少量内容即可，如下：
四、拥抱个性化需求
2b产品中的个性化需求真的很让人头大，每个客户都有自己的想法，一千个客户有一千个哈姆雷特，一开始我是拒绝的。
但是客户爸爸的意见又不能不听啊，怎么办呢？
首先深呼吸一口，放松心情。个性化需求虽然恶心，但是并不是妖魔鬼怪，只要我们花点心思梳理，会发现其实是可以解决的。而且在2b业务中，客户之所以会提出这样那样看似无理的需求，实际上是因为他们的公司在业务中已经遇到了这些问题，而做产品不就是为了解决用户问题嘛！所以这样想，心态就会好很多了~
从另外一个角度看，遇到的个性化需求越多，我们的产品就不得不进行改造升级，这个过程非常痛苦，但结果是产品架构会越来越合理、产品配置越来越灵活、还可能抽象出一些以后可以复用的模块组件，总体来说解决个性化需求会帮助我们的产品越来越好~
当然啦也不是所有客户需求都是要满足的，梳理个性化需求的第一步是判断该需求是不是在我们产品的范围之内。如果一个餐厅订单系统的客户非要让我们管理采购业务，那我们只能抱歉的说这超出了我们的能力范围了（但如果有需要可以提供和采购系统的交互接口）。
剔除了产品范围之外的需求，剩下的需求可以分为三种：
可以用现有功能解决的；
可以通过配置实现的和；
可以定制化开发实现的。从研发成本角度看，1<2<3。
用已有功能解决
我们常说用户说的不一定是他们想要的，或者说用户的需求可以通过其他方式满足而不一定通过他们所给出的方案解决。用已有功能满足用户提出的个性化需求，对我们来说是最经济高效的解决方案。
举个栗子，在一个类似在线excel的产品中，客户提出想要一个excel中按颜色筛选单元格的功能，那么我们就要问为什么呢？
通过访谈和观察现有的操作习惯发现，用户会在操作过程中把有疑问的行背景设置一个颜色，然后通过按颜色筛选找出这些有疑问的行再进行进一步操作。所以可见用户想要按颜色筛选的功能不是真的关注单元格颜色，而是需要一个标志并按照这个标志进行筛选。我们的产品已经有一个标记功能，可以给行做不同的标记，再加上一个按标记筛选的功能就可以满足用户的需求了。
通过配置项解决
配置项把更大的自由和权力开放给用户，允许用户设置自己的数据字典、用户权限、业务流程等等。
（1）什么功能需要做配置？
上图我觉得讲的很明白！其实也是一个优先级的问题，多数用户不一样而且每个用户频繁变更的功能配置化的价值是最大的、优先级也是最高的；多数用户不一样但每个用户变更频率低的功能可以初始化的时候在代码层面配置好；还有少数用户的高频需求可以作为定制化的付费功能。
（2）常见的配置项有哪些？
配置项的内容可以分为产品层面和功能层面。
因为每个客户的实际情况都不一样，所以产品层面的配置很有必要。但产品层面的配置大部分在上边四象限图中属于②多数用户不一样但切换频率低的功能，所以产品初期可能没必要设为配置项。随着客户增多，每个客户都要差别初始化的成本会越来越高，这时候在进行配置化改造也可行。
前边讲到的RBAC把角色权限设置交给用户就是一种很典型的配置项，现在已经是大部分2b产品的标配了；
数据字典各公司的差异性很大，比如资产管理中资产分类、资产用途等数据，所以做成可配置项的价值也比较高；
审批流程的差异化也比较大，而且发生变动的可能性也较高（比如之前报销超过1000元就需要分管领导审批，现在改成超过2000元才需要审批），所以也经常被做成用户可配置的。
功能层面的配置针对每个小功能，粒度更细。比如在资产管理中，要生产贴在每个设备上的标签，标签上该显示什么信息呢？每个公司的规定可能都不一样，甚至每种类型的设备也都不一样。所以我们需要把标签显示信息做成可配置的，方便不同场景下不同用户的选择。
功能配置不是越多越好，配置多虽然产品灵活性好，但对单个用户来说会提高上手难度、降低用户体验（想象一些软件还没用就要配置十几项信息是非常让人头疼的一件事）。而且配置项越多开发的成本越高、周期越长，所以配置项做哪些不做哪些值得仔细思考~
通过定制化开发解决。
上边四象限中的情况③少数用户的高频功能就非常适合作为定制化开发的对象。定制化开发的成本高，通用性还低，但从商业价值上来看不一定没有意义，可以看做是我们解决个性化需求的兜底方案。
