业务究竟是什么？

很多时候既让初入B端行业的设计师感到一丝丝迷茫，因为不同的B端系统也就意味着，它的业务一定就会有所不同。比如CRM系统当中的客户生命周期管理，OA的办公自动化，特定的行业往往都会蕴含着不同的业务类型

而作为设计师，如果只了解设计模式、设计组件，不去分析设计最后的业务诉求，其实是没有任何意义。因此想要通过B端设计指南，和大家一起聊聊B端业务，以及背后所牵涉的具体逻辑。今天就简单聊聊最为常见的 审批

开始之前，还得再多说两句，因为一个系统当中，业务本身就不是独立存在的。因此在去讲述审批的过程，一定会涉及到 流程、权限、表单配置 等一些基础内容，建议可以先做初步了解，再结合文章进行阅读

审批的起源

虽然在说起源，其实我更想给大家讲清楚 审批在B端系统 当中的重要性

审批字面意思是审查并加以批示，通常指对 下级呈报上级的公文进行审查批示，报请上级审批

现如今，任何事情一定都会有分工协作，而使用审批的好处是可以

• 规范员工行为

• 提高企业运转效率

• 系统存档便于溯源

• 保护环境（毕竟减少了纸张浪费）

当然在不同的阶段的公司，对于审批的诉求是不太一样

小公司：因为审批的决策路径短、流程上都非常简单，但因此就会缺乏规范保障。比如在外出办公时，看似只需要与老板当面进行口头上的沟通即可，但是在外出出现意外时，由于缺乏外出办公的相关证据，员工的权益则很难得到保障

大公司：因为审批的决策路径长，流程上都极其复杂，因此会在多人协作下完成整个流程审批。比如想要申请购买办公用品时，会由 行政、Leader、财务 层层审批，从提交审批到最终落实可能需要十天半个月，但是这样的流程，能够确保企业在清查财务状况时，更加有理有据

审批的演变，就是从最开始的规章制度而来。比如在早期去政务机构办理各种业务时，会让你去填写各种纸质表单。在审核过程中，则需要有各个机关的盖章及批准，而这种形式正是政府对于普通市民的自上而下的管理方式

审批其实是整个B端系统的灵魂，因为在B端系统当中，企业想要使用系统的一大痛点便是 核心的管控

因此你会发现，只要一个独立的系统，一定会存在独立的审批模块。因为B端管理系统当中企业的最终目的，是管理手中的人，而审批便是最为常见的一种手段

审批在如今的B端系统当中，可以理解为它是一组消息，在这一组消息当中会有：“具体的文本、对应的附件、以及照片视频”这些内容都是辅佐 申请人 去讲诉你需要申请的内容

比如我们在申请病假时，往往需要出示 三甲医院所开设的证明，对于这个证明，如何在表单当中出现，你会发现最为常见的便是拍摄证明图片，然后上传到表单当中（这个与字段属性紧密相连，我就不做不过介绍）

审批的这组消息还会有些特殊，因为它非常重要，你可以理解为它是一则“加急消息”会提醒审批人快速的进行处理，同时会告知相关的参与人（处理人、抄送人）审批的进度、并且无论成功与否，都会在系统当中留下 足迹，因此它起到了 “追踪、通知、留存” 三个非常重要的作用，我们首先对于审批进行一个基础的拆解

审批的拆解

如果把审批单独拿出来，你会发现审批会牵涉到 发起人、处理人、抄送人

发起人：

审批的发起人，也是整个审批流程的归属人，他最关心整个审批进展

因为在发起人的角度，创建完审批事项后，可能还需要进入审批页面，完善 后续附加信息、及时了解审批状态、催促审批人的审核、处理驳回意见 等等，因此站在发起人的角度，审批需要尽可能详细的展示 当前审批的状态、完整的审批流程、驳回信息的快速操作、成功信息的必要通知

处理人

审批的处理人主要在审批过程做出决策，因此他更在乎的是审批申请内容的信息。比如 审批的信息内容、直接的审批操作、多条审批的管理

当然，在一些大型的集团企业当中，会将审批分为审批「直接处理人」与「间接处理人」（后文以 直处人、间处人 简称）

「直处人」作为审批的第一处理人，也就意味着他的意见至关重要，如果「直处人」通过过后，相对而言整条审批的通过几率会大大增加。通常「直处人」是作为申请人的直系领导居多，因此多数情况下可以理解为直属领导进行 “把关”

「间处人」作为审批的后续处理人，同样在流程当中也十分重要。但在有些情况下，比如一些偏平化管理的企业，「间处人」更多像是“权利”的象征，因为权利已经下放给「直处人」，而「间处人」起到知晓审批以及企业的规章制度要求

抄送人

审批抄送人主要起到通知对应角色的作用，因为一条审批的出现，会造成诸多影响，假设今天你需要申请事假，如何通知同部门的其他成员呢？

发送即时消息，显得过于简单；每个打电话，又有些麻烦；发送企业邮件，又怕他们没有看到

这时候抄送人会显得尤为关键

通常抄送会有企业流程上管理员配置的固定抄送人，以及发起人选择的自行抄送人 两种类型

固定抄送人 角色通常与管理员配置整个流程有关，他是角色当中 管理员 所配置的重要通知人，比如今天你的请假信息，肯定会告知行政，像这类默认的通知流程，则可以将其设为固定抄送人

