B端常见功能可以概括为七个字，即“增删改查显算传”。那么在做这些具体的功能前，有哪些条件是我们需要提前了解的？这篇文章里，作者做了相应的梳理和阐述，一起来看一下。

一、功能的前置条件与后置条件

B端常见功能可以概括为“增删改查显算传”，这些功能看似简单，但也有不少坑点。在做具体的功能前，我们需要先了解这些功能的前置条件和后置条件。

1. 前置条件

1）按钮权限限制：什么人可以操作这个按钮？什么人不能操作？

这是由系统功能权限决定的，一般B端都采用RBAC模型，形成用户-角色-权限的控制链路，将不可用的按钮进行隐藏。详见主页《SaaS系统权限架构设计》。

2）业务场景限制

比如只有订单创建人可以修改订单，只有超管可以删除已审批的订单等，这些都是根据实际业务场景来定义的。那由于这类限制导致的按钮不可用是采取隐藏方案还是禁用方案还是点击报错呢？

方案1：按钮正常显示，点击报错。相对简单，不需要前端处理，统一由后端报错；

方案2：按钮处于禁用状态，鼠标悬浮显示禁用原因。交互体验更好，但需要前端参与权限判断；

方案3：按钮隐藏。不太建议采用，因为在用户看来，会怀疑是系统出了bug导致按钮不见了。

3）关联模块限制：对本模块和下游模块会产生什么影响？

在设计各个功能前，产品需事先了解每个模块间的关联关系，比如删除了订单，对哪些模块产生影响？订单本身的删除可能是相对简单的，但由于要通知到各个关联模块（下游的工单、数据统计等），工作量可能就成倍增加了，需要再重新考虑下是否值得做这个功能。

2. 后置条件

1）完成操作后跳转到什么页面？诸如回到列表/回到首页/回到上一个页面/停留在当前页面/跳转到详情页/定位到下一条数据等等。

2）描述数据流转关系以及对其他模块产生的影响。

3）确定下是否需要记录到操作日志中，供用户查阅，防止后续的扯皮等。

二、新增设计

1. 新增方式

1）手动新增：包括通用表单和自定义表单。其中自定义表单常采用仿真手法，模仿现实生活中的单据样式，比如发票、记账凭证等。

2）导入：是批量新增的一种常见方式。

3）同步：主要包括从接口API同步和RPA（使用机器人模拟人工进行自动化操作）采集两种方式。下图是两个系统关于这两种方式的应用示例。

2. 注意事项

注意事项可参见主页的以下文章，此处不再赘述：

• 单个新增：《如何提高表单的填写效率和准确性》
• 批量导入：《B端Excel批量导入设计分享》

三、删除设计

1. 删除及替代方案

1）终止：通过状态变化来达到“删除”目的，适用于需要保留过程数据的场景。

2）清除：适用于自动清理垃圾和用户不关心的系统数据。

3）编辑/撤回后编辑：适用于修正创建错误。

4）停用/禁用/作废：适用于保留历史数据但未来不可选的场景。

5）失效：跟停用相比，有明确的失效时间，适用于未来时间的停用。

6）删除：包括逻辑删除和物理删除。一般情况下系统都是采用逻辑删除，物理删除需慎之又慎。

2. 注意事项

1）删除入口：取决于是否希望用户能直观地看到删除按钮，比如公众号的取消关注，也可以视为是一种删除，但由于业务方不希望用户取消，所以入口就隐藏得比较深。

2）删除的二次确认：

① 是否需要二次确认取决于数据的重要性，比如搜索的历史记录，有些软件就不会二次确认；

② 还需考虑权限问题，即删除二次确认时是否需要高级别人员的同意；

③ 如果可恢复，需提示在哪恢复；

④ 交互上包括气泡框确认、弹窗确认、弹窗扫码确认、弹窗密码确认、弹窗验证码确认、弹窗指纹确认等。

3）是否支持批量删除：取决于数据的录入方式，一般存在批量新增的，就会对应批量删除。

4）删除提示：根据删除成功与否、删除失败的原因及解决方案、单个删除还是批量删除、是否可立即撤销等进行对应提示。

四、修改设计

1. 修改方式

1）表单修改：修改页与新增页采用结构相同的表单。

2）在位编辑：鼠标悬浮时出现编辑框或单独点击编辑按钮。

3）单行编辑：点击编辑后对表单行进行编辑。

4）批量编辑：批量编辑所有行或单独编辑某个字段。

5）分模块编辑：常出现在长表单中，只针对单个模块进行编辑。

2. 注意事项

1）修改是否需要二次确认

2）某个字段能不能修改？有没有特定的权限？比如负责人只有主管才能修改等等

3）是否支持撤销修改

4）其他注意事项：跟新增一致

