编辑导语：如今，很多企业在B端设计中投入较多，B端的产品以及需求在近几年也变大；对于B端产品的设计，更注重功能以及用户的使用感，所以在设计方面也会更注重功能的设计；本文作者对B端产品的“增删改查显算传”七类功能展开了梳理分析，我们一起来看一下。

“Work for something because it is good, not just because it stands a chance to succeed.”

——Václav Havel, Former President of the Czech Republic

B端产品设计面向的用户群主要是企业用户，在设计过程中，要从“服务、逻辑、安全、业务”四个方面考虑，常见 的功能我们通常概括为常说的七字箴言“增、删、改、查、显、算、传”通过分析七类功能，实现业务逻辑的更加严谨，练好基本功，也避免因为PRD或者原型标注的不清楚增加沟通成本。

一、增：创建、新增、导入、添加

1. 输入方式

在做“增加”功能时，首先考虑数据的输入方式，通过输入设备输入、表单导入亦或是通过其他业务同步，在很多会员管理功能中，会员的信息是可以通过规定格式表单导入批量添加的，其他业务同步这种情况最常见的就是我们在系统中添加管理员时，我们可以直接在已有的用户列表中选择用户添加为管理员，自动生成管理员账号；

2. 权限

权限可以从两个方面考虑：

1. 谁可以增加，谁不可以增加；
2. 什么时候可以增加，什么时候不可以增加。

权限的问题同样适用于下下面的其他六类业务

比如钉钉的审批是可以设置哪类员工可以发起审批的，而在企业审批过程中，审批内容是不能新增的。

3. 明确输入字段类型

新增的内容由不同类型的字段组合而成，要对每个字段具体的类型给出明确的定义，虽然常用的字段开发人员可以自主的去设计，但是为了避免不必要的沟通，还是要尽可能的描述清楚，这关系到数据库字段存取的设计、后台逻辑的编写以及前端页面的数据输入方式以及展示形式。

常用的表字段：

• 文本（中文文本、英文文本等，可统一定义为字符串）
• 数字（整数、小数、正负数、阿拉伯数字、中文数字、罗马数字等）
• 时间、日期（yyyy-MM、yyyy-MM-DD、yyyy-MM-DD hh:mm:ss、hh:mm:ss、hh:00等）
• 字典表（一般用于定义业务状态，如结算状态字典可定义“待结算”、“已结算”）

表字段信息说明：

• 字段必填、非必填；强业务关联的数据或者其他必要信息设为必填字段；
• 字段唯一性；唯一的字段组合设置为表结构的主键；
• 字段长度；表字段长度的限制，主要是为了合理分配客户端的内存资源；
• 字段的默认值；对于固定确认的数据，可设置默认值，减少操作员的数据录入工作量；
• 字段校验；例如手机号、身份证号码、银行卡格式标注校验，可根据业务情况说明校验规则；
• 选项型，说明单选、多选；
• 专有名词解释说明，业务场景描述，协助开发人员理解文档。

4. 准确使用信息输入方式

不同的字段需要使用不同的输入方式，通常字典值使用下拉或模糊搜索、时间使用选择器、数字使用步进器以及手动填写需要的文本框，运用正确的输入方式确保因为数据格式问题导致的bug

5. 合理的限制媒体文件

合理的限制媒体文件的格式以及大小，考虑到媒体文件的上传、加载速度，兼容问题，需要对媒体文件的大小、格式进行限制说明。

目前的视频与图片音频格式的兼容性已经越来越强，规定常见格式即可，主要对大小进行限制，图片一般限制在2M以内，音频视频或其他类型文件视业务场景而定

6. 规定输入阀值/默认值/建议值

对输入内容进行合理的建议，设置默认值或建议值给予用户合理的提示，提高数据正确性，设置阀值能避免极端垃圾数据的输入

7. 设置及时完善的错误信息提示

用户输入的过程中，需要对填写的信息有及时全面的反馈，例如必填字段漏填、有格式校验的数据填写错误等.

8. 提高长表单的处理效率

