随着消费互联网的红利减退,资本与巨头的目光逐渐聚焦到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端新人快速建立知识体系。 如果你也有表单设计的心得,欢迎与我分享。