五、查询设计

1. 查询概述

1）查询方式：实时查询 OR 定时查询。

• 实时查询：适用于小数据量场景，比如首页卡片查询我的客户数量等等。
• 定时查询：适用于数据量较大，关联表较多或受限于第三方数据的情况，比如挑系统空闲时间跑任务，将数据固定下来，后续历史数据直接读取已经查出来的数据，提高查询速度，降低服务器压力。

2）查询频率：多久查一次，这取决于业务场景对数据及时性和准确性的要求。

3）查询速度：查询条件关联的表太多会导致查询速度过慢，此时就要考虑是否把部分功能进行迁移，比如拆分成2个页面等等。

4）查询范围：是查全部还是局部？这取决于业务场景、用户权限和系统性能。

2. 典型应用之搜索

1）搜索逻辑：精确搜索 OR 模糊搜索 OR 分词搜索。

• 精确搜索：适用于敏感数据相关信息的查询，比如通过手机号查询特定员工的通话记录等，为避免随便输个数字1就能将系统全部通话记录都查出来，可能会设置为精确搜索。
• 模糊搜索：最常见的搜索逻辑，将包含关键词的数据检索出来。
• 分词搜索：将给定的关键词进行拆分，按稀有程度赋分，综合得分越高排名越前。

2）搜索设计

搜索流程：输入搜索词→搜索词的语义理解→搜索结果的召回和排序→前端展现。

涉及页面：搜索入口、搜索推荐页、搜索联想页、搜索结果页、搜索中转页、搜索历史页、高级搜索页。

详细内容后续会写个专题补充，敬请期待~

3. 典型应用之筛选

1）交互样式：包括表头筛选、tab页签筛选和多条件组合筛选。

表头筛选：交互与Excel相似，但如果列过多可能会忘记已筛选过的条件。

tab页签筛选：不够灵活，适用于高频筛选条件的预置。

多条件组合筛选：包括筛选条件的自定义外显、高级筛选、自定义保存筛选方案、且或条件的筛选方式等等，更多细节后续会写个专题补充，敬请期待~

2）查询触发方式：包括手动查询、回车查询、即时查询。

• 手动查询：点击查询按钮触发。
• 回车查询：适用于文本查询。
• 即时查询：选中下拉框中的选项值后即开始查询。对于用户来说减少了点击查询按钮的步骤，但对系统性能的考验会更大，需要评估实际场景后决定最终方案。

六、显示设计

1. 典型页面之列表页

表头：需考虑是否可筛选、是否可自定义展示列、是否可自定义列宽、排序、字段提示语、冻结列、多行表头、是否吸顶等。

正文：

格式：数字两位小数右对齐（涉及计算的，需考虑除数为0等特殊场景下的显示样式）；字符串左对齐；定义时间格式，如YYYY-MM-DD等；定义内容过多时的显示样式

分隔线：包括横向分隔线、纵向分隔线、无分隔线和斑马纹分隔线等

信息层级：是否存在总分层级等

合计行：常见于数据统计页，一般位于首行或末行（吸底）

分页：每个页面展示的数量条数需考虑业务的平均数和上限。比如用户在使用跨页勾选时，如果分页数量太少，则操作的次数势必较多，体验较差；但如果分页数量太大，可能计算量过大导致页面卡顿。

2. 典型页面之详情页

详情页样式的自定义程度一般都比较高，此处就不截图了，仅讨论下详情页的承载容器。

选择依据

1）根据需要承载的信息量来选择：页面>抽屉>弹窗。

2）根据页面需要的连贯性来选择：如果需要体现流程变化，则更适合用当前页刷新；如果需要展示与当前页相关的拓展信息，则更适合用弹窗和抽屉；如果要跟当前页的信息做比对，则更适合用抽屉。

3）根据是否要保留原页面内容来选择：需要保留的，选择新开页签、抽屉或弹窗。

七、计算设计

常见的计算包括偏业务侧的报表公式计算，也包括偏技术侧的算法模型。

1. 报表计算

报表计算可进一步分为有业界统一标准的（比如财务报表的计算公式）和无业界统一标准的（比如线索转化率的计算）。

1）业界有统一标准的：重点在于给出各公式的计算逻辑和涉及的参数

像这种有业内统一标准的公式计算相对来说比较简单，摸清楚竞品的整个计算逻辑就行。

当然，用户其实跟开发一样，对此类计算逻辑可能只知皮毛，一旦数据有问题，就可能质疑取数逻辑和取数过程。因此，在产品设计上需要提供清晰易懂的取数规则说明以及数据的加工溯源。

此外，为了避免数据的大规模修订，此类计算在上线前的测试必须慎之又慎，且必须拿用户的真实数据进行最终测试和验收。如果是业内有统一标准的，可以直接用竞品去测，看自己产品的计算结果是否与竞品一致。

