B端产品页面设计:表单设计

表单在很多工作和项目中都会用到,在一个项目中,会涉及到大量的数据、信息等等,这时候用表单进行记录是很重要的,今天我们谈谈在设计表单过程中需要了解的知识和遵循的原则。

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读者的注意力,便于技术人员理解和把控需求。

业界动态

尼尔森十大可用性交互原则,用页面来举个例子

2020-9-2 13:20:37

业界动态

三位B2B CMO聊大半年的得失,下半场真正考验在这里

2020-9-2 14:18:32

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索