自行选择抄送人 则是提供给发起人自行选择，该条审批可能会影响到的相关人群。比如就是发送给同事，让他们知晓今天你不在岗位上，因此自行选择可以增加审批抄送的灵活性

这里肯定会有很多读者会问，我选择抄送人与我发消息给同事，有什么区别么？

看似完全相同，实则有明确的区分

通过消息，将审批内容传达，本质上是你自行将内容发送给对方，对方会对于你这个消息的真实性会产生疑问？你是否通知了

而选择抄送，更为权威，更能体现你这条消息的真实性，并且整个流程都已经由领导进行批准，因此不会存在太大问题

其实审批的本质就是一组消息，而这一组消息当中，申请人 通过 表单配置 去获取需要补充的消息内容，而流程会根据企业所配置的流程方式将这一组消息进行合并转发给对应人，而审批人则需要对这一组消息进行回复“通过、驳回” 来让整个流程继续延续

审批流程

审批当中，最主要的便是流程。因为你可以通过查看流程图，去了解整个企业的组织架构、规章制度、员工管理方式

1.串行审批/依次审批

串行审批主要是指当一个审核节点通过后，才能进入下一个审核节点。如果节点驳回，则可以根据业务实际需要，配置驳回的返回路径，会有：拨回到发起人、驳回到上一个节点、或驳回之前任意一个节点 重新审批

2.并行审批

并行审批是指一个审批节点存在多个角色同时审批，这里会存在两种情况

1. 任何一个人审批通过，则可以进入下个节点，这也就是系统当中常说的 「或签」

2. 所有审批人员通过，才能进入下个节点，这也是系统当中常说的 「会签」

3. 条件审批

条件审批就是将企业当中的规章制度映射到实际的项目当中，通常就是某个审批内容会根据 金额多少、实际数量 等 进而选择哪个角色进行审批

比如销售人员在申请一个合同审批时，会根据合同金额的不同，审批人也会有所差异

• 当金额小于8000时，合同直接由财务专员进行审批，进而让流程进行快速审批

• 当金额大于8000时，合同会由销售主管进行审批，让销售主管能够掌握企业的重要合同

4.自主审批

通过发起人选定一个审批事项后，将自主选择后续的审批内容，进而实现审批的后续选择。这是一种较为灵活的审批流程，当企业尚未形成标准化流程时，自主的核心就是当发起人发起一个审批，提交时需要自行选择下一个环节的审批人。而下一个环节的审批人审批通过后，可以选择继续流转到再下一个人去审批，或者结束这个流程

审批页面梳理

审批的背后，它映射的其实是企业的一条条管理制度，而它的设计一定是要满足企业的实际需求。因为你负责的产品不是为某一家企业提供的服务（定制化产品），并且企业管理制度的变动其实是家常便饭，你需要去考虑一个通用的解决方案，这个解决方案拆解下来会分为三个内容，分别是：申请表单、流程配置、更多配置 进行讲解

1.审批表单

审批表单是最为一个“简单”的用户可配置化表单，因为现如今大多数B端产品都是以 SaaS 作为基础（如果是定制化产品 它的审批内容、流程也不会是固定不变的）也就意味着审批表单需要为企业提供“DIY”的方式，通过表单提供不同的字段类型，去构建审批的实际要求

比如在一个选择请假时，年假、事假、病假、婚假 等的要求都会有所不同

如何知道他们的差别，其实可以根据《劳动法》的相关规定 以及 各个其实的实际公司制度，进行个性化的处理

在申请婚假时，需要上传你的结婚证，以证明其真实性；在病假时，需要有3甲医院的病情证明；在年假时，则需要有你的剩余年假天数。而这些特殊诉求，其实都需要在表单当中进行各种定制化表单

当然这只是极为常见的 请假 场景，而在实际业务当中的复杂场景（更多需要将 审批与其他系统关联）一个简单的表单是没有办法进行满足

这也是很多企业会发现，无论是飞书、钉钉、企业微信，都没有办法满足其实际流程需求。又没有办法改变自身流程，只能够自研、定制化 产品，这也是为什么即便各行各业都有了初具规模的 SaaS 产品，但是还是会有很多企业愿意自行研发软件

2.流程配置

企业可以根据自身的系统流程，在流程配置当中去定制特定的流程。在这个页面的设计上，需要注意不同参与人的状态，以及复杂流程时如何才能够进行清晰的阅读，因此增加了 颜色区分（发起人、审批人、抄送人）+ 视图缩放 功能

颜色自然不必多说，整个系统需要统一，因此不能够只考虑在管理后台的颜色，是一定要在详情页当中也能过保证颜色的一致。这样才能够满足实际业务所需

视图缩放只是小小提一下，常见的视图缩放会放在左侧，至于为什么，自己稍稍揣摩揣摩

由于流程配置的属性页面会涉及很多表单的复杂逻辑，这个只能够留在我的 训练营的课程 当中进行拆解，这里就不过多赘述

3.更多配置

更多配置项则是审批在实际情况下的特殊处理，比如：申请人修改审批的具体时间、能够将审批转发给其他人、出现多次相同的审批人是否去重 等等...  其实就是将审批的设计方案进行“赋能”，去满足更多企业在实际场景当中的需求，感兴趣的同学可以去 钉钉、飞书 了解详情

结语

审批，核心还是提高企业运转效率，如果在审批之间，还需要不同角色私下反复沟通，本质上就失去了审批的意义。而审批本身，就是一个典型的B端产品 从场景到需求，进而研发功能，最后又回归场景，你设计的好与坏，落地到真实的场景当中，试试便知