2）业界没有统一标准的：重点在于跟业务方的口径确认

相较而言，这类没有明确标准的报表字段计算逻辑的确认更考验产品的数理逻辑和沟通能力。

这里提醒以下几点：

① 必须明确谁是能最终决定口径的人。因为此类报表可能涉及的人员众多，线下都没有达成统一，一旦上线，如果对使用方的利益造成影响，势必会受到质疑。

② 产品对整个数据库的字段需有一定的了解，需要将客户的诉求转化成数据库的表字段，绝对不能让口径存在模棱两可的可能性。如果只是用中文而不是表字段去阐述此类口径，最终开发设计出来的大概率会跟业务方的实际需求存在差异。

③ 为了避免后续的反复扯皮，所有的计算结果必须能溯源，比如点击数字查看详情。也方便业务方纠正自己原有的口径，意识到“哦~原来还有这种情况我忽略了，这个不该统计的，这个应该统计的”。

④ 最好能将统计口径形成文档，让业务方确认（包括微信等聊天软件回复等等）。

⑤ 核验计算结果。由于业内没有统一标准，建议将用户的真实数据拷贝到另一个环境中去测试，看数据结果用户是否认可或者先只是小范围上线，待用户验证后再大规模上线。

2. 算法模型

常见的算法模型包括：

1）联结学派。比如神经网络，包括图像识别、机器翻译等。此类算法最明显的问题就是模型可解释性差，模型对数据量的要求比较高。因此，神经网络算法适用于有着海量数据且对算法解释性要求不高的业务。

2）符号学派。比如决策树模型。当条件为XX的时候，走到哪个分支。

3）进化学派。比如基于强化学习的推荐算法等。

4）贝叶斯学派。比如垃圾邮件过滤系统，根据已知的垃圾邮件，推导出垃圾邮件的一些典型特征。接下来如果我们先验地知道一封邮件包含的特征和垃圾邮件类似，我们就可以做出推断，这封邮件有很大概率是垃圾邮件。

5）类推学派。比如隐语义模型，可以根据“用户×物品”矩阵，去想办法构建出“用户×偏好”矩阵和“物品×偏好”矩阵。在得到这两个矩阵之后，就可以使用线性加权求和的方法来计算用户和物品的推荐分数。

常见的应用包括推荐算法、风控算法、标签算法等。

举个例子，小红书发现页算法机制CES：CES评分=点赞数×1分+收藏数×1分+评论数×4分+转发数×4分+关注数×8分系统会根据得分决定后续是继续推荐还是减少推荐。

八、传输设计

1. 传输目的

1）确保数据源头的唯一性，不重复生产数据

比如一家公司的2个系统都要使用组织架构，那势必用1套组织架构即可；

再比如公司各个模块都会产生商品数据，但使用方不同，开票员要用商品信息开票，销售要用商品信息创建订单，会计要用商品信息做账，如果让他们各自维护一套，那么维护成本就比较高，而且数据难以互通。此时就需要确保各个模块的数据能够互通，且满足各个模块自身的需求。

2）使用别人家的数据

比如CRM系统，销售线索需要从百度、抖音等渠道接入，这就涉及到了数据的传输，需要对对方系统接口进行一定的了解，知道哪些数据能获取，哪些数据在传输上可能会有延迟，并针对延迟字段进行特殊处理。

3）复用现有的轮子，避免重复造轮子

专业的事情交给专业的人，外购还是自研产品经理一定要有自己的想法。能够复用尽量复用，即使付费购买，可能也比自研开发+后期维护的成本低。饼摊得太大，可能会被撑死。血泪的教训…当然，老板可能不听劝。

2. 传输方式

包括接口、中间件、message等。但每种方式都可能存在数据传输失败的情况，因此要考虑补偿机制。

3. 传输安全

由于有些数据比较敏感，因此必要时可进行脱敏传输。

4. 传输速度

为了提高用户体验，当然传输速度是越快越好。但这必然是有瓶颈的，所以如何平衡用户体验和传输速度呢？

1）压缩：比如微信上传图片时，如果不勾选原图，图片会被默认压缩。

2）预加载：比如阅读类APP，用户看第一章的时候，就开始自动加载第二章的内容。

3）智能加载：比如当网络条件好的时候，加载高质量的图片，反之加载低质量的图片。

4）异步处理：比如当网络条件不好的时候，如果你给某篇文章点了赞，这个操作并不会因为网络异常而失败，而是被记录了下来，显示为操作成功。等网络恢复正常后，再将此行为上传到服务器，从而完成了点赞行为。这就是让产品去解决问题，而不是让用户去解决问题。