• 对于较长的表单，流程分步操作，减轻用户的认知负荷和心理压力；
• 对于相关的信息进行合理分组展示，高效填写；
• 采取高效填写的方式，避免出错；例如银行卡扫码、拍照识别；小结：新增是业务开始的第一个环节，数据进入系统的源头。若新增不顺畅或者总是报错，会导致业务流程顶部断层无法继续、用户体验感极差，甚至有可能会导致项目验收失败。

二、删：删除、禁用、停用

删除也是常规性操作，既然数据有增加，就会有删除的需求，我们思考的要点和新增的思路是一样的，删除操作是否有必要？谁可以删除，谁不能删除？什么时候可以删除，什么时候不可以删除？在哪里删除（入口）？删除的内容是什么，什么内容不支持删除？怎样删除，删除关联的数据项有哪些？其中有哪些异常情况？

通常说的删除，包含两种：

1. 物理删除：真实删除，从数据库层面删除了数据，查询找不到该条数据，数据不可恢复；一般对于重要的基础数据，不建议设置删除功能，设计中要避免不可逆的操作；
2. 逻辑删除：假删除，只是从页面对数据进行了删除，数据库将数据的状态改写为“已删除”，可通过删除后撤回或者数据库备份恢复，产品设计中比较常用。

数据的前后业务关联太强，不适合设计删除功能，那应该如何对数据进行合理的处理呢？

个人理解的删除需求的存在，可能存在以下几种情况：

1. 过期无用信息：可以设计数据库定时任务，根据实际的业务情况和指定条件，定期清理垃圾数据，适用于数据量较大的情况；
2. 信息录入错误：逻辑删除或者使用编辑功能修改数据；
3. 数据状态改变，或需要中止业务：使用字典状态来限制。

三、改：修改、编辑、覆盖

改”可分为两种表现，一是用户对原有数据的修改，哪些可以哪些不可以，可以修改哪些元素，哪些元素一旦确定将不予修改等；二是对设计的修改程序实现的方式，从一种方式更改为另一种方式程序是否易于实现。

1. 能否修改

• 修改的限制条件是什么
• 用户ID不可修改。
• 用户状态，需要有权限的人才能修改。
• 哪些参数可以修改，哪些参数不可修改
• 是否支持批量修改
• 修改是否涉及数据转移

2. 保存机制

• 定时保存。
• 失去焦点时保存。
• 其他条件触发，比如网络变化等。
• 修改过程中如何取消修改
• 哪些参数可以修改，哪些参数不可修改

3. 修改是否可逆

• 修改提交有二次确认吗
• 修改后支持撤销吗

4. 修改方式

• 子页面修改
• 列表直接覆盖，最直观的EXCLE表格

列表内嵌子表格修改

四、查：查询、搜索

大范围的数据变动，导入表格批量修改。

常用的查询方式有：

1. 同步查询、组合条件查询

设置默认查询条件，常用有默认查询日期、默认状态查询，有助于用户快速获取需要的信息。

2. 精准查询 or 模糊匹配

精准查询适用于字段简短准确的数据，用户记忆成本高于模糊匹配，而后者是查询中比常用的形式。

例如根据身份证号码查询用户信息，只需要输入1991，则查询出列表中所有包含1991的身份证数据，可能查询出来的结果为：4280861996054212或者4758261991024483。

按状态值快速过滤，业务流程类比较常用。

自定义设置查询条件；展示高频查询条件，低频查询条件按钮收起隐藏，且允许自定义设置查询字段。

提供查询历史记录，有必要的情况下可根据历史查询词条的热度进行排序。

3. 定时器任务查询

比较专业的范畴，请教了一下开发同学， 我们一般说定时器是指，按照某个特定的时间间隔执行某一段命令（无法深入说明了，抱歉）；

笔者项目中目前只运用过定时器请求流水，查询余额，有机会可以写一下。

4. 查全局 or 查局部 ？

考虑到数据的安全性问题，可能有些产品设计上会限制查询的界限，限制查询出的结果只展示部分数据。