业务究竟是什么？

很多时候既让初入B端行业的设计师感到一丝丝迷茫，因为不同的B端系统也就意味着，它的业务一定就会有所不同。比如CRM系统当中的客户生命周期管理，OA的办公自动化，特定的行业往往都会蕴含着不同的业务类型

而作为设计师，如果只了解设计模式、设计组件，不去分析设计最后的业务诉求，其实是没有任何意义。因此想要通过B端设计指南，和大家一起聊聊B端业务，以及背后所牵涉的具体逻辑。今天就简单聊聊最为常见的 审批

开始之前，还得再多说两句，因为一个系统当中，业务本身就不是独立存在的。因此在去讲述审批的过程，一定会涉及到 流程、权限、表单配置 等一些基础内容，建议可以先做初步了解，再结合文章进行阅读

审批的起源

虽然在说起源，其实我更想给大家讲清楚 审批在B端系统 当中的重要性

审批字面意思是审查并加以批示，通常指对 下级呈报上级的公文进行审查批示，报请上级审批

现如今，任何事情一定都会有分工协作，而使用审批的好处是可以

• 规范员工行为

• 提高企业运转效率

• 系统存档便于溯源

• 保护环境（毕竟减少了纸张浪费）

当然在不同的阶段的公司，对于审批的诉求是不太一样

小公司：因为审批的决策路径短、流程上都非常简单，但因此就会缺乏规范保障。比如在外出办公时，看似只需要与老板当面进行口头上的沟通即可，但是在外出出现意外时，由于缺乏外出办公的相关证据，员工的权益则很难得到保障

大公司：因为审批的决策路径长，流程上都极其复杂，因此会在多人协作下完成整个流程审批。比如想要申请购买办公用品时，会由 行政、Leader、财务 层层审批，从提交审批到最终落实可能需要十天半个月，但是这样的流程，能够确保企业在清查财务状况时，更加有理有据

审批的演变，就是从最开始的规章制度而来。比如在早期去政务机构办理各种业务时，会让你去填写各种纸质表单。在审核过程中，则需要有各个机关的盖章及批准，而这种形式正是政府对于普通市民的自上而下的管理方式

审批其实是整个B端系统的灵魂，因为在B端系统当中，企业想要使用系统的一大痛点便是 核心的管控

因此你会发现，只要一个独立的系统，一定会存在独立的审批模块。因为B端管理系统当中企业的最终目的，是管理手中的人，而审批便是最为常见的一种手段

审批在如今的B端系统当中，可以理解为它是一组消息，在这一组消息当中会有：“具体的文本、对应的附件、以及照片视频”这些内容都是辅佐 申请人 去讲诉你需要申请的内容

比如我们在申请病假时，往往需要出示 三甲医院所开设的证明，对于这个证明，如何在表单当中出现，你会发现最为常见的便是拍摄证明图片，然后上传到表单当中（这个与字段属性紧密相连，我就不做不过介绍）

审批的这组消息还会有些特殊，因为它非常重要，你可以理解为它是一则“加急消息”会提醒审批人快速的进行处理，同时会告知相关的参与人（处理人、抄送人）审批的进度、并且无论成功与否，都会在系统当中留下 足迹，因此它起到了 “追踪、通知、留存” 三个非常重要的作用，我们首先对于审批进行一个基础的拆解

审批的拆解

如果把审批单独拿出来，你会发现审批会牵涉到 发起人、处理人、抄送人

发起人：

审批的发起人，也是整个审批流程的归属人，他最关心整个审批进展

因为在发起人的角度，创建完审批事项后，可能还需要进入审批页面，完善 后续附加信息、及时了解审批状态、催促审批人的审核、处理驳回意见 等等，因此站在发起人的角度，审批需要尽可能详细的展示 当前审批的状态、完整的审批流程、驳回信息的快速操作、成功信息的必要通知

处理人

审批的处理人主要在审批过程做出决策，因此他更在乎的是审批申请内容的信息。比如 审批的信息内容、直接的审批操作、多条审批的管理

当然，在一些大型的集团企业当中，会将审批分为审批「直接处理人」与「间接处理人」（后文以 直处人、间处人 简称）

「直处人」作为审批的第一处理人，也就意味着他的意见至关重要，如果「直处人」通过过后，相对而言整条审批的通过几率会大大增加。通常「直处人」是作为申请人的直系领导居多，因此多数情况下可以理解为直属领导进行 “把关”

「间处人」作为审批的后续处理人，同样在流程当中也十分重要。但在有些情况下，比如一些偏平化管理的企业，「间处人」更多像是“权利”的象征，因为权利已经下放给「直处人」，而「间处人」起到知晓审批以及企业的规章制度要求

抄送人

审批抄送人主要起到通知对应角色的作用，因为一条审批的出现，会造成诸多影响，假设今天你需要申请事假，如何通知同部门的其他成员呢？

发送即时消息，显得过于简单；每个打电话，又有些麻烦；发送企业邮件，又怕他们没有看到

这时候抄送人会显得尤为关键

通常抄送会有企业流程上管理员配置的固定抄送人，以及发起人选择的自行抄送人 两种类型

固定抄送人 角色通常与管理员配置整个流程有关，他是角色当中 管理员 所配置的重要通知人，比如今天你的请假信息，肯定会告知行政，像这类默认的通知流程，则可以将其设为固定抄送人

