B端产品日记:增删改查显算传

现在很多企业在B端设计中投入较多,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. 什么时候可以增加,什么时候不可以增加。

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

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

B端产品日记:增删改查显算传

3. 明确输入字段类型

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

常用的表字段:

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

表字段信息说明:

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

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

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

B端产品日记:增删改查显算传

5. 合理的限制媒体文件

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

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

B端产品日记:增删改查显算传

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

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

B端产品日记:增删改查显算传

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

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

B端产品日记:增删改查显算传

B端产品日记:增删改查显算传

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

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

二、删:删除、禁用、停用

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

通常说的删除,包含两种:

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

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

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

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

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

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

1. 能否修改

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

2. 保存机制

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

3. 修改是否可逆

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

4. 修改方式

  • 子页面修改B端产品日记:增删改查显算传
  • 列表直接覆盖,最直观的EXCLE表格

列表内嵌子表格修改B端产品日记:增删改查显算传

四、查:查询、搜索

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

常用的查询方式有:

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

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

B端产品日记:增删改查显算传

2. 精准查询 or 模糊匹配

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

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

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

B端产品日记:增删改查显算传

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

B端产品日记:增删改查显算传

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

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. 传输数据要求

  • 传输内容格式支持:文本、图片、视频、数据等
  • 哪些需要传,哪些不需要传?手动传,还是自动传
  • 传输的内容和方向
  • 上传文件是否有格式限制、大小限制?是否要显示格式信息,格式提示
  • 上传文件后是否显示文件名,怎样显示
  • 上传后是否允许重复上传,覆盖上传,取消上传
  • 是否可以批量上传,批量上传后如何显示
  • 上传后是否可以删除、批量删除,如何删除?
本文由 新媒体之家 作者: PM苏木 发布或转载,其版权均为原作者所有,如稿件涉及版权等问题,请与我们联系删除或处理。稿件内容仅为传递更多信息之目的,不代表本网观点,亦不代表本网站赞同其观点或证实其内容的真实性,更不对您的投资构成建议。未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
2

发表评论