随着消费互联网的红利减退，资本与巨头的目光逐渐聚焦到B端产品上，并致力于企业服务、提高办公效率等方面上。而B端产品大多涉及到了表单这一设计场景，于是本文将为大家仔细讲讲表单设计原则与技巧，希望对你有所启发。

B端产品的蓝海正在慢慢打开，随着C端人口红利的减退、企业业务信息化协同的发展趋势、科学技术的进步和突破，越来越多的生产场景被挖掘出来，形成一个个既特色鲜明各有不同、又有章可循有规律可依照的B端设计案例。

在过去几年中，笔者一直在和B端审核系统、质检系统、流程管理系统、业务管理后台、电销系统、CRM等打交道；接下来笔者也将工作中积累的一些经验和思考梳理汇总，希望能够输出为有用的分享，帮助到初入B端产品行业的朋友。

B端产品的蓝海正在慢慢打开，随着C端人口红利的减退、企业业务信息化协同的发展趋势、科学技术的进步和突破，越来越多的生产场景被挖掘出来，形成一个个既特色鲜明各有不同、又有章可循有规律可依照的B端设计案例。

在过去几年中，笔者一直在和B端审核系统、质检系统、流程管理系统、业务管理后台、电销系统、CRM等打交道，现在，我计划将工作中积累的一些经验和思考梳理汇总，希望能够输出为有用的分享，帮助到初入B端产品行业的朋友。

B端产品，常用于支持各类生产业务的线上化开展，具有以下的一些特性和特点：

• 抽象化线下或C端产品底层业务流程和逻辑，轻量化支持，提升业务效率
• 辅助业务标准化建设，规范流程，沉淀业务数据，为数据财富挖掘提供可能
• 形成线上知识库，高效解决业务开展中遇到的问题，支持岗前培训等场景，降低业务开展门槛

一千种业务场景，就会有一千种B端需要，因此，B端产品的能力提升，常常分为两个方面：

• 对于业务的深入理解掌握，对于行业的了解与前瞻性思考
• 产品经理的核心技能：抽象与设计

在今天的分享中，我将介绍B端产品设计中最常见的一个设计场景——表单设计，介绍表单设计的一些原则和技巧，并会列举一些典型案例。

一、表单的使用场景

表单在B端产品中，是最为常见的一种信息展现方式。不论是传统行业还是泛互联网行业的产、销、供、管等场景中，都涉及到大量的业务信息和数据，表单是最为简单直观的表现载体。表单的概念并非互联网原创，在传统行业中，纸质化的表单就占据了非常重要的工具地位，B端产品通过为表单增加属性，使得一个个任务表单能够在动作-状态机中流转，就能够实现业务的线上化开展和管理。

二、表单的基本结构

B端产品的表单，常常由以下三部分构成：列表、功能和搜索。

表单设计属于B端产品页面设计中的一种，在B端产品页面中，常见的信息元素都可以划分为：展示项和操作项。在表单中，列表项常常被认为是展示项，功能和搜索归类为操作项，其中搜索又可以理解为一类特殊的操作——不对表单信息产生影响的独立操作。

1. 列表

列表是承载表单信息的主体，单一列表常展示某种状态或某几种状态的数据。设计时注意以下三点：

（1）提取信息展示的维度

列表由字段构成，但并非所有的信息字段都需要在列表中进行展示，原则上，设计时需要调研并确定：业务上针对当前表单中，需要关注的信息维度。例如在质检场景中，产品批次、抽样数量、业务员信息等，属于质检表单中应该呈现的信息，而其他更多与质检业务无关的产品属性则不需要体现和关注。列表只展示当前页面使用者所需关注信息的最小集合——尤其是当内容不同时会引起用户不同操作的字段，应该给出更高的展示优先级。

（2）注意排序条件和分页

常见的列表排序维度有：时间维度、处理优先级维度等。

时间维度常常使用的是列表中数据生成的时间，例如订单列表中，可以依据订单生成的时间顺序展示订单，这种设计便于用户先处理创建时间早的任务，符合现实中先到先处理的逻辑，避免压单或超时。

处理优先级维度，是指系统依据一些限定条件，为列表任务增加了优先级属性，例如处理人员相同时，可以为vip客户的订单提高处理优先级，在列表中较前的顺序展示，保证先被受理，提升客户体验。

（3）设计技巧

列表表头除了展示字段名称信息之外，本身也可以扩展一些排序的属性，例如当列表默认为依据“创建时间”顺序排列时，可以增加一个这样的设计：点击“创建时间”的列名，即可将列表切换为倒序排列。这一技巧可以很好的支持用户查看最新的列表数据，简单便捷且没有理解成本，在实际业务中非常有用。

此外，当列表需展示的字段较多时，也可以对相似的字段进行合并展示，例如：总处理量、待处理量和已处理量，这三个相似且有关联的字段，可以合并展示，在字段名中通过“/”分隔三个字段名，在列表数据中展示为”3000/1500/1500″，这样可以有效地缩小列表宽度、避免字段过多带来的杂乱感。

如果担心字段合并展示会引起用户误解，还可以在字段名后方展示“？”的提示图标，鼠标悬浮即展示字段信息说明，以达到消除误解的目的。

2. 功能