自行选择抄送人 则是提供给发起人自行选择，该条审批可能会影响到的相关人群。比如就是发送给同事，让他们知晓今天你不在岗位上，因此自行选择可以增加审批抄送的灵活性

这里肯定会有很多读者会问，我选择抄送人与我发消息给同事，有什么区别么？

看似完全相同，实则有明确的区分

通过消息，将审批内容传达，本质上是你自行将内容发送给对方，对方会对于你这个消息的真实性会产生疑问？你是否通知了

而选择抄送，更为权威，更能体现你这条消息的真实性，并且整个流程都已经由领导进行批准，因此不会存在太大问题

其实审批的本质就是一组消息，而这一组消息当中，申请人 通过 表单配置 去获取需要补充的消息内容，而流程会根据企业所配置的流程方式将这一组消息进行合并转发给对应人，而审批人则需要对这一组消息进行回复“通过、驳回” 来让整个流程继续延续

审批流程

审批当中，最主要的便是流程。因为你可以通过查看流程图，去了解整个企业的组织架构、规章制度、员工管理方式

1.串行审批/依次审批

串行审批主要是指当一个审核节点通过后，才能进入下一个审核节点。如果节点驳回，则可以根据业务实际需要，配置驳回的返回路径，会有：拨回到发起人、驳回到上一个节点、或驳回之前任意一个节点 重新审批

2.并行审批

并行审批是指一个审批节点存在多个角色同时审批，这里会存在两种情况

1. 任何一个人审批通过，则可以进入下个节点，这也就是系统当中常说的 「或签」

2. 所有审批人员通过，才能进入下个节点，这也是系统当中常说的 「会签」

3. 条件审批

条件审批就是将企业当中的规章制度映射到实际的项目当中，通常就是某个审批内容会根据 金额多少、实际数量 等 进而选择哪个角色进行审批

比如销售人员在申请一个合同审批时，会根据合同金额的不同，审批人也会有所差异

• 当金额小于8000时，合同直接由财务专员进行审批，进而让流程进行快速审批

• 当金额大于8000时，合同会由销售主管进行审批，让销售主管能够掌握企业的重要合同

4.自主审批

通过发起人选定一个审批事项后，将自主选择后续的审批内容，进而实现审批的后续选择。这是一种较为灵活的审批流程，当企业尚未形成标准化流程时，自主的核心就是当发起人发起一个审批，提交时需要自行选择下一个环节的审批人。而下一个环节的审批人审批通过后，可以选择继续流转到再下一个人去审批，或者结束这个流程

审批页面梳理

审批的背后，它映射的其实是企业的一条条管理制度，而它的设计一定是要满足企业的实际需求。因为你负责的产品不是为某一家企业提供的服务（定制化产品），并且企业管理制度的变动其实是家常便饭，你需要去考虑一个通用的解决方案，这个解决方案拆解下来会分为三个内容，分别是：申请表单、流程配置、更多配置 进行讲解

1.审批表单

审批表单是最为一个“简单”的用户可配置化表单，因为现如今大多数B端产品都是以 SaaS 作为基础（如果是定制化产品 它的审批内容、流程也不会是固定不变的）也就意味着审批表单需要为企业提供“DIY”的方式，通过表单提供不同的字段类型，去构建审批的实际要求

比如在一个选择请假时，年假、事假、病假、婚假 等的要求都会有所不同

如何知道他们的差别，其实可以根据《劳动法》的相关规定 以及 各个其实的实际公司制度，进行个性化的处理

在申请婚假时，需要上传你的结婚证，以证明其真实性；在病假时，需要有3甲医院的病情证明；在年假时，则需要有你的剩余年假天数。而这些特殊诉求，其实都需要在表单当中进行各种定制化表单

当然这只是极为常见的 请假 场景，而在实际业务当中的复杂场景（更多需要将 审批与其他系统关联）一个简单的表单是没有办法进行满足

这也是很多企业会发现，无论是飞书、钉钉、企业微信，都没有办法满足其实际流程需求。又没有办法改变自身流程，只能够自研、定制化 产品，这也是为什么即便各行各业都有了初具规模的 SaaS 产品，但是还是会有很多企业愿意自行研发软件

2.流程配置

企业可以根据自身的系统流程，在流程配置当中去定制特定的流程。在这个页面的设计上，需要注意不同参与人的状态，以及复杂流程时如何才能够进行清晰的阅读，因此增加了 颜色区分（发起人、审批人、抄送人）+ 视图缩放 功能

颜色自然不必多说，整个系统需要统一，因此不能够只考虑在管理后台的颜色，是一定要在详情页当中也能过保证颜色的一致。这样才能够满足实际业务所需

视图缩放只是小小提一下，常见的视图缩放会放在左侧，至于为什么，自己稍稍揣摩揣摩

由于流程配置的属性页面会涉及很多表单的复杂逻辑，这个只能够留在我的 训练营的课程 当中进行拆解，这里就不过多赘述

3.更多配置

更多配置项则是审批在实际情况下的特殊处理，比如：申请人修改审批的具体时间、能够将审批转发给其他人、出现多次相同的审批人是否去重 等等...  其实就是将审批的设计方案进行“赋能”，去满足更多企业在实际场景当中的需求，感兴趣的同学可以去 钉钉、飞书 了解详情

结语

审批，核心还是提高企业运转效率，如果在审批之间，还需要不同角色私下反复沟通，本质上就失去了审批的意义。而审批本身，就是一个典型的B端产品 从场景到需求，进而研发功能，最后又回归场景，你设计的好与坏，落地到真实的场景当中，试试便知

