关于一个优秀的2B产品设计，如何从流程、角色、批量、个性化4个重要关键词入手呢？

 一、通过流程理解业务

2B产品设计是从理解业务开始的。不论是行业垂直还是业务垂直的2B产品，大多都是强业务属性的。

要完成一项特定的业务，可能是一个复杂的过程，需要多个人协调配合。比如说资产的全生命管理是一个很长的过程：采购->入库->领用->跟踪->维护->报废，涉及到的角色可能包括：采购人员、资产管理员、普通员工，如果需要审批的话那还涉及到部门领导、财务人员等等。

可见业务有两个特点：过程复杂、角色多，那我们在理解业务时也试着从这两个角度来考虑，即流程和角色。如果把流程和角色看做两个维度，就可以得到泳道图，which is 常用的业务逻辑梳理工具。

下边的泳道图例子是一个餐厅从顾客点单到结账的流程，涉及到顾客、服务员、厨房三个角色，如果按点餐的阶段也可以分为用餐前、用餐中、用餐后。

如何梳理业务流程：从宏观到细节

复杂的业务系统梳理往往不是一蹴而就的，为了让自己的理解更系统、更有条理，可以采用从大到小，从宏观到细节的顺序分析和梳理业务流程。

比如上边举的餐厅的泳道图栗子，其实是一个比较宽泛的整体流程。在有了这个流程之后，我们可以更进一步的梳理顾客“点餐”的流程：

我一般会把流程拆分成两个部分：业务流程（宏观）和功能流程（细节）。

业务流程对应宏观的流程，如果输出PRD的话，可以放在产品概述的部分，让自己和同事首先对业务有个宏观的认识；

功能流程可以针对一个小的功能点，也可以针对“点餐”这样的功能模块，功能流程最好尽可能的详尽，应该包括各种各样的异常处理，原则是RD小伙伴能按照这个流程就开发出来相应的页面和功能。

流程另一种含义：操作流程

上边讲到的业务和功能流程更多是我们定义产品、设计产品时候帮助自己或同事理清思路的一种方式。

这里要说的另一种流程是有关用户体验的“操作流程”。由于2B业务本身的属性，要完成某些任务，过程可能涉及到多步操作，操作流程会比较长、比较繁琐。出于产品易用性的考虑，在设计这种功能的时候尽量让用户的操作流程化。

在表单设计中我们总结过让用户填写信息“分块分步”，其实就是操作流程化的思路。把繁琐的表单填写细化成几个步骤，用步骤条指明当前所处的位置和接下来要进行的操作。这样流程化的操作可以让用户很顺利的完成填写表单这个比较复杂的任务。

再举个例子，在一个数据采集产品中，采集数据人员要完成图像数据的采集工作需要完成上传数据、填写基本信息、填写业务信息、数据标注、数据校验几个步骤，这几个步骤其实并不具有严格的先后顺序（可以先填信息也可以先标注数据），所以我们设计的第一版产品中这些功能是一个一个分散在页面中的。

经过用户调研，我们发现这种设计会让用户进入页面后不知所措，不知道自己该做什么。所以改进的版本中我们把杂乱的功能都列在了一起，看起来像是一个todo list，这样即使是第一次使用产品的用户也能快速上手完成采集数据这项任务。

二、角色、用户、权限 什么是角色？用户？权限？

在上边点餐的栗子中，顾客、服务员、厨师是角色；顾客小李、顾客小方分别用不同的账号登录，分别点餐，他们是两个用户；顾客可以查看菜单、点餐，可以说顾客有“查看菜单”、“点餐”的权限。

角色很多时候对应着2B业务中的某类工作岗位，每个工作岗位负责的工作不同，我们就把他们叫做不同的角色，比如最常见的“普通用户”、“管理员”等等，都是因为业务中负责的工作不一样所以区分成不同的角色。

用户很好理解，一般每个人都有自己的账号登录系统，每个人都是一个用户。

权限呢？其实就是每个用户可以看到的东西（数据权限）、可以操作的功能（功能权限）。正因为每个工作岗位负责的工作不同，工作岗位A的工作内容不希望让工作岗位B的人看到（比如公司CEO能看到的数据和操作的功能肯定和一个普通员工不一样），所以我们需要通过权限来控制每个用户能的视野大小。

RBAC模型

细心的小读者会发现，角色就是用户和权限之间的桥梁，一个用户可以查看的数据权限、操作的功能权限是通过角色来配置的。

那我们不禁会问，为什么要通过角色建立用户和权限的关系呢？为什么不直接给用户赋予相应的权限呢？