编辑导语：表单在很多工作和项目中都会用到，在一个项目中，会涉及到大量的数据、信息等等，这时候用表单进行记录是很重要的；本文作者详细的介绍了在B端产品设计的工程中运用到的表单设计，我们一起来看一下。

人们眼中的天才之所以卓越非凡，并非天资超人一等，而是付出了持续不断的努力；1万小时的锤炼是任何人从平凡变成世界级大师的必要条件。——格拉德威尔《异类》

在过去几个月中，笔者一直在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）当搜索项不可避免得比较多时，可以进行分类展示，降低寻找成本

常用的有两种分类方式：

①信息维度

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

• 订单信息自有的属性包括：客户姓名、产品名称/编号、商品类别、价格范围、订单创建时间等；
• 任务属性则包括：订单处理状态、处理人、处理时间、处理结果等。

②条件类别维度

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

• 订单创建时间、订单失效时间、订单处理时间；
• 客户姓名、处理人姓名、商家名称；
• 订单状态、商品状态、订单处理状态等。

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

3）两个注意要点：

• 注意不同搜索条件之间的关联关系，可以利用条件联动，缩小用户选择的范围；例如必要时，产品分类和产品编号就可以设计为联动。
• 搜索条件之间是交集的关系，注意不要逻辑重复，相同搜索结果的条件，只保留一个即可；例如产品名称和编号。

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

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

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

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

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

三、表单的权限设计

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

B端产品的权限设计是相对独立也比较重要的一个模块，基于整个系统的权限体系。

在表单权限设计中，应注意：

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

功能项权限控制中，注意权限划分的粒度，配套使用的一组功能，可以通过一个权限统一控制，避免权限冗余，降低权限配置的复杂度。

例如：工单挂起与取消挂起，就可以统一控制。

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

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

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

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

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

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

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

实际工作中，由于常依据任务状态对表单进行拆分，涉及到一组表单的批量新增。

这种场景下，一组表单需展示的信息往往比较相似，在输出PRD时，可以先统一说明共性，再突出说明表单间的差异点。

例如：可以先统一说明该组表单中共有的列表字段、功能项和搜索项，再针对有差异的表单单独说明特有功能——如此，可以提高PRD的输出效率，避免重复信息分散PRD读者的注意力，便于技术人员理解和把控需求。

本文由 @非鱼 翻译发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议