先看目录，大家按需取用，当然更建议全文阅读（全文7756字，建议阅读20分钟）

大部分设计师应该都遇到过这种场景：在做设计前并没有考虑到加载，但在进行还原度走查或者验收的时候才发现，由于某些页面数据请求较慢，导致在页面中会出现空屏状态。这时才想起需要在这些页面添加动画来承载页面的过渡。

归根结底是因为设计师在设计过程中，更多关注页面本身，而很少去思考页面在呈现过程中何时会出现白屏状态，都是后知后觉去补充完善。加载作为必备的一环，却总是被忽略。目前很多B端产品在这方面都没有一个系统合理的规划，导致系统的加载体验缺失或者不统一。

因此希望这篇文章能够讲清楚中后台加载出现的场景和规则，对需要深入了解加载以及在制定加载规则的设计师朋友们带来一些帮助。

加载通俗来讲就是用户从触发页面操作，到页面最终呈现的一个等待过程。这个过程始终存在不可避免，只是时间有快有慢。快的加载只需要几百毫秒就结束，但慢的加载就可能会达到几秒甚至十几秒，让人产生焦虑。

而为什么会有如此大的差距，这就需要从页面渲染的整体过程来进行说明。当我们从浏览器输入网址，再到我们看到完整页面的这个过程，网页到底经过了哪些步骤呢。经过资料查询和与前端确认，整体过程可以阐述如下：

从这里我们可以看到页面的呈现是程序经过了一系列操作才最终呈现到我们面前的。在这里可以将其简化为四个阶段：用户操作功能→页面向服务器发送请求→服务器接受并返回数据→页面呈现。

而决定整个页面加载快慢的就在于请求与数据这里。一般我们可以将页面的数据分为2种类型：静态资源和动态资源。

静态资源：前端的固定页面，这里面包含HTML、CSS、JS、图片等等，不需要查数据库也不需要程序处理，直接就能够显示的页面。可以简单理解为你页面上的固定字段和结构。这种页面一般加载速度比较快，比如我们看到的展示型官网一般都是前端写好的静态资源。

动态资源：而对于页面上的动态变化的，需要程序处理或者从数据库中读数据，能根据不同的条件在页面显示不同的数据，比如表格数据、统计数据等称为动态资源，这种都需要调用后台接口来进行返回，因此加载速度相比于静态资源就会更慢。

而它们的区分点用下图可以表示：

可以看到静态资源基本是直接返回，而动态资源还需要连接数据库调取资源，尤其是在遇到数据库调取较慢时就会花费更多时间。而我们加载缓慢的大多数问题，也基本上更多出现在动态资源的获取上。

当我们清楚加载形成的原因，接下来要做的就是在需要加载的地方对其进行处理。这也是在设计过程中我们经常遗漏的地方。我们先看一下目前常见的2种处理方式：「默认处理」和「使用进度指示器」

2.1程序默认处理方式：直接显示

当我们对加载过程不进行任何处理时，程序就会以默认的方式进行-即根据资源获取速度一步步呈现。可以看到嘿店后台的处理过程就是一种默认处理方式：

但是这种做法就会导致我们在页面加载过程中会出现空屏状态，比如上图切换到概览时出现了空屏状态，尤其是当遇到了网络缓慢的情况，会造成在加载时页面停留在当前状态下不动，往往会让用户陷入到「系统故障」的错觉。

2.2通用处理方式：进度指示器

这个名词说起来可能比较陌生，它指代的就是我们平时经常看到的加载动画、骨架屏或者进度条等。进度指示器的作用就是告知用户当前页面并没有故障，而是正在读取数据。

通过添加进度指示器来对空屏状态进行承载，能够减轻用户的焦虑感。目前很多B端产品更通用的形式是添加动画来过渡。

但是在体验过程中很容易发现一个问题，就是在产品的整体加载过程中，某些空屏状态是没被加载动画覆盖到的。当这些没被覆盖到的加载过程过长时，很容易出现焦虑感。比如神策数据在左侧列表切换时的加载过程就没被覆盖：

想要更全面的把加载动画覆盖到所有页面，我们就需要弄清页面在哪些状态下会出现空屏状态，从而制定统一的加载动画规则。这个问题可以先思考一下，后面解答。

在制定统一加载规则之前，我们需要明确一个概念，就是加载的模态与非模态。

3.1模态加载

模态加载的含义就是当前加载会中断用户其余操作，用户在这个期间只能等待加载而不能进行其他操作（有的模态会提供取消按钮）。如果你的页面涉及到以下2种情况，可以考虑使用：

1.用户当前的操作本身不能与其他操作同时进行。比如系统更新，或者工具类的导入导出相关操作，我们只能等待更新、导出完成才能继续进行后续的操作。这时候可以使用模态加载来承载，比如protopie的导入操作；

2.当用户进入到一个全新的页面时，这个时候页面什么都没有，我们只能等待页面加载完成才能进行后续的操作，因此在这种情况下也可以采用模态加载，比如我们刚进入Asanan产品页面看到的首屏加载动画：

除了上述2种情况外，你也可以根据你的业务场景来进行模态加载的选择，但建议是尽量少用模态加载，其会对用户的打断和干扰性比较强。

3.2非模态加载

非模态加载的话，这种加载通常只会出现在需要加载的部分，不会中断用户其他操作。对用户干扰比较小。比如我们常见的功能切换加载、数据筛选加载等都属于非模态加载。