例如设置某些用户只能查询特定条件下的数据，获取过滤后的数据量。

五、显：显示、回传、样式

数据的显示，根据需要做哪些显示，显示的方式是怎么样的，不同用户的权限是否一样，不一样的话数据如何表现，这里的表现的是背后逻辑。

“显示”的 思考要点主要有：显示这个是否有必要？针对不同人显示内容是否相同，不同权限显示是否相同，不同角色显示是否相同？显示包括哪些元素？（btn、数据、文本、图表、图片、视频）什么时候显示，什么时候不显示，显示多久？数据在哪里显示，怎样显示？用户对所使用的产品的一切感受，也都是通过“显示”感受到的。因此，尽量做到：可读/易用、一致性、消除用户焦虑、及时反馈、数据安全

1. 显示方式

• 显示的层级关系（父子级嵌套关系）
• 显示内容的优先级（必要字段、重要字段、排版、呈现方式）
• 功能操作前、操作方式、操作过程展示、操作结果展示

2. 显示权限

• 敏感数据如何显示，如何配置（隐藏、权限设置）
• 功能操作前、操作方式、操作过程展示、操作结果展示

3. 显示规则

• 显示的顺序，按照创建时间顺序、修改时间、类别
• 列表的是否支持快捷操作，筛选、排序、搜索
• 列表显示样式、一页显示数量，分页显示数量，响应式布局

4. 显示边界问题

• 显示的元素数量范围，文本过多如何显示
• 内容为空怎么显示
• 哪些错误、错误提示显示方式和内容
• 哪些内容是固定的，哪些内容是服务端返回的

详细问题可参考我之前一篇中提到的设计方法：《B端产品日记——表单设计》

六、算：算法、计算

算”指计算规则，是指用系统的方法描述解决问题的策略机制。其能对一定规范的输入，在有限时间内获得所要求的输出。比如热门文章=点击数*1+评论数*2+分享数*3诸如此类的背后计算的数值；此类规则约定之后可以节约很多时间。比如，财务系统的工资条，根据考勤数据可自动算出基础工资数据，这样目的是节省人力成本。

1. 计算规则

• 多久算一次
• 参数的限制
• 数据变化的规则：实时更新、自动拉取、推送、隔天更新等
• 需要什么哪些条件
• 数量变化规则

2. 计算逻辑

• 哪些数据参与计算
• 需要什么统计
• 哪些信息需要默认保存，自动填充？

七、传：数据传输

“传”指的是数据的传递，不同服务器之间的数据传递，考虑到用户体验的时候ajax的传递，还有一些api的数值传递等。最近5G话题火热，大部分人对5G的印象是速度快。其实，5G的应用亮点是低时延和高带宽，速度快反而是其次。这里提到了“传”的三个要点：时延、带宽、速度。

1. 传输安全

• 用户可感知类：脱敏传输并脱敏显示、可执行文件加后缀等；
• 不可感知类：加密传输、接口安全、服务器隔离（敏感服务器不直接面向用户）。

2. 传输速度

• 压缩：比如微信发送图片，不勾选原图，图片就会被压缩传输；
• 预加载：比如阅读类App，用户看第一章，他就会预加载第二章。用户读起来就不会有等待加载的过程，不会打断爽感。

3. 异步加载

• 偏移动端：按模块加载并显示给用户，不要等整屏内容都加载完再呈现，避免让用户焦虑。
• 偏PC端：尽量避免整个页面刷新，减少服务器压力，和用户等待时长。

4. 传输数据要求

• 传输内容格式支持：文本、图片、视频、数据等
• 哪些需要传，哪些不需要传？手动传，还是自动传
• 传输的内容和方向
• 上传文件是否有格式限制、大小限制？是否要显示格式信息，格式提示
• 上传文件后是否显示文件名，怎样显示
• 上传后是否允许重复上传，覆盖上传，取消上传
• 是否可以批量上传，批量上传后如何显示
• 上传后是否可以删除、批量删除，如何删除？

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

题图来自Unsplash，基于CC0协议