当表单中通过列表展示了用户需要关注和处理的信息后，还需要依赖一些表单功能，帮助和支持用户完成业务操作，实现B端工单正向、逆向以及异常状态下的处理流转。

（1）列表功能围绕

增、删、改，3个方面设计。常见的表单功能有：查看详情、处理、驳回/删除、转单、挂起、抽取/获取、追加数据等。可以根据用户在当前表单期望完成的动作进行选择，设计时，注意关键操作的二次确认机制，从设计角度降低用户误操作的概率，避免关键操作出现错误给业务带来的负面影响。

（2）除了将表单功能独立于列表之外全局展示，还可以将功能与列表合并，在每一行列表数据后方展示对应可以进行的操作功能。这种设计适合于同一表单中包含多种子状态的任务，且需要对不同子状态任务进行不同操作的业务场景。通过对功能生效范围的调整，灵活支持业务操作。

3. 搜索

搜索其实是对列表数据的查找，实际业务中，列表数据量级往往比较大，增设搜索功能，可以帮助用户快速找到目标数据。

（1）搜索项的设计原则

在使用中，索引本身应该是0思考成本的，否则就失去了索引的核心价值。围绕这一点，有两个设计时的原则：宁少勿多和高频前置，即不要揣测用户需要，而是实际调研，只设置有限的、会被真实使用的搜索项，并且最常使用的展示位置尽量靠前。在搜索项的设计中，产品经理应当克制，数量超过10个的搜索项，使用起来就十分困难了。

（2）当搜索项不可避免得比较多时，可以进行分类展示，降低寻找成本

常用的有两种分类方式：

①信息维度

常见的有列表信息自有属性维度的分类和任务属性维度的分类，例如：

订单信息自有的属性包括：客户姓名、产品名称/编号、商品类别、价格范围、订单创建时间等；

任务属性则包括：订单处理状态、处理人、处理时间、处理结果等。

②条件类别维度

例如可以按照时间类、名称类、状态类等将订单列表的搜索项分为：

a.订单创建时间、订单失效时间、订单处理时间

b.客户姓名、处理人姓名、商家名称

c.订单状态、商品状态、订单处理状态等。

任何信息都是存在信息结构的，产品经理需要发现这些结构，并借助信息自有的结构进行组织设计，让信息本身说话。

（3）两个注意要点

①注意不同搜索条件之间的关联关系，可以利用条件联动，缩小用户选择的范围。例如必要时，产品分类和产品编号就可以设计为联动。

②搜索条件之间是交集的关系，注意不要逻辑重复，相同搜索结果的条件，只保留一个即可。例如产品名称和编号。

4. 基本结构的自定义延伸

在商业B端产品中，可以通过扩展自定义配置项，来适配不同企业、部门、业务的需要。

必要时，可以将表单列表字段、搜索项和操作项都设计为可配置，支持不同用户在一定范围内选择自己需要的信息、搜索条件，甚至可以自定义配置搜索项顺序，以及决定操作项的停/启用。

再延伸一些，可以将搜索项展示顺序设计为依据使用频率自动调整。

当然，在使用自定义设计中，要慎重而行，调研清楚必要性再做，避免杀鸡用了宰牛刀。

三、表单的权限设计

除了上述基本结构外，还需要理清表单权限。在权限设计中，常通过两个维度来考量：功能权限和数据权限。

B端产品的权限设计是相对独立也比较重要的一个模块，基于整个系统的权限体系，在表单权限设计中，应注意：

1. 表单中功能的单一权限控制

功能项权限控制中，注意权限划分的粒度，配套使用的一组功能，可以通过一个权限统一控制，避免权限冗余，降低权限配置的复杂度。例如：工单挂起与取消挂起，就可以统一控制。

2. 列表和搜索项的数据权限

通过数据权限区分不同主体、不同部门、不同业务线的列表查看范围，注意搜索时，也应保证数据权限划分有效，避免出现搜索时，列表查看范围扩大了的数据泄露风险。

四、关于表单设计的PRD如何写

常见的表单设计PRD组织方式有两种：

1. 针对单一表单逐项说明

针对单一表单，通过逐一说明列表、功能、搜索项和权限来组织PRD结构，可以清晰全面地将表单内容和逻辑描述清楚。

2. 多个同类表单，可以合并说明

实际工作中，由于常依据任务状态对表单进行拆分，涉及到一组表单的批量新增。这种场景下，一组表单需展示的信息往往比较相似，在输出PRD时，可以先统一说明共性，再突出说明表单间的差异点。例如：可以先统一说明该组表单中共有的列表字段、功能项和搜索项，再针对有差异的表单单独说明特有功能。如此，可以提高PRD的输出效率，避免重复信息分散PRD读者的注意力，便于技术人员理解和把控需求。

以上，就是关于B端产品中表单设计的一些原则和技巧。熟悉表单设计，相当于熟悉了构建B端产品最基本、最常用的控件，是每一个B端产品人应该优先掌握的。

在后续的分享中，我将介绍B端产品的状态设计、B端产品架构方法、权限设计以及报表设计，希望可以从这些方面，帮助B端新人快速建立知识体系。

如果你也有表单设计的心得，欢迎与我分享。

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

题图来自Unsplash，基于CC0协议。