非模态加载相比于模态加载会更轻量，因为用户随时都可以打断也不会影响到其他操作。因此建议在大部分情况下都可以使用非模态弹窗来进行承载，比如飞书的左侧栏切换操作：

接下来我们进入正题，在这里我从加载的角度将网页整体加载过程分为呈现加载规则和操作加载规则。

我们先谈页面呈现规则。前面已经明确加载产生的原因和类型后，我们就可以开始为我们的产品制定统一的加载规则，以保证后续页面加载的一致性。

4.1 页面的加载过程拆解

在拆解页面的加载过程前，我们进一步阐述之前提到的渲染原则，从前文中提到最后会经过「解码」和「渲染」2个步骤，这也是决定了我们看到的页面的最终呈现顺序：

1.页面的渲染顺序

我们看到的页面是由HTML、CSS和JavaScript来进行构成的。HTML可以看作最简单的框架、CSS则是赋予了框架样式，JavaScript则是负责页面中的交互(当然JS也可以控制样式，这里只描述主要功能)。

页面在「解码」阶段，拿到的HTML文档会被解码为DOM树，同时将CSS文件解析成CSSOM，这两者结合后一起渲染页面，JS一般是在最后渲染。所以逻辑上就是框架和样式一起渲染，最后渲染交互。视觉的角度来讲就是先看到元素样式，然后才能进行对应操作。

2.页面呈现的视觉顺序

由于浏览器渲染顺序一般会根据代码的顺序进行渲染，而代码在页面中的构建一般也是按照页面的上下和左右的顺序去写的，因此我们看到的页面的视觉呈现顺序也是遵循从上到下，从左到右。

所以几乎所有的产品都是先看到顶栏，然后左侧边栏，然后其他内容。因此我们可以通过这个原则来拆解对应的页面，我们按照页面常规结构可以将其分为三个加载部分：顶栏、左侧导航栏、内容区域。而其加载顺序如图所示：

当知道对应页面的渲染顺序后，我们就能够清楚在页面渲染的过程中哪些地方会出现空屏了。因此将页面加载过程拆解为如下顺序：

我们的加载动画需要承载的就是上述这些白屏的地方，从而将加载细化为三种场景的拆分：全局加载+局部加载+内部加载。如图所示：

通过这三种加载就可以涵盖页面所涉及到的所有部分。接下来详细阐述一下这三种类型的定义和用法。

4.2 全局加载

如上图所示，全局加载的目的是为了覆盖用户从输入网址到页面的资源渲染的这个中间过程的空屏状态而存在的。而这种状态会涉及三种场景：

1.通过网址进入到一个新的页面时；

2.通过鼠标右键或网页刷新按钮对该页面刷新时；

3.通过页面操作需要新开页面时。

该全局加载的动画构成为：

1：覆盖整个页面的加载，由纯白色+加载动画构成；

2：加载类型为模态加载，因为用户在这种页面状态下并不能进行其它操作。

但在这里我们需要注意全局加载的开始和结束时间：

开始时间：当进入页面时立即呈现加载动画；

结束时间：当页面加载出顶栏的时候，此时停止加载。

为何要这么处理结束时间，原因其实图中已经给出了。这里再解释一下原则：只要有页面资源返回，我们的全局加载动画就会结束，随后启用局部加载来承接后续的状态，避免用户在当前状态长时间等待。而顶栏在一般情况下都是最先加载出来的，所以以顶栏出现作为结束全局加载的标准。当然如果你的结构没有顶栏，可以以左侧栏来作为结束标准。

4.3 局部加载

局部加载是用在页面整体框架加载的过程中，承接在全局加载后。局部加载的使用场景可以概括如下：

1.顶栏加载结束后，用在剩余框架的加载效果（具体体现为左侧边栏和右侧内容区域）；

2.对于涉及到局部页面的切换操作都会进行局部加载（比如左侧边栏的切换）；

光看文字可能不是特别清晰，在这里可以举一个动态的例子来帮助理解：

上述展示的是在页面呈现的时候一个完整的局部加载。在这里需要注意的是我们首次渲染和第二次渲染在加载动画上是可以有区分的，可以通过程序控制让这种加载动画只在初次加载时出现。

第一次加载时出现是因为我们需要有加载动画来承接框架首次加载的空屏时间：

但第二次的时候由于有缓存（缓存会加载我们的静态资源，能够让我们的页面框架在第二次时更快显示），这样在读取框架时基本不需要加载，我们就可以通过程序来直接去掉其中的局部加载动画，直接显示框架来进行呈现。

目前在飞书和钉钉等B端产品后台均采用了这种处理方式。可以看到图中我在第一次切换到角色管理时是有碰撞小球的局部动画存在的，而第二次再次进入时则直接出现框架。这样既能够保证加载动画能够覆盖所有的空屏状态，又避免了局部加载动画的频繁出现。

4.4 内部加载

内部加载是用在页面内部不同模块数据间的加载。当框架都已经加载结束，但某些数据由于接口比较慢，此时还没有返回，这时我们就可以用内部加载来进行承载。这应该是我们更常见的加载情况：

在进行内部加载的时候，需要注意，内部加载的时候一般标题是存在的，因为标题基本都是固定的，所以能够很快被拉取。比如Zoho的内部加载，加载时标题已经出现了：

通过这三种类型的加载，能够覆盖从用户输入网址，到页面渲染完成这个页面呈现过程中的全部加载场景。

说完页面的呈现规则，再谈页面操作加载规则。页面的操作其实对应的是页面控件的反馈。而我们的常用的控件比如有按钮、tab切换等。我们不仅需要考虑控件本身的加载状态，而且需要考虑到控件影响的其他页面范围。

5.1需要考虑控件本身加载

控件的加载并不是随时都需要，我们要根据实际的数据量大小及业务场景来选择性使用。目前我们需要考虑的控件及其加载状态主要有如下：

比如图中的按钮的加载状态是必备的，在很多场景下都会用到。但是下拉列表和级联列表，在一般的场景下都不太需要进行加载，当遇到列表中的数据特别多或者调取特别慢时就可以考虑为其加上加载状态。

5.2当控件操作会影响到页面其他元素

这种控件比如日期筛选、表格筛选或者保存等操作，当你切换筛选条件后所有与其相关的页面元素都会发生变化。在这种情况下我们需要考虑到被影响元素的状态。目前的设计实现上有两种做法：

1.被影响元素不可被操作，且该区域有遮罩+加载动画来覆盖；

2.被影响元素可进行操作，无任何动画，但操作并不会影响之前提交的结果；

这两种方案一种是利用遮罩防止用户无效操作，另一种则是保持了足够的操作自由性。个人在这里更倾向于处理方式1，我认为被影响的元素是需要有遮罩+动画的，来避免用户在加载期间对其进行无效操作，比如示例中方案2后面修改的名称是没有被系统保存的。

需要注意的是如果在产品中使用方案1，我们的遮罩区域只需要覆盖被影响的元素就可以了（保存这种可以将按钮一起覆盖），比如通过筛选导致图表数据发生变化，这时只需覆盖图表区域，而不用覆盖筛选区域。这样的好处是当某些筛选数据出现加载过慢问题时，用户可以通过切换筛选项来打断当前加载。

上述描述的操作都是针对于当前页加载。当控件导致页面刷新或者跳转时，则整体遵照页面呈现的规则进行加载。

上面阐述的加载已经完全能够覆盖我们页面整体的加载，但是还是需要提及一下骨架屏和进度条这两种加载形式。

先说骨架屏。实际上骨架屏的使用效果体验是优于加载动画的体验的（骨架屏的加入使用会让用户感觉网页出现的更快）。那么为什么在大部分的B端业务页面中没被用到呢，主要有2点原因：

1.每种骨架屏都需要进行对应的定制开发，需要与加载后的页面框架保持一致，这会增加了开发成本。

2.中后台的业务界面对来说固定结构的页面会较少，这对于骨架屏的使用机会就相对较少。

个人认为在前期可以以统一加载体验为主，在后期业务相对成熟后，可以针对固定结构，通过骨架屏的使用优化加载体验。

再说进度条。我理解的进度条的使用条件：对于加载时间较长的规定场景可以考虑用进度条来承载，比如我们常见的游戏加载中进度条就用得比较多，因为游戏一般资源比较大。还比如figma在进入设计文件的过程中也采用了进度条加载也是因为设计文件可能会很大。

进度条在特定场景下能够缓解用户焦虑，让用户知道进展。但进度条在多数情况下都抓取不到程序的真实进度，这也会导致有时候我们看着加载到99%，那最后的1%迟迟加载不出来的的原因。目前很多中后台产品对于进度条加载使用相对较少的原因，很大程度是没有那种加载特别长的场景。

因此这两种加载场景的使用会更加定制化，如果需要使用请根据具体的业务场景来进行选择。

如果把加载动画等比作页面加载的外在，那么缓存和加载策略则是页面加载的内核，合理使用缓存和加载策略可以从根本上提升我们页面的加载速度，让用户更快速地看到页面。

7.1 关于页面的资源缓存

大家肯定听过缓存这个概念，前后端都可以使用缓存。缓存就是数据交换的缓冲区（称作Cache），是存贮数据（使用频繁的数据）的临时地方。在这里主要讲一下浏览器缓存：

从这张图可以看出，服务器在请求数据时，会进行缓存的判断，如果有缓存则首先读取缓存，如果没有则从服务器中拿取。调取缓存会在很大程度上提升页面的加载速度，缩短了从服务获取数据的时间。通常浏览器会主动对页面的静态资源进行对应的缓存，这也就解释了我们第二次进入页面会比初次进入页面时加载快的原因。

但程序其实也可以对动态资源（也就是需要从数据库等拿到的资源）进行缓存的，并且可以设置缓存的过期时间（比如设置过期时间为1小时，那么1小时过后就会重新拉取新资源）。对于某些动态资源拉取过慢并且更新频率不高的我们可以采用动态资源缓存的策略，从而提升整体的页面加载体验。

7.2 加载策略的正确使用

现阶段我们常用的主要有下列6种加载策略：

加载策略的本质就是通过对应的加载设置来缩短产品与服务器交换数据的时间，接下来我们详细看一下每种加载策略的具体使用策略：

7.2.1懒加载

懒加载是当内容落入视窗被用户看到时，才会进行加载。这种比较节省资源和减轻服务器压力。对于当前页面内容很多的可以采用这种加载策略。而这种加载策略的设计，能够让用户更快看到当前屏幕内的内容，减少等待时间。

比如苹果官网的加载策略就采取了这样的一种方式。我们可以看到右侧的资源只有在我们向下滚动出现在屏幕中时才会进行对应的加载，这样能够保证用户在进入网页第一时间看到首屏内容，并且用户几乎感知不到这种加载延迟。

7.2.2预加载

预加载是在页面空闲的时候就把用户即将用到的资源加载完存到缓存中，等用户需要使用时，通过缓存直接调用呈现。比如用户在看A页面的时候，就可以通过预加载来准备用户需要的B页面资源。当用户需要B页面的时候，立刻就可以呈现。

比如某些页面在实际中加载比较慢，这个时候就可以考虑是否用预加载的策略来提升网页整体加载速度。比如知乎的视频和文字在都进行了对应的预加载。即使当你处于断网状态（图中我将页面网络切换为断开状态），可以看到依旧可以点击全文进行查看和视频的部分预览。

7.2.3分步加载

当页面中有文字和图片时，优先加载占用网络资源小的，比如文字资源，然后再进行占用资源较大的加载，比如图片资源。通过分步加载也能有效减少页面等待时间。比如大众点评等图片很多的网站往往会采用这种加载策略。

7.2.4分页加载

分页加载是我们目前很常见的方式，比如我们常用的百度和谷歌等搜索引擎都是使用的分页加载，分页适用于数据量比较大的内容，比如表格数据或者大数据搜索场景可以使用。

分页加载可以理解为当前获取到100条数据，但是将100条数据分别拆成5页每页20条数据提供给用户，这样也可以让用户减少等待时间：

在目前还有一种滚动分页的加载，就是不提供视觉上的分页，而是当用户进行滚动时，自动加载一定数量的内容，这样从用户的视角看就是一个连续不间断的数据展示。比如一些资讯类的网站就是采用的这种加载策略，有的也把这种滚动分页的方式称为自动加载。

7.2.5延迟加载

这里讲的延迟加载更多的是一种防护加载机制，一般延迟设置的时间为300ms。这里的延迟加载有2种使用，第一种多用于搜索，通过延迟加载能够让用户更好进行连续输入，避免搜索结果被高频率刷新，同时缓解服务器压力。如下图，可以看到我在输入1后会有个延迟才出现加载列表，并且我在连续输入12306的过程中是没有对结果进行更新的，当我输入完后才更新。

第二种则是通过延迟加载可以更好防止反复操作。当用户在同一组件上面进行切换时，如果该操作小于300ms,则只记录最后的点击操作。这种情况可以用在我们的表格翻页和开关等状态上，防止用户疯狂点击导致数据反复请求和屏幕闪烁的情况。我们可以通过下面这个组件演示例子来进行对应的感知：

延迟加载更多用于上述2种场景，对于其他情况的加载，直接加上就可以了，并不需要刻意设置延迟。

7.2.6后台加载

这里想要表达的含义是当用户在操作后，客户端立即反馈操作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待。无论在什么网络环境下你基本上都能操作成功。比如微信的朋友圈发布就是这样的操作，即使你在断网的情况下都能够立刻发布，但实际上这个时候并没有发送成功，还需要上传到服务器后才你的朋友们才能看见。

这样的好处是用户使用起来非常流畅，但是坏处就是，当操作不成功时，用户并不能及时进行感知，仍然以为操作已经成功了。所以这种场景我们也需要根据场景进行对应的判断和选择。对于复杂的B端场景个人建议慎用或者不用这种操作，毕竟很多发布的功能会同时影响很多业务线。

这里就拿微信的朋友圈发布来进行举例，下方手机状态都为断网状态，可以看到微信立即发布，而贴吧在这种状态下提示网络错误。

通过这些加载策略的选择性使用，能够在特定环境下提升我们系统的整体使用体验。因此我们需要对这些加载策略有一个比较全面的认识，这样我们不仅知道加载慢的原因，还可以利用加载策略去提升页面性能。

在整体的加载过程中，别忘了考虑加载异常的情况。在通常情况下我们会我们会遇到网络速度过慢或者突然断网这两种状况让页面一直加载不出来，这时我们需要考虑对长时间的加载过程进行处理。

通常做法是我们要对加载状态有一个最长时间的限制，一般为加载不超过10s，超过最长时间后就进行异常状态显示（提示语+刷新按钮）。这样用户可以选择重新加载或者离开此页面，而不是一直等待。

在这里还想到一点，就是对于编辑页面，我们应当加入网络连接是否异常的判断，比如当进入到编辑页面后，如果遇到网络断开，需要在页面的顶部加上常驻提示条【当前网络连接断开】，这样用户能够及时进行察觉并修复。避免在无网环境下继续输入。这对于某些需要输入很多内容且并不提供本地保存的页面来讲是非常有必要的。

加载在设计中是非常容易被忽略的模块，因为在大部分情况下网络速度都较快，人们很难深刻地感受到加载过程。但加载却在产品运行中起着不可或缺的作用。通过这篇文章想要告诉大家的有几个点：

1.我们需要明白加载为什么会出现，这个过程是怎么样的；

2.加载的通用处理手段是怎么样的，非通用处理方式有哪些；

3.通过缓存和对应加载策略能够让页面加载速度有本质上的提升。

这样当我们在页面上遇到加载速度慢的问题时，在为其加上动画承载过渡的同时，还应该思考其加载缓慢背后的原因，是因为数据量太大还是加载策略的相关问题，是否可以将其进行懒加载或者分步加载，这时我应该去找前端或者后端如何沟通。从源头上解决加载时间长的问题，才是后续产品设计过程中的长久思路。

最后，虽然进行了很多资料查询和技术沟通，但文章不可避免会出现不当之处，欢迎进行反馈。