本文介绍了APaaS产品中的数据模型（表单设计器）的作用和实现方式。通过表单模型和数据表格容器，可以实现用户友好的数据输入和验证，以及数据的存储和展示功能。

一、为什么要讲

做了近四年的SaaS产品经理，我想讲讲为什么需要APaaS，因我们公司做的是面向建筑设计领域的协同办公平台，我们的核心是围绕以项目全生命周期为主，提供涵盖项目经营管理系统（项目立项）、项目管理系统、协同设计系统（CAD）、电子出图系统、电子档案管理系统、出版管理系统。

过程中遇到以下两个问题：

• 对企业自身来讲，100家企业会有100种业务场景和流程，所以说无法通过简单的SaaS系统去进行适配，而企业一般也不可能因为系统的引进，从而去改变自身的业务流程。
• 这些企业中有些需求已经通过其它厂商解决了，会形成数据孤岛。比如考勤用钉钉、HR用薪人薪事、审批用泛微、项目管理用我们的、财务系统用金碟。

1. 实现思路

1）每个企业都有其独特的业务流程和需求，作为垂类领域SaaS平台，就需要进行面向企业场景的定制化改造。

定制化改造的核心是贴合企业的业务流程，即SOP（标准作业流程）。通过对企业的业务流程进行深入理解和分析，可以通过表单的编排和流程的编排来实现系统的构建。

这样的定制化改造可以满足企业对业务信息录入、OA系统、HR系统、工单系统等各种需求。使用APaaS（应用平台即服务），可以实现面向企业定制场景的基础系统的快速搭建APaaS提供了表单的编排和流程的编排功能，使企业能够根据自身的业务需求和流程特点，快速构建定制化的系统。

此外，APaaS还提供了分析看板和权限管控等功能，进一步增强了系统的灵活性和可定制性。

2）设计原则是：各大模块可独立存在，也可以组装在一起使用。

支持API和excel从各大平台直接接入至平台。市场角度来说先渗透进企业内部，同时也实现数据一致性。

2. APaaS（Application Platform as a Service）开发的核心价值可以总结为以下几点

1）产出可复用模型，快速开发并提升部署效率

APaaS开发平台提供了一系列的可复用组件、模块和功能，开发人员可以通过拖拽、配置和定制的方式快速构建应用程序。

这些可复用的模型和组件可以被多个应用程序共享和重复使用，大大缩短了开发周期，提高了部署效率。

2）降低使用门槛，敏捷适应业务需求

传统的应用开发需要开发人员具备一定的编程和技术能力，而APaaS开发平台通过提供可视化的界面和简化的开发工具，降低了应用开发的技术门槛。

非专业开发人员也能够通过APaaS平台进行应用开发，快速适应和响应业务需求的变化。

3）打通数据孤岛

企业中常常存在着各种数据孤岛，数据存储在不同的系统和应用中，互相隔离且难以共享。

APaaS开发平台提供了数据集成和连接的能力，可以通过简单的配置和绑定，将不同系统和应用中的数据进行整合和共享，实现数据的打通和流动。

除了以上核心价值，APaaS开发还具备一定的灵活性和通用性。开发者可以根据自身需求自由定义前端界面组件、数据源绑定方式、数据模型、业务逻辑和工作流等，甚至可以进一步修改源码，定制符合特定业务需求的应用程序。

这种灵活性和通用性使得APaaS开发能够适应不同行业和企业的需求，提供个性化的解决方案。

总体而言，APaaS开发的核心价值在于提供快速开发、部署和适应业务需求的能力，通过产出可复用模型和打通数据孤岛，帮助企业提高效率、降低成本，并加强业务的灵活性和可持续发展能力。

二、那我们来讲讲什么是数据模型

前面提到了APaaS平台通过数据模型+角色权限+视图+流程可以快速产出可用模型。那么今天就来说说，其核心之一的数据模型。

数据模型是一种概念性的表示，用于描述现实世界中的数据、数据之间的关系以及数据的属性。它是对数据的组织、结构和语义的抽象和规范化。数据模型通常用于设计和构建数据库系统、信息系统和软件应用程序。

常见数据模型：

• 关系型数据模型（如关系数据库）：使用表格和关联关系来组织数据。
• 层次数据模型：数据以树状结构组织，每个节点可以包含多个子节点。
• 面向对象数据模型：数据以对象的形式组织，包括属性和方法。
• 文档数据模型：数据以文档（如JSON、XML）的形式组织。

关系型数据模型

关系型数据模型对应的数据库自然就是关系型数据库了，这是目前应用最多的数据库。（关系型数据库如MySQL、Oracle、Microsoft SQL Server）

定义：关系型数据模型是一种基于关系（表格）的数据组织方式，其中数据以二维表格的形式存储。它通过定义表格、行和列之间的关系来表示数据。

每个表格代表一个实体，每行代表一个数据记录，而每列代表一个数据字段或属性。

关系型数据模型具有以下特性：

• 表格结构：关系型数据模型使用表格作为数据存储的基本单位。每个表格由列和行组成，列定义了数据的属性，而行表示数据的具体记录。
• 实体关系：关系型数据模型支持多个表格之间的关联关系。这些关联关系通过定义主键和外键来建立，以实现表格之间的数据关联和查询。
• 数据一致性和完整性：关系型数据模型通过定义约束条件和规则，确保数据的一致性和完整性。主键约束保证每行数据具有唯一标识，外键约束保证表格之间的关联关系正确。
• 灵活性和扩展性：关系型数据模型具有良好的灵活性和扩展性。它可以适应不同类型和结构的数据，支持添加、删除和修改表格、列和记录等操作。
• 数据独立性：关系型数据模型具有数据独立性的特性。这意味着数据的逻辑表示与物理存储相分离，可以在不影响应用程序的情况下进行物理存储结构的改变。
• 查询语言：关系型数据模型使用结构化查询语言（SQL）作为数据操作和查询的标准语言。SQL提供了丰富的查询功能，包括选择、插入、更新和删除数据的操作。
• 数据安全性：关系型数据库提供了安全性机制，如用户身份验证、访问控制和数据加密，以保护数据免受未经授权的访问和恶意操作。
• 并发控制：关系型数据库支持并发控制机制，以处理多个并发的事务。并发控制确保在多个用户同时访问和修改数据时，数据的一致性和隔离性得到保证。

这些特性使得关系型数据模型成为企业内部信息化产品中常用的数据模型，适用于许多应用场景，如数据管理系统、企业资源规划（ERP）系统、客户关系管理（CRM）系统等。

三、关系型数据模型的实现方式——数据表格

关系型数据模型使用数据表格来表示实体、属性和它们之间的关系。

1. Microsoft Excel≠数据表格

Microsoft Excel 不是像 MySQL 或 Oracle 那样的传统关系数据库管理系统 (RDBMS)。

虽然 Excel 确实具有一些类似于关系数据模型的功能，例如将数据组织到表中以及定义表之间的关系的能力，但它并不完全遵守关系数据库的原则。

Excel 主要是一种电子表格应用程序，允许用户以表格格式存储和操作数据。 它提供数据输入、计算、格式化和可视化的功能。 虽然它可以处理结构化数据并执行基本数据分析，但它缺乏关系数据库的一些关键特性，例如数据完整性约束、数据查询能力（如 SQL）以及对复杂事务的支持。

Excel 通常用于个人和小规模的数据管理任务，但它可能不适合处理大量数据或复杂的关系数据模型。 对于更高级的关系数据库需求，通常会采用专用的 RDBMS 解决方案。

2. 数据表格的构成要素

数据表格通常由以下要素构成：

• 表名（Table Name）：数据表格在数据库中有一个唯一的名称，用于标识和引用该表格。
• 列（Column）：数据表格由多个列组成，每一列代表一个属性或字段。列定义了数据的类型、长度以及其他约束条件。
• 行（Row）：数据表格中的每一行表示一个数据记录或实体，也称为元组（Tuple）。行包含了与列相对应的实际数据值。
• 主键（Primary Key）：主键是用于唯一标识每一行的一列或一组列。主键的值必须是唯一的且不为空，用于保证每一行的唯一性和检索的准确性。
• 外键（Foreign Key）：外键是用于建立表格之间关系的列，它引用了其他表格的主键。外键用于确保数据表格之间的引用完整性和一致性。
• 约束条件（Constraints）：约束条件定义了数据的完整性规则，用于限制数据的取值范围和关联关系。常见的约束条件包括唯一约束、非空约束、默认值约束等。
• 索引（Index）：索引是一种数据结构，用于加快数据表格的检索速度。索引可以基于一个或多个列，通过预先排序和组织数据，提供更高效的数据访问。
• 其他属性和选项：数据表格还可以具有其他属性和选项，如表格注释、触发器、视图等，用于进一步管理和操作数据。

这些构成要素共同定义了数据表格的结构、数据类型、约束条件以及与其他表格之间的关系，使得数据能够被有效地存储、查询和操作。

3. 典型的数据表格例子之Mysql

传统开发模式下，开发人员会根据业务需求建表。

1）创建数据模型

Contract表格表示合同信息，包含ContractID作为主键，表示合同的唯一标识，以及其他属性如ContractName、StartDate和EndDate。

Party表格表示相关方信息，包含PartyID作为主键，表示相关方的唯一标识，以及其他属性如PartyName、Address和ContactNumber。

ContractParty表格用于建立Contract表格和Party表格之间的关系，它包含了ContractID和PartyID作为外键，分别与Contract表格和Party表格的主键关联，以及Role属性表示相关方在合同中的角色。

2）设计表

3）预览表

四、APaaS平台怎么通过可视化界面把表单设计与数据库建表工作结合起来

1. 通过容器的方式实现数据表格其在可视化界面的渲染

APaaS平台通常通过以下方式来实现数据表格容器：

1. 可视化表格设计器：提供可视化的表格设计器，允许用户以图形化的方式创建和设计数据表格。用户可以通过拖放和设置属性来定义表格的列和属性。
2. 数据模型定义：允许用户定义数据模型，包括表格和列的结构。用户可以定义列的数据类型、长度、约束条件等。
3. 表格操作和行为：提供一系列操作和行为选项，用于对数据表格进行操作和处理。例如，用户可以定义增加、删除、修改表格记录的操作，以及表格之间的关联关系和查询操作。
4. 数据绑定：支持将数据表格与其他组件或数据源进行绑定。这意味着表格可以显示和编辑与其他组件或数据源相关联的数据。用户可以指定数据源，如数据库表、API接口或其他数据服务。
5. 用户界面定制：允许用户自定义表格的外观和行为。用户可以调整表格的样式、布局和交互方式，以满足特定的需求。
6. 数据验证和约束：提供数据验证和约束机制，以确保数据的完整性和一致性。用户可以定义列级别和表级别的约束条件，如唯一性约束、非空约束等。
7. 数据过滤和排序：支持对表格数据进行过滤和排序。用户可以定义过滤条件，以便只显示满足条件的数据。同时，用户可以指定排序规则，对表格数据进行排序。
8. 数据导入和导出：提供数据导入和导出功能，以便将表格数据从外部源导入到表格中，或将表格数据导出到外部文件或数据存储中。

1）腾讯微搭

① 功能展示

在页面设计组件中，提供数据容器：

数据容器组件介绍：

• 数据列表：适用于从数据源中查询多条数据，并将返回列表循环展示的场景，如查询用户列表。
• 数据详情：适用于从数据源中查询一条数据，并将返回数据展示的场景，如查询访客预约详情。
• 表单容器：快捷实现表单数据的提交与展示场景。绑定数据源后，可根据字段类型自动生成单行输入、下拉选择、提交按钮等组件。
• 数据表格：以表格形式展示多行数据，支持对数据进行排序、搜索、分页、自定义显示内容和操作。

数据列表显示效果如下图所示：

数据详情显示效果如下图所示：

表单容器显示效果如下图所示：

数据表格显示效果如下图所示：

目前微搭已经实现根据选择的数据表，可以直接生成选择表对应的列表、创建、更新、详情页面。用户体验绝佳！

② 操作演示

创建模型应用：选择数据源（创建数据表、表字段、表关系），数据源支持跨应用共享选择。必须选择一个数据源才能走下一步。

选择完成之后，会自动生成如所下图所示几个页面，列表、创建、更新、详情。这个地方特别符合用户心智模型，点赞！！！

对于组件的解释，跟随详情跳转链接，这个细节特别好，点赞！

③ 技术实现

腾讯微搭使用 Kubernetes 作为其应用程序容器的管理和编排平台，通过利用 Kubernetes 的自动化和弹性能力，提供高效、可靠的微信小程序开发和部署环境。

2）Microsoft Power Apps

① 功能展示

• “编辑”窗体：则用户可以编辑相应字段、创建记录，以及将所做的更改保存到数据源。
• “显示”窗体：则用户可以显示某个记录的所有字段，或者只显示您指定的字段。

② 操作演示

选择“编辑”窗体：

关联了数据源的表单，不支持删除：

这个细节特别好，值得点赞！！！

③ 技术实现

在 Microsoft Power Apps 中，应用程序的运行和托管是在 Microsoft Azure 云平台上进行的。Azure 提供了一系列的托管服务和平台功能，用于运行和扩展 Power Apps 应用程序。

Microsoft Azure 平台本身支持容器化应用程序的部署和管理，并提供了 Azure Kubernetes Service（AKS）作为托管 Kubernetes 服务。这使得开发人员可以在 Azure 上部署和管理基于Kubernetes 的应用程序。

但这与 Microsoft Power Apps 平台本身的功能和架构是分开的，Power Apps 并不直接使用 Kubernetes 作为其容器管理解决方案。

2. 怎么做

有两种开发方式：

• 表单驱动。在表单驱动的开发方式中，应用的核心是表单。开发者通过定义和配置表单来构建应用的用户界面和交互逻辑。表单中包含了输入字段、验证规则、布局等信息，用于收集用户输入的数据并进行处理。表单驱动的开发方式更加关注用户界面和交互逻辑的设计，开发者需要根据具体的业务需求来创建和配置表单，定义数据的输入、展示和验证方式。
• 模型驱动。在模型驱动的开发方式中，应用的核心是数据模型。开发者通过定义和配置数据模型，包括实体、属性、关联关系等，来构建应用的数据结构和业务逻辑。应用的用户界面和功能是基于数据模型自动生成的，开发者可以通过配置数据模型的属性、视图、操作等来定义用户界面和交互逻辑。模型驱动的开发方式强调数据驱动的应用开发，开发者主要关注数据模型的设计和配置，而较少关注具体的界面设计和编码。

腾讯微搭和Microsoft Power Apps都是都采用了表单驱动和模型驱动相结合的开发模式来实现表单设计器

腾讯微搭，它结合了表单驱动和模型驱动的特点。在微搭中，可以通过简单的表单配置来创建用户界面和交互逻辑，快速构建数据录入和展示界面。

同时，微搭也支持通过数据模型的定义和配置来实现更复杂的业务逻辑和数据关联。开发者可以根据具体的需求选择合适的方式进行开发，灵活地使用表单驱动和模型驱动。

Microsoft Power Apps，它同样采用了表单驱动和模型驱动的混合模式。在Power Apps中，可以通过拖拽和配置表单控件来创建用户界面，并通过设置控件的属性和事件来定义交互逻辑。

此外，Power Apps还提供了数据模型的支持，开发者可以定义实体、属性和关联关系，并使用公式和规则来实现数据的处理和业务逻辑。通过表单驱动和模型驱动的结合，Power Apps提供了更灵活、细粒度的开发方式。

核心设计思路：

• 数据源绑定。将数据源绑定逻辑从表格组件中分离出来。这可以通过创建一个数据服务或数据层的模块来实现。该模块负责与数据源进行通信，获取数据，并将数据传递给表格组件进行显示。这样，表格组件只需要专注于展示数据和用户交互，而不需要处理数据获取的细节。
• 容器和内容分离。将表格组件放置在一个独立的容器组件中。容器组件负责管理表格的布局和样式，并提供必要的交互功能，如排序、筛选等。表格组件则负责渲染和展示数据，并处理用户交互事件。通过将容器和内容分离，可以实现更好的模块化和组件重用性。

1）数据表格搭建

实现思路：

1. 准备数据：首先，准备需要展示的数据。数据可以来自数据库、API接口、本地文件或其他数据源。确保数据的结构和格式与表格组件所期望的一致。
2. 选择表格组件：根据需求和技术栈，选择适合的表格组件或库来渲染数据表格。
3. 绑定数据：将准备好的数据绑定到表格组件中。
4. 设置表格属性：根据需要，配置表格的属性和样式。可以设置列的名称、数据类型、排序方式、筛选选项、分页设置等。此外，你还可以自定义表格的样式、颜色和布局。
5. 处理交互和事件：根据需要处理表格的交互和事件。例如，你可以添加点击表头排序、选中行、编辑数据、删除数据等功能。通过监听表格组件的事件或使用相应的API方法，来实现这些交互和操作。
6. 渲染表格：在可视化页面中使用相应的代码将表格组件渲染出来。这通常涉及在HTML文件中插入表格组件的标记，并在适当的位置使用JavaScript代码将其实例化和渲染。

① 腾讯微搭

功能展示

数据源：腾讯云微搭低代码的数据源提供了数据集合本身的存储以及操纵数据的各种方法，本质上是一系列操作数据的方法集合。低码平台提供了数据源管理功能，可以创建、管理多个数据源。

数据源类型及功能概览：

操作演示

新建数据模型（创建表）：

设计表字段属性：

通用选项集（合同状态、合同类型），通用选项集管理就是枚举值的管理：

表与表是怎么关联的，例如下图所示：为合同相关字段，提供数据类型：关联关系，关联模型选择对应的表“相关方”，关联类型选择：“1:1”，“N:1”的关系。

以及删除“相关方”时，对应的“合同”数据不删除就是当“合同”与“相关方”有关联数据时，“相关方”不允许被两个选项。这一点微搭考虑很到位。

数据源管理

在对应数据模型后面，提供了对该数据的管理入口。

② Microsoft Power Apps

功能展示

数据源的类型：数据源可连接到云服务，或者，可以位于应用本地。

连接的数据源：最常见的数据源是可用于检索和存储信息的表。 可以利用到数据源的连接，采用 Microsoft Excel 工作簿、使用 Microsoft Lists 创建的列表、SharePoint 库、SQL 表和许多其他格式来读取和写入数据，并将这些数据存储在 OneDrive for Business、DropBox 和 SQL Server 等云服务中。

除表以外的其他数据源包括电子邮件、日历、Twitter 和通知，但本文并不介绍其他这些类型的数据源。

操作演示

创建应用，创建表，设计表：

使用“显示”窗体容器，关联对应数据源：

数据管理，可以添加修改数据：

2）表单模型搭建

表单模型是指在应用程序或系统中用于收集和处理用户输入数据的结构化数据模型。它定义了表单中的字段、验证规则、默认值和其他相关属性。

表单模型的构成要素，表单模型的构成要素包括以下几个方面：

1. 表单字段（Form Fields）：表单字段是表单模型的核心要素，用于收集用户输入的数据。每个表单字段代表一个特定的数据项，例如文本输入框、下拉列表、单选按钮、复选框等。每个字段具有唯一的标识符和相关的属性，如字段类型、验证规则、默认值等。
2. 标签（Labels）：标签用于描述表单字段的用途或含义，提供给用户一个可见的文本标识，帮助他们理解字段的目的。标签通常显示在字段前面或上方。
3. 输入控件（Input Controls）：输入控件是用户与表单字段进行交互的界面元素。根据字段的类型，输入控件可以是文本输入框、下拉列表、单选按钮组、复选框等。输入控件允许用户输入、选择或修改数据。
4. 默认值（Default Values）：某些字段可以设置默认值，作为初始值或推荐值。默认值可以预先填充字段，减少用户的输入工作量，同时提供了一些合理的选项。
5. 验证规则（Validation Rules）：验证规则定义了对用户输入数据进行验证的规则和条件。验证规则用于确保输入数据的合法性和完整性，可以包括必填字段、数据格式、范围限制、唯一性检查等。验证规则可以提供及时的错误提示，帮助用户纠正错误并提供有效的数据。
6. 提交按钮（Submit Button）：提交按钮用于触发用户完成表单输入并提交数据的操作。当用户点击提交按钮时，表单数据将被发送到后端进行处理或存储。
7. 取消按钮（Cancel Button）：取消按钮允许用户放弃当前的表单输入操作，返回上一步或退出表单页面。

这些要素共同构成了表单模型，提供了一种结构化和用户友好的方式来收集和处理用户输入的数据。通过合理设计表单字段、标签、输入控件、验证规则等要素，可以提升用户体验、确保数据的准确性和完整性，以及满足特定应用场景的需求。

① 腾讯微搭

组件列表详见：https://cloud.tencent.com/document/product/1301/59110

② Microsoft Power Apps

组件列表详见：https://learn.microsoft.com/zh-cn/power-apps/maker/canvas-apps/add-configure-controls

五、结论

本文详细描述了APaaS产品中数据模型（表单设计器），本质来看：表单模型是一种用于收集和验证用户输入数据的模型。它定义了数据输入的结构、字段和验证规则。表单模型提供用户界面，用于展示字段和接收用户的数据输入。

通过表单模型，可以收集用户提交的数据，并进行验证以确保数据的合法性和完整性。而数据模型负责数据的结构化存储和查询，使用数据表格容器是数据模型在可视化界面的实现方式，另外还提供数据源的管理。

扮演的角色

数据表格容器用于数据的存储和展示，而表单模型用于数据的输入和验证。

数据表格容器提供了数据的结构化存储和查询功能，而表单模型提供了一种用户友好的方式来收集和验证用户输入的数据。

• 数据输入：表单模型提供用户界面，用户可以填写表单字段并提交数据。
• 数据验证：表单模型可以验证用户输入的数据，确保数据的合法性和完整性。
• 数据存储：通过数据表格容器，将表单中的数据存储到适当的表格中，以便后续的数据处理和查询。
• 数据展示：数据表格容器可以用于展示存储的数据，将数据以表格的形式呈现给用户或其他系统进行查看和分析。

常见的B端卡片组件，应该怎么设计才可以达成更好的传播效果、传递更清晰、更完善的视觉体验？在本篇文章里，作者就结合具体案例，对B端卡片组件设计进行了技巧拆解，一起来看看吧，或许会对你有所启发。

B端设计的过程中，并不是所有元素抄一抄别人的，从组件库里引用下就完事了，而是要经过具体组织并设计。尤其在一些特殊的组件中，是可以去表现设计水平，提升项目整体视觉质量的，而不是让它们看起来非常的枯燥乏味。

这次，我们的改版主要就围绕在B端常见的卡片组件中，通过3个以前提交过的作业，来分享如何设计B端的卡片。

三个改版案例我们都遵循相同的设计方式和顺序：

• 分析组件包含字段
• 确认组件内部框架
• 完成字段权重表现
• 完成组建视觉样式

一、卡片案例1

在该案例中，卡片作为页面的核心对象，视觉重心不够突出，且内容的权重没有得到有效的表现，订单标识只有一个的情况反复强调对识别卡片没有任何帮助，且卡片占比过大，没必要的浪费页面空间。

所以，重构它的结构时，重点突出标题弱化标签，将卡片拆分成标题、信息、操作三个栏，让信息的呈现更简洁直观。

然后再具体优化内容和细节，对重要信息突出，固定的标题字段弱化。

最后，再根据主色的需要填充色彩进去即可。

二、卡片案例2

这个案例也是设计得比较有问题的，但是忽略掉全局组件的粗糙，卡片部分的设计也是很多作品案例中的常见问题，要素过多，没有主次，在列表化的展示中，根本没办法很好的识别相关的内容和关注到有效的信息，会被淹没在繁复的字段内容中。

所以，我们用相同的方法作下区分，将内容分为上中下三个栏。

然后再对字段做权重的划分，虽然字段信息很多，但值得被突出的要素不多，企业名和数据是卡片中最重要的信息，一个用于识别卡片，一个用于查看核心的指标。

最后，再完成样式的补全即可，只在星级和用户职位上增加色彩。

三、卡片案例3

问题和前面还是一样，内容很零碎，所有要素都强调，于是就没有重点。所以，下面对它们进行改版，这次因为数据项不再是重点，卡片的目标不是用来查看数据而是用于检索进入到下级页面的，所以只分了两栏。

然后，再对权重进行强调，查看详情是这里面最重要的元素，图片则没有太大的意义仅仅是点缀所以缩小。

最后，再完成相应色彩的添加和图片的填充，完成最终的视觉效果。

这三个改版都用了很简单的修改方式，通过理解卡片的作用、字段信息，对它进行信息分区，然后填入相关的字段并做出权重划分，最后再用颜色为不同的要素加权。

只要掌握这样的设计思路，做绝大多数卡片都不会有阻力，只会纠结于应该用哪套样式更合适。

结尾

因为时间关系只做了很简单的调整，没去做多套大跨度的样式变更，同时套进原图环境没做整体的处理，所以还有很多升级优化的空间，理解这个感觉即可。

三方支付机构已经发展了很多年，相信大家对三方支付机构都不陌生，本文将从定义、资质、通道、支付账户、支付产品等几个维度认识三方支付机构，希望对你有所帮助。

我国支付体系由众多参与者构成，其中包括人民银行、商业银行、清算机构、三方支付机构、四方支付机构等，如图1所示，支付是由众多组织、众多系统协同的结果。

图1：支付服务组织、职能及示例

三方支付机构已经发展了很多年，对很多人来说并不算陌生，特别是头部的几家，接下来将从定义、资质、通道、支付账户、支付产品等几个维度认识三方支付机构。

一、三方支付定义

是指非金融机构在收付款人之间作为中介机构提供下列部分或全部货币资金转移服务∶

网络支付：指依托公共网络或专用网络在收付款人之间转移货币资金的行为，包括货币汇兑、互联网支付、移动电话支付、固定电话支付、数字电视支付等。

预付卡的发行与受理：指以营利为目发行的、在发行机构之外购买商品或服务的预付价值，包括采取磁条、芯片等技术以卡片、密码等形式发行的预付卡。

银行卡收单：指通过销售点（POS）终端等为银行卡特约商户代收货币资金的行为。

中国人民银行确定的其他支付服务。

二、资质要求

非金融机构要想提供支付服务，应当依据规定取得《支付业务许可证》，成为支付机构，如图2所示。支付机构依法接受中国人民银行的监督管理。未经中国人民银行批准，任何非金融机构和个人都不能从事或变相从事支付业务。支付机构应当按照《支付业务许可证》核准的业务范围从事经营活动，不能从事核准范围之外的业务，不能将业务外包给其他机构。支付机构不能转让、出租、出借《支付业务许可证》。

三、备付金管理

客户备付金是指支付机构为办理客户委托的支付业务而实际收到的预收待付货币资金。备付金管理指客户备付金的存放、归集、使用、划转等存管活动。

客户备付金必须全额缴存至支付机构在备付金银行开立的备付金专用存款账户。备付金银行，是指与支付机构签订协议、提供客户备付金存管服务的境内银行业金融机构。断直连以后支付机构客户备付金集中存放在人民银行，开立专户核算。

3.1 备付金账户模型

支付机构通过接入网联或者银联开展支付业务（后续默认以接入网联为例进行描述），并通过网联管理备付金账户，比如查询账户余额，通过额度映射方式向网联分配额度，如图3所示。

图3：备付金账户模型

集中存管账户余额，是指支付机构在人民银行开设的备付金集中存管账户余额（以下简称账户余额）。

映射额度，是由支付机构根据账户余额分配至清算组织的，经清算组织确认且互认的账户资金份额，并不会进行实际的资金划转，并且支付机构可以随时调整映射额度。

可用额度，是以已映射额度为基准，根据支付机构出入金业务处理结果，实时进行增减的额度（可用额度=映射额度+入金-出金），如果可用额度不足，则无法完成出金业务。清算组织通过控制可用额度，确保支付机构办理业务所形成的汇差，不高于支付机构向各清算组织所分配的已映射额度。

在这种账户模式下，可以在清算机构内先完成清算场次内的清算工作，仅将一定周期内的清算净额提交央行做最终的结算，这样可以降低高并发的互联网支付业务对央行支付系统的冲击，避免形成热点账户。

3.2 映射额度管理

网联的账户模块即“备付金热点账户前置系统”（以下简称“前置系统”或“RCMP”）。支付机构可以通过前置系统进行映射额度的调整，如图4所示为映射申请的流程。

图4：映射申请流程

支付机构向网联发起映射申请，网联会先查询该支付机构已经分配给银联的额度，然后查询其央行备付金集中存管账户的账户余额，如果本次申请映射的额度不大于“集中存管账户余额-银联已映射额度”，则申请成功，否则失败。

解映射申请相对简单，因为是减少映射额度的申请，所以无需查询银联的已映射额度和集中存管账户的账户余额，可以直接进行解映射处理，如图5所示，但解映射申请的金额不能大于已映射的额度，否则申请失败。

图5：解映射申请流程

3.3 备付金变动通知

结算时，网联向备付金集中存管账户提交结算指令，在支付机构备付金集中存管账户内完成最终的结算，并通知支付机构相关结果以及额度变动情况，如图6所示。

图6：结算与结果告知流程

3.4 备付金账户余额查询

支付机构可通过网联或银联所提供查询工具7*24查询账户余额、网联或银联已映射额度、可用额度等信息，额度查询流程如图7所示。

图7：备付金账户余额查询流程

3.5 备付金管理平台

支付机构需要做一个后台工具，用于查询央行集中存管户账户余额，查询网联映射额度和可用额度，增加或者减少网联映射额度。通过上面网联提供的查询能力和映射额度调整能力，就可以做一个后台页面工具提供给备付金管理人员使用，如图8所示。

图8：备付金账户管理

四、接入网联业务

断直连以后支付机构开展互联网支付业务，需要接入网联或者银联，由网联和银联进行支付指令的清算和转发，与直接接入银行通道存在一定的差异，特别是在付款业务上，下面分别介绍网联向支付机构提供的相关业务以及网联的支付清算模式。

4.1 网联支持的业务

网联提供的可接入业务包括信息类和支付类两大类，具体业务功能和适用场景如下表所示。

4.2 支付清算模式

网联和银联采用“实时清算、定时结算”的模式受理来自支付机构的收付业务，通过支付机构备付金集中存管账户完成资金结算。收付时，通过实时增减网联前置系统的可用账户余额完成清算，在固定时间点提交央行完成最终的结算。以入金业务为例，整个支付业务流程如图9所示。

图9：网联入金业务流程

在上述的入金业务清算过程中支付机构备付金集中存管账户的余额并不会发生变化。在清算场次内虽然支付机构发生了收付业务，但是网联的清算处理仅在前置系统内通过实时增减可用余额完成，并不会改变支付机构备付金账户的余额。提交结算以后备付金账户余额才会根据清算净额发生变化。

这里有一个明显的好处，那就是付款效率的提高，断直连之前支付机构通过在各银行开通的收付户进行对外付款，但需要账户中有足够的资金，当日的收款在银行没有结算至备付金账户之前是无法用于付款的，而现在的实时清算模式下，出金业务并不依赖实际的账户资金到账，而是可以基于可用余额进行，入金业务会增加可用余额，可以直接用于付款，极大的提高了资金的使用效率。

五、支付账户

支付账户是指获得互联网支付业务许可的支付机构，根据客户的真实意愿为其开立的，用于记录预付交易资金余额、反映交易明细信息的电子簿记。支付账户不能透支，不能出借、出租、出售，客户不能利用支付账户从事或者协助他人从事非法活动。支付账户根据开立时的验证要素数量可以分为一类，二类，三类等级，如下表所示。

六、机构的产品架构

支付机构以银行支付通道为业务基础，封装出适用于各类交易场景的支付产品，为商户提供支付能力，这是支付机构的产品主线，围绕该主线又会产生其他类系统的诉求，例如资金处理、对账、计费等。以下是典型支付机构的产品架构，如图10所示。

图10：典型三方支付机构产品架构

接入层，是三方支付机构直接面向客户的入口，包括个人客户、商户、渠道商等，为个人客户提供消费支付产品，为商户提供支付能力服务，为渠道商提供分销合伙的平台。

业务层，是支付机构所打造出来的适用于各类支付场景的支付产品，例如航旅支付解决方案、生活缴费支付解决方案、银行卡支付、资金合规、分账类产品、商户结算类产品等。

交易层，是对各类业务交易请求的处理层，处理上游各业务线下发的支付订单，例如收款类交易、付款类交易、鉴权类交易等。

支付处理层，处理提供收银台和支付核心，还将构建各类支付的核心处理流程，例如快捷支付、网关支付、分账支付等。

风控层，对支付安全负责，包括客户信用安全、交易安全、支付安全、数据安全等等。

通道层，是集中管理接入的各类支付通道，以及为支付层筛选最佳通道的路由系统。

渠道层，是底层对接的提供各类支付通道的服务商，其中包括一些消金类机构、银行、清算机构等。

七、产品岗位设置

其实通过上面的架构图大家也应该能猜出来会有哪些岗位职责和产品经理岗位；如果你将来计划去一家支付机构做产品经理的话，大概率会有以下支付类岗位可以选择。

开放平台产品经理，主要负责对上游商户对接，输出基础能力的规划和设计。

商户后台产品经理，负责商户后台的规划和设计。

商户管理产品经理，入网产品经理，工单系统产品经理等负责基础性产品。

行业解决方案产品经理，针对某垂直领域进行支付场景挖掘和解决方案设计，比如水电煤气领域，保险领域，教育领域等。

收款产品经理，主要做收单通道的接入，路由的设计、通道管理的设计等等，核心职责就是与内外部对接，是支付机构与内外部的桥梁角色。 付款产品经理，出款通道的接入和管理，出款产品的设计，为出款性能、准确性、安全性负责。

退款产品经理，管理收单逆向业务，负责退款中心的设计和规划，为退款业务负责。

基础支付产品产品经理，主要负责不同支付场景的挖掘以及支付产品的包装和设计，提供具有更好用户体验以及市场竞争力的支付产品解决方案，比如二清合规，快捷支付类，打款类。

风控产品经理，设计风控核心系统的产品经理。

资金管理产品经理或者清结算产品经理，包含了核算产品经理，账务账户产品经理，计费产品经理，财务处理产品经理，备付金管理产品经理等。

当然还有一些细分的支付产品经理，比如快捷支付、网关支付、聚合支付、钱包产品、企业支付等等。

本文通过与Airtable的创始人对话，了解在Airtable的创作初期，他们是如何寻找产品与市场定位的过程，接下来，我们看看作者的分享吧。

Andrew Ofstad 是 Airtable 的联合创始人，在创立 Airtable 之前曾在 Google 担任多个重要产品的产品经理，包括 Google Maps、Android、社交应用以及应用市场，并获得了 Google 内部的 Founders Award。

Ofstad 在近期分享了 Airtable 早期发展中如何达到 PMF 的经验，对话 First Round 的合伙人 Todd Jackson，Jackson 也曾在 Google 担任产品经理，也是前 Dropbox 产品副总裁和 Twitter 产品总监。

PMF 是公司建设中最重要但又最难以捉摸的概念之一，Jackson 表示它不是一个清晰可测量的指标，也不是一个可以轻易勾选完成的里程碑。

他认为 PMF 是创始人在将产品从“推销”变为用户“主动需求”时的转变时刻，但是达到这个目标的道路是非常个人化的，一个创始人的 PMF 之旅可能与另一个创始人的完全不同，但两个路径都可以完全有效，这使得当你从外部观察时很难判断可以得出哪些经验教训。

Ofstad 与 Jackson 这次对话旨在为创业者分享找到 PMF 的具体步骤提供借鉴，我们将站在一名产品经理的视角，一起回顾 Airtable 探寻 PMF 过程中最关键的片段。

一、倒带Airtable的故事

经过十年的公司建设，Airtable团队取得了一些令人瞩目的成绩。这个低代码平台拥有超过30万家组织的客户群，其中包括亚马逊、贝克休斯、Netflix和耐克等知名公司。事实上，令人惊讶的是，80%的《财富》100强公司都在使用Airtable。

低代码运动已经牢牢确立，该公司专注于全球化发展（在伦敦开设了首个国际总部），并且该团队已经筹集了13.6亿美元的资金，估值达到110亿美元。

但就像任何完善的故事一样，如果你把时间倒回最早的日子，情况看起来截然不同。随着时间的流逝和成功的光环，很多微小的细节被掩盖了，无论是最初原型的构建困难，还是找到理想的客户画像的挑战。

对于Airtable来说，构建一个大型的横向产品使得这条道路变得更加艰巨。（浏览他们的模板部分，可以了解到这个灵活产品可以应对的广泛应用场景，从跟踪错误和营销活动，到牧场经营和寻找婴儿配方等。）

2012年，安德鲁·奥夫斯塔德和他的联合创始人豪伊·刘和埃米特·尼古拉斯开始了一场“缓慢的建设”。在他目前的角色中，奥夫斯塔德主导公司的长期产品投注，但今天他带我们回到起点，追溯Airtable达到 PMF 的过程。

我们深入探讨了他们如何验证最初的愿景，并从私人内测到正式发布的早期产品构建之旅。从最初的迹象表明它开始受到欢迎，到如何定位和思考竞争对手的挑战，这里有很多值得有志创业者学习的经验教训，特别是那些正在构建横向产品的人。

二、探索创意和验证愿景

公司建设的-1到0阶段可以有很多不同的形式。有些创始团队很快就会围绕一个特定的创意凝聚起来，而其他团队可能会花费几个月的时间探索完全不同的行业。对于Airtable三人组来说，早期的愿景虽然宏大，但目标却很明确。

“早期的愿景是让软件创作民主化。我们都觉得自己有一种疯狂的超能力，就是能够构建软件，在我们的职业生涯中，这给了我们巨大的优势。通过构建软件并将其应用于人们身上，即使你不在领导层，你也可以在组织中产生巨大的影响。因此，广义上来说，我们在探索如何让非程序员更容易地创建软件，”Ofstad说道。

这种灵感大部分源于计算机历史。“计算机的早期是使用晦涩难懂的命令行操作。直到施乐帕克（Xerox PARC）的图形用户界面和苹果的Mac问世，计算机才变得更容易为每个人所接受。我们希望对软件做同样的事情，让每个人都拥有一个软件堆栈，可以在其上构建有用的软件。”

但仅仅拥有一个创意是不够的，评估其潜力是有志创业者需要克服的下一个关键障碍。你如何向自己（和他人）证明它是有发展前景的呢？

Ofstad说，在这里花时间是关键。他主张采取所谓的“长孕期”，建议创始人抵制迅速着手构建功能和发布不成熟概念的诱惑。

相反，他建议创始人深入研究，并广泛阅读，从各个角度考察问题：了解你之前的竞争对手，市场中的空白部分以及你自己推动的动机：

1）要不追随时尚

“我们有点持异议。那时候，都在讲Lean Startup，早期客户验证和快速失败。有一本名为《灵感的四个步骤》的书推崇这种精益公司发展模式，你只需发布一个非常粗糙的原型，以了解客户并迅速转向，”他说。“我们采用了更多的从头原则方法——我们不想只是随意尝试，因此我们在正式开始构建产品并试图获取客户之前，对问题进行了深入研究。”

2）研究先前的成果

“我们对进入这个广泛的软件创作领域感到非常兴奋。所以我们花了很多时间进行研究。几乎像是在休假，阅读所有这些早期计算机先驱的先前成果，比如道格拉斯·恩格尔巴特（Douglas Engelbart）和比尔·阿特金森（Bill Atkinson），甚至包括同代人，如布雷特·维克托（Bret Victor）。我们玩过一些旧产品，比如HyperCard，它具有面向所有人的软件创作功能，还大量阅读如何可视化复杂系统的资料。”

3）评估潜力并找到机会

“我们花了很多时间思考’这个市场是什么样的？’电子表格已经存在很久了，但大多数时候，人们只是用它们来跟踪对象：人、公司、简单的表格。它们没有进行建模和数值计算，这是它们被发明出来的目的，”Ofstad说。“当豪伊在Salesforce工作时，他对企业软件市场有了更多的了解，并发现目前市场上的大多数业务应用本质上只是具有视图和业务逻辑的数据库，而在垂直软件中存在很多重复造轮子的现象。因此，我们看到了将这种软件创作方式向更大市场开放的商业潜力。”

确保你有充分的投入和深入研究：“我们在早期花了很多时间，以确保这是我们致力于的事情。如果你要解决一个很难市场推广且需要构建很多内容才能达到MVP的横向产品，我建议花时间确保你对问题空间非常感兴趣，并且喜欢与你一起工作的人。如果没有这个深入研究问题的时期，我们很难达到那种坚定的信念。”

我们有一个早期的漫长孕育时期，在这个时期我们对技术挑战、市场和先例进行了研究。我们看到我们可以建立一个大公司，但我们知道这可能需要很长时间，所以我们必须拥有正确的心态。

三、构建早期产品：从原型到发布的缓慢路径

“第一个版本是试图证明我们可以使数据库易于使用。它就像一个原型——很多花招。我们百分之百地专注于用户界面和交互。我们实际上没有后端，只是将数据存储在本地存储和浏览器中——足够确保我们可以测试交互并使人们能够玩弄它。我们想让人们面对它，并要求他们尝试组织一些东西，看看他们是否真的能做到。”Ofstad说道。

产品差异化将是Airtable成功的关键，但早期版本看起来非常像电子表格。“显然，它下面是一个数据库，但我们借用了电子表格界面，这对大多数知识工作者来说是熟悉的，”他说。“我们构建了许多相同的交互方式，尽管我们有类型字段、表格和外键关联之间的链接。但对于很多人来说，它就是没有点燃火花。我们经历了很多迭代，做了很多事情，比如构建模板，让它感觉不同。”

这里有一个例子：“即使是一些细节，比如颜色选择选项的字段，也有助于传达你正在处理记录而不是电子表格的心理模型。我们也一直强调直接操作，让它感觉像是你可以伸手触摸数据。当我们首次构建附件时，它带有拖放功能，因为我们希望它感觉非常互动，所以我们在实时架构上投入了很多努力。”

尽管存在这些最初的障碍，仍然有一群早期采用者。“他们是程序员或数据库人员，更具有摆弄性格，他们的思维非常结构化，”他说。“我们有一个朋友是视频制作人，他开始追踪他的视频制作，创建演员和工作人员表，并将它们链接在一起。”

许多创始人可能会试图扩大用户群，让更多用户使用产品，但Ofstad再次警告不要过快行动。由于只有零星的那些可点击的顾客时刻，Airtable团队知道这将是一个异常缓慢的发布路径。

在评估自己的时间表时，Ofstad建议退后一步，重新评估在早期阶段公开发布是否真正有助于实现关键目标。“我们非常早期就专注于尽早消除公司的主要风险。对我们来说，这是 ‘我们如何使非程序员真正能够使用这个数据库？” Ofstad说道。“这意味着我们需要让它易于使用，对原型进行迭代，并获得大量反馈。看起来，公开发布产品并不能给我们带来更多数据或加速到达目标的路径。”

将从客户那里获得反馈并改进产品的概念与公开发布的概念分开。

Ofstad解释了这个原则在实践中是如何运作的：

1. Alpha：在降低风险的同时保持精益

“我们的策略是构建一个非常横向的产品，然后随着时间推移向更多人推出。早期，我们进行了内部测试（alpha版）。那是邀请制的，但你可以推荐其他人，这帮助我们获得了一些有机增长，但并不多，”Ofstad说道。“大概在100人左右之后，我们最终觉得我们处于一个好的位置。” 他说，这花了两年的时间。“我们必须构建很多功能，才能得到有用的东西。”

除了延迟公开发布，这种策略还使团队保持相对精简，避免了过早雇佣的陷阱。“在alpha阶段，同时进行这项工作真的很困难。你不能雇佣一大堆工程师来加快速度。实际上，试图大规模扩展可能会产生相反的效果，因为我们需要打好数据库的基础。雇佣一大堆人会使我们更难以灵活变通并改变这个基础的方向，”他说。

如果你正在构建类似类型的产品，Ofstad的建议是保持反馈循环非常紧密，并放宽对MVP外观的期望。“我们会与客户坐下来看他们如何使用产品。对于横向产品，你构建了这个非常通用的东西，有趣的部分是看人们如何使用它，”Ofstad说道。

我们的产品的MVP并不是某一件事。对于横向产品，你不断解锁新的用例。

“随着我们添加新功能，我们解锁了新的用例。我们慢慢地添加了一个日历视图，然后突然发现人们将其用于营销用例。或者添加看板视图，看到人们将其用于流程和管道。”

Beta：测试，测试，测试——但努力加快速度。

“最终，我们觉得可以将其发布为beta版，并试图获得更多客户。我们在2014年在Hacker News上进行了公开发布。我们将其保持为beta版，以便有机会在以后进行更大规模的公众发布，并在出现问题时保留beta标签，”Ofstad说道。

2. Beta：测试，测试，测试——但推动更快速度

“最终，我们觉得可以将其放入beta版，并试图获得更多客户。我们在2014年在Hacker News上进行了公开发布。我们将其保持为beta版，以便为我们提供一个机会，以便稍后进行更大规模的公众发布，并在事情出现问题时保留beta标签，”Ofstad说道。

2014年Airtable在HackerNews上的beta版发布

“事后看来，也许我们等待的时间有点太长了。我们可能可以更早地发布并减少一些功能。但在很大程度上，我们得到了所需的学习，并在准备就绪时进行了发布。我们试图看它是否与我们的客户产生共鸣，以及我们是否能处理潜在的额外流量。我们是否具备了使人们不会丢失数据并且我们可以轻松恢复的功能？”

四、确定市场进入策略和评估竞争对手

“早期，我们的市场进入策略与大多数公司的做法相反，他们会从一个非常小众的受众开始，找到他们，定位他们，并扩展到新市场，”他说。

“我们完全从一个空白产品开始进行横向定位，并随着时间的推移，我们的重点越来越窄，专注于获取客户。我们开始看到不同用例的有机采用，然后我们会创建数百个模板。”

Airtable的产品（大约是在2015年）

“但在过去几年中，我们在市场进入方面变得非常有针对性，”Ofstad说道。“我们现在变得更有主见，缩小了范围。现在，我们主要关注市场营销和产品组织，以确定我们最初如何进入一家公司。这部分是因为我们有了一个更成熟的高管团队来帮助我们完善，包括我们的首席收入官Seth Shaw和我们的首席营销官Archana Agrawal”（她在之前的一期《深度探究》中分享了她的营销经验）。

但找到这条路径并不容易。以下是Ofstad给其他横向产品构建者的建议：

1. 加倍关注初期的动力（但要小心）

“当你在构建横向产品时，尽早了解人们从你的产品中获得价值的地方，并且真正加倍关注。你可以通过深入理解特定用例来构建横向产品。只是不要对它过于深入，”他说。

“这其中存在平衡，因为你也不想采用第一个出现的用例，特别是如果它不会有很大的增长，或者不符合你对公司长期愿景的设想，”Ofstad说道。

“但是，一旦你看到一些验证，客户正处于你对产品的更广泛愿景范围内，与他们一起共同构建产品。专注于理解问题，并将其普遍化为可能解决许多不同用例的功能。”

如果你为一个具体功能构建了一个超特化的应用程序，那么它将无法发挥你对产品的更广泛愿景的作用。从客户那里获取数据，但也将其与你试图构建的更广泛的横向平台的更广泛愿景进行匹配。

2. 融合功能和愿景

横向产品面临的最大障碍之一是传达信息。“多年来，我们越来越关注如何描述我们解决的问题和适用的用例。但在我们实现产品-市场适配之前，很难在早期阶段描述产品，”Ofstad说道。

“我们有几个信息。其中之一是 ‘这是一种构建软件的方式。’我们当时主要还只是一个数据库。我们还没有构建诸如自动化之类的功能，但这就是我们构建使命的框架。然后另外，我们会说 ‘这是一种电子表格数据库混合体，或者是具有数据库功能的电子表格。’这来自于我们的客户对我们的描述，他们说 ‘这是一个易于使用的数据库’ 或 ‘它是一个电子表格，加加。”（我们注意到2014年的《Show HN》副本上写着：Airtable，实时电子表格数据库混合体）

Airtable网站（2014年版）

3. 描绘你的采用情况

那些“我们只是爆发式增长”的产品驱动增长故事对于大多数仍在努力寻找发展机会的初创公司来说并不那么相关。Ofstad深入探讨了Airtable的增长轨迹：

“这发生在许多不同的S形曲线中。我们开始看到媒体公司在我们之间传播口碑。或者制片负责人从Netflix去了其他公司，他们会带上这个工具。这一切发生得非常缓慢，直到2018年左右才真正开始增长，”他说。

“这种功能和行业驱动的口碑增长，加上我们建立的新能力解锁了更多的用例，以及在公司内部扩展的组织成熟度，这些因素共同促成了过去五年里相当稳固的增长。”

但其中的很大一部分归因于产品本身的性质。“有人在他们的表格中构建了某些内容，并与团队的其他成员分享以进行重要工作。一旦人们开始在其中进行工作，就会生成有用的数据，其他人也想使用这些数据。所以人们会邀请他们加入到这个基础上。我们在内部将这些描述为黄金数据集，公司的关键数据集，比如产品路线图或营销日历。一旦达到这一点，就会有很多病毒式的采用。”

找出这一点的关键是能够跟踪这些指标。“我们做的更重要的事情是，早期我们设置了一些仪器，这样我们每次有人注册时就会收到通知，”他说。“一旦我们在较大的公司中获得更多采用，我们就会建立起这些网络图，显示产品是如何从个体传播到个体，然后从团队传播到团队的。这帮助我们理解产品的机制，并为我们提供了一种直观的病毒式采用心理模型。”

4. 从早期开始考虑定价作为定位

“我们从最早的日子开始就考虑定价。即使在我们与第一批用户的alpha版中，我们也有一个包含几个不同计划的定价页面。它主要描述了我们尚未构建的功能，但至少我们希望给出这样的定位，即这是一个我们将要收费的产品，”Ofstad说道。

“我们还选择了定价点来进行定位——我们如何与我们认为我们将为公司带来的价值进行定位？我们与Salesforce和ServiceNow等企业进行了定价比较，而不是与Evernote和Dropbox进行比较。我们预计人们将在Airtable上构建能够支撑公司重要流程的应用程序，因此我们希望能够相应定价，”他说。

“有一段时间我们没有真正建立计费系统来向我们的客户收费。我们实际上有一个地方，在我们的设置页面中隐藏，客户可以自愿输入他们的信用卡信息，但我们没有向他们收费。我们感到惊讶的是，我们的一些客户竟然找到了这个功能，并输入了他们的信用卡信息，然后抱怨说他们没有被收费，”他说。

虽然这可能看起来是一个理想的问题，但Ofstad指出在创始人在定价问题上犹豫不决时可能会忽视的两个因素。“我们的客户担心Airtable会消失。因此，虽然我们从市场营销的角度来制定定价，但也很重要传达我们在这里建立一个持久性业务，”他说。

“而且，如果我开始使用一个产品，而不清楚它是如何盈利的，我也会持怀疑态度。你会想：他们会出售我的数据吗？他们以后会完全掠夺定价吗？透明度对于客户来说实际上也是有好处的，有助于建立对产品的信任。”

5. 在竞争方面，始终保持前瞻性

“我们很幸运选择了一个早期没有太多竞争者对我们形成直接威胁的领域。当然，我们确实有一些可比较的产品和替代品，客户可能会使用电子表格或项目管理应用等产品，但它们是非常不同类型的产品，”他说。“说实话，无代码在2012年并不是一个很流行的概念，而且B2B生产力软件并不是非常吸引人——那时更多的是关于消费者社交。这使我们处于一个几乎没有直接竞争的环境中。”

当然，现在情况已经不同了。但是竞争的增加并没有让Ofstad感到困扰。相反，他的理念是：“我曾经在高中参加越野跑和田径比赛，我的教练总是说，‘不要回头看。你会放慢速度。只要保持头部朝前，感知竞争对手在做什么，但不要过分关注，因为你会迷失自己的目标所在，”他说。

“你能做的最好的事情就是对你想要去的方向有自己的愿景，并确保你朝着这个方向前进。当然，你可以从生态系统中的其他产品中学到很多东西，看看有哪些新产品推出，了解人们正在使用什么，以及消费者品味如何调整。”

保持对更广泛的生态系统中好产品和趋势的敏感是非常重要的。但这与专注于直接竞争对手，并陷入“哦，他们做了这个，我们也要做”的狭隘状态是不同的。那是一种适得其反的做法。

五、找到市场认同：Aha Moment

产品与市场的契合并不是一时的瞬间，而且它也是一个不断变化的目标。但回顾过去，创始人往往会有一个“啊哈”时刻，一切都变得清晰起来。

“有几个里程碑是非常显著的。当你最初看到一个人从产品中获得价值时，比如我们的朋友用它来进行视频制作。或者当你第一次看到一个团队使用它并从中获得价值时——我们有一个非营利组织，大约有10或15个人从早期开始就开始使用它来管理所有的申请者，”他说。

但Ofstad记忆深刻的时刻更加真实。“我们与WeWork合作，并在该公司内部迅速传播，几乎无所不在。当我在客户之旅中来到纽约时——之前我主要通过支持渠道或Zoom与客户进行互动——我参观了WeWork。我环顾四周，每个人的电脑显示屏上都打开着Airtable。我心想，‘天啊，这真的是一回事。人们在使用它。’那时，它变得更加真实。那是我第一次觉得我们真的构建了一个可能成功的东西。” 时至2022年，可以说他们确实取得了成功。但对Ofstad来说，旅程远未结束。

“我们不断努力使产品更易于使用。这不仅适用于在Airtable上构建应用程序的人，也适用于使用这些应用程序的最终用户。我们显然越来越关注企业市场，关注那些在Airtable上运行大型部门和全公司流程的客户。因此，我们需要在更大规模、更好的权限等方面做很多工作，这些都是你们所期望的，”他说。

“越来越多，我们将Airtable视为一个连接的应用平台，这就是我们正在定义的类别。这意味着我们希望给予各个团队和部门构建和部署自己软件的控制权，同时连接到共享数据集和共享表，有助于打破组织内的壁垒。”（如果你想深入了解Airtable在这方面的长期战略，我们推荐阅读关于Ofstad的联合创始人Howie Liu的Protocol专访）。

参考：

https://review.firstround.com/airtables-path-to-product-market-fit-lessons-for-building-horizontal-products

B端产品，不像C端产品直接面对用户需求，B端产品面向企业，帮助企业管控流程、划分责任、降本增效。因此，B端产品的价值并不好体现，那么该如何量化B端产品价值呢？

B端产品，它不像C端产品那样直接面向用户需求。C端产品通过汇聚流量或促成交易直接为企业带来收入，而B端产品面向企业，以低边际成本的产品形式传播企业管理思想和管理手段，最终帮助企业管控流程、划分责任、降本增效。可以说B端产品的价值并不好直观体现。

对B端产品经理来说，需求上线了，意味着苦劳分拿到了，但功劳分能否拿到还是未知数，功劳分能拿多少或者扣多少，需要有客观的指标来衡量。

为了能够将B端产品价值阐述清楚，我们引入B端产品的「衡量指标」，其作用在于帮助我们将价值说清楚，帮助我们将定性的事物转换为可测量的数量，即将解题的思路从语文题变为数学题。

那么怎么定义衡量指标？

衡量指标是衡量产品功能或产品策略好坏的“标尺”，可以从这五方面去做指标定义：时间、人力、效率、质量、规模。

一、时间维度

通过简化流程或操作量，来降低企业员工处理单位工作量的时长。负责B端运营侧的产品同学一般会考虑如何通过工具或产品功能，在复杂重复的事项上节省一线员工的时间。

比如昨天在某小区看到了SF给快递员配备了简易版的电动小三轮，要知道一些小区是不允许快递车进小区的，所以以前快递员只能把快递车停在小区外面，在小区里只能通过手拉筐步行的方式去配送，比较耗时。配备电动小三轮之后无疑会对单包裹的履约时间大大缩短，尤其是在一些面积比较大的小区。

那么平均单包裹履约时长由10min降低至7分钟（打比方非真实数据），就属于时间维度的指标定义。

二、人力维度

在业务流程中，通过系统规则、自动化硬件、传感器、算法等自动化手段代替原流程中的人工节点，实现人力成本的降低。如干线物流的智能调度、快递包裹自动分拣设备、门店摄像头，以及图像识别等方式，代替原需要人脑决策和人力劳动支撑的业务动作，以降低这部分人员成本的支出。

人力维度通常以节省的员工工时工资为计算口径，来阐述产品价值。

三、效率维度

效率分两方面，一通过产品功能的优化提升线上操作效率，如各种一键操作（合并多个操作步骤）、智能记忆、表单自动填充等，提升业务人员在系统使用上的效率。二通过系统规则或智能硬件等，提升线下执行效率，如外卖小哥的串点路径规划提升配送效率，大件仓储场景下使用RFID代替把枪对焦扫描，提升货物扫描效率等。

效率维度通常以单位时间处理更多事件，做更多业务动作为方向，来阐述产品价值。

四、质量维度

通过软硬件技术、业务约束等方式，来规范业务动作、提升交付质量。常见的质量维度的指标有「合格率」「准确率」「满足率」等。比如工厂引入自动化设备，加强薄弱工序环节，提升产品合格率；比如加大算法模型的训练数据，使图像识别准确率提升；比如客户下定100单，原来一个店只能提供90个，那么通过店间动态调拨等形式来满足客户需求等等。

质量维度指标往往是面向用户或者客户，通过技术手段将自身交付质量提高。

五、规模维度

如果说以上几种指标是从运营成本和质量角度出发，那么规模指标则是从经营角度出发，通过业务规模指标来概括当前企业发展情况，常见的有GMV、用户量、商家数等数据指标。举个例子，mt和dy都有到店业务，每家签约的商家量分别是多少，你做的产品策略在其中带来了多少新增量，以及贡献了多少GMV，都是可以通过规模指标去定义产品价值。

写在最后：什么是好的衡量指标？

业务角度：对症。能够直接或者间接与业务指标产生关联，促进业务发展的指标就是好的业务指标。如果一个指标定义后无法准确的描述业务问题，也无法通过指标的变化定位问题原因，那么就不是一个好的指标口径。

技术角度：原子。定义清晰无二义性的，且可被收集方便统计的。原子指标具有唯一解释性，是后续做指标组合和逻辑运算的基础，在进行上层排列组合运算时，不应产生歧义；便于收集是从技术成本角度考虑，比如一些非系统行为的指标就难以采集，像便利店每天进出的人流量，注意不是购买人数，如果想采集这部分数据，那么就需要加装门头传感器来回传数据，也意味着额外增加一定成本，需要结合收益来看是否值得做。

系统的根本目的是为了解决业务范围内出现的问题，那么，如何了解IT架构？本文通过故事的形式让你全面、完整地了解各类系统的业务范围与它们之间的关系，希望能对你有所启发。

市面上有很多的系统，如：ERP、SRM、CRM、WMS、TMS、MES、APS、PLM、OA、HR…

这些系统是什么意思？这些系统有哪些核心模块？这些系统之间的相互关系是什么？

拆解完成，梳理出下图IT架构，明确系统处理的业务范围以及各系统之间的相互关系。

IT架构

系统是为了解决业务范围内的问题而诞生的，以上图IT架构为例，支持层OA系统是为了实现审批流，将所有待办事项、待审核事项按照顺序审核的方式落地。

具体的审核事项可以是生产中的事项，如：工单审核、生产调配审核；可以是质量检查中的事项，如：批次产品质量检查、不合格品返修。支持层HR主要提供组织及用户信息，并管理好用户权限，是所有其他系统使用的基础。

这个IT架构是如何拆解出来的呢？为何是这个样子的呢？

接下来，从系统发展的角度，来梳理系统建设过程，了解系统的业务范围、明确系统之间的关系。

一、源起：库房流水

系统建设实际是从库存流水开始的。下面用一个小故事串联一下。

别看现在小白虽然和文武双泉开起了壹叁零壹大饭店（来源：组织架构），但之前窘迫的日子可是熬了不少。

还记得最开始，小白还只是一个小铁匠。那时候，邻村的乡亲都把家里破破烂烂的铁具交给小白，由小白铸造成新的工具。虽然小白的铁匠手艺不错，但更关键的是小白记录的方式。

小白有一个本子，记录了什么时间谁拿了什么原料过来，想铸造什么东西。在对应人员拿走成品时，签个字确认一下。

记录本明细

这看似简单的记录，清晰记录了每个人拿来什么，换回去什么。加上重量的标记和成品的对比，知晓了原料的损耗，让整个铸造过程清晰透明，每个参与这个交换的人获取的只有一个感受：踏实！

周边人员都很熟悉，人际关系也很清楚，加上送原料的记录和取货的确认，为去掉记录的岔劈奠定基础。

这个记录本的本质是物料库存记录。

物料库存

所有的乡里乡亲进行原料提供，增加物料库存；在成品铸造完成后，乡亲来成品取货，减少物料库存。

随着更多附近乡亲的信任，铸造技术的升级，小白的铁匠铺越来越红火，业务越来越多，小白一个人已经有些来不及了，团队进入扩展阶段。

二、发展：B端业务的兴起

记录本渐渐不能支持了，首先出现的情况是，记录过多，过几天来取成品时，翻找之前的记录，就会变得很耗时间。再是记录人员和制造人员区分开，每个铁匠打造产品时，都需要来查看记录确定原料和成品，对于流水记录的要求更多了。

再就是成品越来越多，同一款产品可能存在多个，原料会影响成品的质量，乡亲来取货的时候，需要进行查找和确认。

再就是乡亲们的交易情况也变多了，或直接卖给铁匠铺原料，或直接购买成品等等。

复杂业务

为确保业务的高效运转，小白建设了一套信息化系统来支持，并配合业务调整，具体落地为原料库、成品库增加接口人。

乡亲们送来原料时，原料库接口人记录信息：原料提供人员、原料名称、原料类型、原料重量、目标产品等；记录生成会同步到铁匠铺内、成品库。

铁匠铺内查看记录，获取到记录信息，安排人员制造产品，在完成后移交到产品库。

当乡亲们来取货时，通过原料库记录信息查询提供原料及成品，完成成品取货，并让取货人员签字确认。

因为加工时长的不确定性，小白修改了信息记录的方式，先让乡亲们关注铁匠铺，成为铁匠铺系统的用户；然后在提交原料的时候自己记录好信息，由原料库接口人确认信息。

铁匠铺内进度信息也实时更新到原料供应乡亲的记录中，让乡亲们获取到铸造的进度。在系统建设的角度，小白让乡亲们关注铁匠铺的时候，就完成了用户的引入及创建。

生产业务流程

随着发展，乡亲们对于产品的品质要求越来越高，自己能提供的原料也逐渐减少，就干脆提出直接购买成品。铁匠铺就需要自己去购买铸铁，来支撑生产产品所需要。

乡亲们即使有一些原料，则通过废料回收的路径直接卖掉了。

随着模式逐渐成熟，铁匠铺各个成员也更熟悉工作，在安排适当的情况下，开始准备增产。

通过查看产品的历史销售量，分析产品的消耗情况及销售趋势，将铁匠们开始细分，专门提前预打造一些产品。

为支持业务的良性发展，小白对系统进行了升级，B端产品雏形初具。

物料、产品库

业务具体细分为采购、库存（物料/产品）、生产、销售，其中库房管理分为 物料库房、产品库房。通过采购补充物料，增加物料库存；物料库存通过生产，形成成品，减少物料库存，增加产品库存。通过销售减少产品库存。

随着信息化的发展，工具赋予生产制造的效能让小白震惊。业务接入系统的深度在深挖，业务的广度在扩展，小白信息化的思维也在不断进化。

三、兴盛：信息化建设的加速

小白作为类似拓荒者的角色，不断的在向前探索。铁匠铺的业务在不断发展，生产制造工具进行了大量的升级，生产效率大幅提高。

类似原料提纯等通过大型设备和熔炉支持，一次性就可以完成超大批量，并且在质量上也有了很大提升。

为确保生产效率的维持，采购物料部分也加大加强了管理。采购物料有交货期，供应商需要准备这大批量的原料；需要财务结算支持，既支持内部资金链的健康，也促进供应商的资金循环；大批量物料需要物流运送，在原料的上货下货、车型配备上也需要精细化管理…

随着生产端效率的大幅提升，销售端也需要扩大力度。需要支持更多销售员销售产品，提供销售订单用于跟进产品物流、财务情况，为产品销售物流提供支持，形成一个完整的闭环。

生产制造业务流程

业务上的闭环没有太多震撼，而发现产品设计标准流程，才让小白欣喜若狂。这一发现，让所有最初始一起合作的铁匠兄弟们有了更大价值发挥平台。

铁匠铺自身需要大型熔炼设备是一个触发契机，促进小白一直思考铁匠铺自身的能力优势，可以打造更多更精细、更尖端的设备。

这就使得产品研发需要有一个完整的链路，并通过已经证明价值的信息化系统来支撑。铁匠铺也正式升级为生产制造工厂。

作为一个铁匠铺发展到一个制造工厂，已经获取了很大的成就，小白更多的发现，这完整的业务链条不能只是一个团队一家公司来完成，但要支撑整个业务的完整运转，信息化建设一定是必要且必须的，以生造制造为中心挖掘信息建设的深度，以完整业务链条运转挖掘信息化建设的广度，将大有可为！

生产制造是一个业务核心【MES】；采购、销售、库存链接起来的进销存是一个业务核心，并以财务结算做支持【ERP】；产品研发设计流程也是一个业务核心【PLM】。这也是信息化三驾马车的来源。

系统间需要数据对接，主要是以物料、产品库存的出入做平衡；采购为物料的入，生产制造为物料的出；生产制造为产品的入，销售为产品的出。

库存平衡

而在这个大平衡下，小的业务场景也需要支持。以产品为例，生产虽然是产品库存的入，但是产品质量不合格、产品成品抽检异常，需要让产品返修或重做，也会成为产品库存的出；销售是产品库存的出，但是销售退货也会成为产品库存的入。

业务详尽场景兼容

每一个独立业务模块都需要对应的系统来支撑，也就成为各个系统划分的边界。

而系统间需要数据通信，是需要系统相互支持的。系统建设的庞大不允许每家公司都使用完全的业务链条系统，也不必要，就会存在非核心业务模块的系统被弱化，也就导致，都是ERP系统，但是功能存在有很多不同。

小白的生产制造工厂，在商业合作顺利获取了一个矿场作为物料来源后，采购的业务就逐渐淡化下来，仅仅使用物料入库记录就可以了。

系统划分

基于业务的原则，划分各系统建设的核心，一次性完成众多系统的识别。

系统间通信

系统建设以业务为核心，设计完整的业务流程，然后强化各个环节自身的自闭环，从而落地为具体而有效的支撑工具。

在并非自身开发系统情况下，要上一套系统，首先需要的就是判断：系统设计是否匹配自身的业务情况。自身建设系统也需要以自身的业务为核心。

经典系统

看完小白的整个梳理过程，是否可以更好理解最开始建立的IT架构了呢？

组织为提升效率而产生，个人专业化将极大提升个人效率，两相正向影响，效率得到更大提升。工具应提升效率而生，应更高提升效率而发展。

用一个好工具，没有？那就造一个好工具！

直播、视频会议是常见的音视频互动方式，那么在金融行业，音频代表的是一个什么角色？本文分析总结了音视频互动在金融行业的应用分析，希望对你有所启发。

之前参与过一款面向金融机构细分领域的视频会议产品，当时产品处于初创阶段，做了一次泛的调研分析，主要目标是分析金融行业对音视频互动的需求特征、了解整体市场情况。

这份报告的实际编写时间是在2022年，因此行业和产品动态的部分的信息可能滞后。

其中数据报告参考来源：《金融直播的风险防范与监管》、《2021年中国企业直播服务行业发展研究报告》、《2022年中国企业直播多场景应用策略白皮书》

一、行业范围理解与界定

1. 音视频互动形式分析拆解

直播、视频会议是常见的音视频互动方式，在金融行业中，更常见的一个词是“路演”。路演原意指宣讲推介，直播、视频会议都可作为路演中的工具方式，两者在应用场景和性质上具有不同的特质，但本质上都是音视频互动方式。

工具属性范围界定——企业直播服务目前直播在多个行业均有广泛应用，包括公域平台直播服务、企业直播服务，在本次分析中，主要针对企业直播服务进行分析。

通过以上的分析界定，也就基本上明确了本次行业分析的方向⬇️

二、音视频互动行业分析

1. 企业直播行业分析

以上产业图谱数据来源于《2022年中国企业直播多场景应用策略白皮书》

• 在政策层面上，利好企业直播服务相关的技术及应用，《“十四五”数字经济发展规划》中明确肯定了企业直播相关应用的价值和意义，且直播应用受到各地鼓励，有较大的发展潜力和发展空间。
• 在经济层面上看，企业直播服务可帮助企业进行数字化转型，提升运营效率、降低获客营销成本，受到越来越多企业客户的肯定和采用。
• 在社会层面上，疫情环境下，自2020年以来，直播用户使用率明显提升，对于企业而言，更易触达到C端用户。
• 在技术层面上，5G技术、云服务、数据智能等技术的发展和能力提升，有助于企业直播体验的提升。

2. 视频会议行业分析

以上产业图谱数据来源于《2022年中国企业直播多场景应用策略白皮书》

• 在政策层面上，《“十四五”国家信息化规划》释放出加快数字化建设进程的信号，推进数字产业化和产业数字化；
• 在社会层面上，自2020年疫情以来，中小企业的协同办公需求激增，企业数字化转型需求激增；
• 在技术层面上，5G技术加速落地，为视频会议协同提供更快更稳定的网络；

三、金融行业常见应用场景

1. 应用场景分布

对于泛行业而言，常见的应用场景主要为营销和培训，而金融行业更侧重于营销场景。

以上场景分布图来源于《金融直播的风险防范与监管》

2. 音频互动在金融行业的应用

3. 竞品分析

四、金融行业音频互动需求特征分析

总结

• 直播、视频会议均属于音视频互动，在应用场景上存在区别特征；
• 音视频互动行业，包括企业直播服务、在线视频会议，整体行业在政策、经济、社会与技术层面上来看均有较大发展潜力和发展空间；
• 金融行业在音视频互动上存在较多的场景应用，目前其他的音视频互动平台或工具有所布局，但缺乏整体的金融行业音视频互动解决方案，需要切入金融行业场景的特殊性和需求特征，进行差异化的布局；
• 金融行业的音视频互动需求特征要求产品除了具备基本的音视频底层能力、灵活外接能力外，在安全合规、互动协作、营销转化及路演管理上，都有行业特殊的要求，也是自有产品构建差异化解决方案的切入点。

在运营活动中，我们要怎样才能高效地搭建出活动主页，并在提升用户品牌感知的同时，推动用户转化？在本篇文章里，作者便结合过往的运营活动设计案例，整理了一份有关高效搭建运营活动的攻略，一起来看看吧，或许会给你一定启发。

一、前言

如今互联网大厂的运营活动不断精细化内卷，玩法也越来越新颖，从简单的分享玩法到游戏化的活动体验，怎样能吸引更多用户参与活动，达成拉新、促活、商业营收等运营目标？本“秘籍”将结合百度APP以往的运营活动设计案例，浅谈一下我们在设计工作中，如何利用有限的时间排期快速且高效的搭建出一个活动主页，在降本增效的同时提升活动的品牌感知，促进用户转化。

首先我们要了解一套完整的运营活动参与流程包含用户了从资源位开始，进入活动主页参与活动，通过弹窗、二级页等内容引导最终实现活动的全链路体验。

资源位在于获取流量，吸引用户点击，因此在资源位设计上我们会简单粗暴的去注重利益吸引或是趣味创意等手段；而活动主页是整个活动中最为关键的一环，需要不断保持用户粘性实现转化，这也是以下我们将要具体展开聊聊的内容；弹窗和二级页逐步引导用户完成一系列操作，丰富整个活动流程体验。

二、大厂的活动主页长什么样

纵观快手、支付宝等各节点的重点运营活动，除了设计的精致度一直在线外，活动主页的框架结构、信息布局以及设计元素是可以被提炼和归纳。

三、三层架构秒速拼搭运营活动

我们可以将运营活动主页拆分定义为三层结构：创意层、骨架层、对话层。

接下来将详细阐述三层构架都有哪些搭建因子，这些因子具体内容又是什么，在理解的前提下做设计，让页面搭建的变得更简单。

1. 创意层

创意层用于呈现静态或动态的主题图、或是可交互的玩法主体，例如大富翁玩法地图、集卡玩法的卡片陈列、竞猜答题玩法的问答卡片，这是我们在设计工作中要进行重点创意的部分，不同活动的创意各不相同、灵活多变。

在项目流程中通常需要先基于主玩法确定创意层的大致形态，在设计骨架层时配合创意层的大形安置各功能模块，再去丰富创意层的细节氛围元素，使活动页面的整体视效和屏效达到最优。

而在项目初期我们可以借助AI生图工具快速生成不同的视觉素材，从中获取新的设计元素、色彩搭配和构图思路，帮助我们提前预判活动视觉方向和质量。

2. 骨架层

骨架层承载操作按钮等功能模块，游戏化运营活动的首屏骨架层通常使用 “回字布局”，以便充分利用页面空间承载功能模块，包括标题模块、主操作模块、子玩法模块（子玩法入口、奖励进度）、导流模块。

标题模块：通常包含主题头图、联合LOGO、辅助功能等，布局样式具有强通用性，适用于所有活动，可以制作成组件以便快速复用。

主操作模块：具有强引导性，强化主按钮，相对弱化周边操作按钮。主操作区域在视觉层级上的优先级最高，但结构不宜复杂。而多功能按钮，看似很丰富但用户认知成本较高，不利于新人上手。

玩法模块：包括主玩法辅助模块和子玩法模块，用于呈现当前状态、参与进度等信息，通常具有强激励性，附带激励文案和动态反馈；子玩法内容尽可能用半弹层承载，减少跳转、使参与过程更沉浸。

导流模块：用于同期活动或商业导流，通常会跳出当前活动页面，因此导流位不宜过多，可采用按队列或配置的方式轮换展示更多导流入口；在回字布局的侧边，一定的留白空间也可以避免给用户参与主活动造成过多干扰。

除此之外，活动的品牌设计和素材组件也是骨架层中重要的组成部分，我们可以将构成页面并贯穿始终的最基础组件剥离出来，例如字体、颜色、符号、素材、IP、动效等，这些基础组件在整个活动流程中都会被应用到，是搭建界面的基石。

1）不同的字体传达出不同的性格特征，比如赛事竞猜活动，更适合使用具有倾斜度的非衬线体字体，体现竞赛和专业；旅行类或游戏类活动，更适合使用带有圆角的更具变化的字体，体现轻松和活力。

2）颜色跟字体一样具有很强的象征性也会决定活动的气质，比如红色代表热情激情，体现热闹氛围，适合春节情人节等活动；绿色代表健康、舒适，适合在医疗类的运营活动中使用。‍

3）符号在活动中具有装饰和辅助作用，当它与活动想表达语意相契合时，便可成为视觉锤，将活动想表达语言钉进用户心智，符号在活动中重复使用，达到加强记忆的同时也增加了活动统一性。

4）素材作为页面中主要视觉道具和装饰出现，通过对素材规范设置与排列组合，形成一个可快速调用与便捷维护组件，能够避免在相同场景下重复造新样式问题，同时增强活动品牌统一性。

5）IP形象具备典型符号性，它可以强化视觉趣味、快速拉近用户情感距离，促成心理认同与积极情绪，因此我们也要学会在活动中灵活植入IP形象，常见的场景有互动性质的主视觉、激励感受的页面、情绪体现的弹窗等。

6）动效往往是用户体验中画龙点睛的一个要素，同时也是比较耗时的一个过程，除了各活动定制化的视觉动效外，我们可对页面中的btn呼吸态、弹窗弹出、半层升起、小手引导、页面光效等部分进行动态组件化应用，让我们在一个甚至多个活动中减少设计和开发的时间成本。

通过对以上模块、组件的了解和灵活运用，骨架层的搭建才能更加的丰富和完善。

3. 对话层

在运营活动界面设计中，牵引力是十分重要的，在骨架层的基础上通过对话层可以增加互动性，从而牵引用户进行参与行为。对话层常见形式包括：tips、弹窗、向导。

tips：气泡提示框，可以灵活地附着在骨架层的各个模块上，常用于配合玩法策略在特定时机展示激励性文案，引导用户点击所提示对象。需注意的是，在同一时刻，页面一屏内建议只出现一个tips，避免分散用户注意力。

弹窗：弹窗是人机界面中最常用的组件，在游戏化运营活动中，按场景可分为3类：激励弹窗、挽留弹窗、异常弹窗。

在设计弹窗时，我们将设计工作的重点放在激励弹窗上，激励弹窗用于引导用户完成单个任务，因此需要强化用户任务的利益点和主操作按钮，将其余元素和按钮尽可能远离或弱化，从而让用户视线更聚焦，提高激励主体的引导效果。

激励弹窗的引导效果虽然最强，但本身也容易给用户阻断感，因此我们在弹窗设计上通常会融入活动IP、搭配氛围动效，以抵消打断用户时的负面感受，同时也提升激励场景的趣味度，在局部做适当变化，给用户更丰富多样的视效感受。

向导：向导用于新手教育，不同于产品功能向导的是，在游戏化运营活动中，用户往往缺乏学习的耐心，因此需要尽量使用轻量化的向导形式，我们常用的向导形式有3种：手势指针、分步引导、非模态对话框。

在玩法较简单的活动中，通常仅使用一次手势指针指引关键操作按钮。

如果玩法稍复杂，为了避免过多的按钮功能让用户感到复杂，可以使用分步引导配合手势指针，逐步展现骨架层，带领用户逐一体验多种玩法。逐步引导建议不超过3步，如果需要引导教育的内容较多，可拆分多阶段或延后引导用户进行体验。

非模态对话框是我们近期的新尝试，它即可融入创意层，也可指引骨架层，是一种灵活轻量的对话形式，当与IP搭配使用时，使用第一人称和第二人称文案，可以给用户更强的互动感、让IP更具生命力。

四、后记

工作中面对有限的时间排期，快速且高效的完成业务需求变得十分关键，通过AI生图工具、组件拆分，将每个重要元素设计出来，同时结合三层架构的方法，像玩乐高一样，把相应的“积木”拼起来，逐步进行调整和优化，一个运营活动页面就成型了。

工作效率得到提升，设计师也能有更多的精力去专注体验与细节的深耕，实现设计更多的商业价值。

最后，感谢你能读到这里，希望本“秘籍”对你有所启发。

孙悟空是中国古代小说《西游记》中的一个著名角色，他聪明机智、武功高强，在人们心目中具有很高的知名度和影响力。针对关于孙悟空的潮玩IP玩具的设计方案，我可以为您提供以下详细思路和规划：1. 思路： - 突出孙悟空的形象特点：潮玩IP玩具的设计应以孙悟空的形象为核心，突出其聪明机智、灵性和独特的外貌特征。这可以通过创新...

孙悟空是中国古代小说《西游记》中的一个著名角色，他聪明机智、武功高强，在人们心目中具有很高的知名度和影响力。针对关于孙悟空的潮玩IP玩具的设计方案，我可以为您提供以下详细思路和规划：

1. 思路：

   - 突出孙悟空的形象特点：潮玩IP玩具的设计应以孙悟空的形象为核心，突出其聪明机智、灵性和独特的外貌特征。这可以通过创新的造型设计、可动关节、嵌入式声音效果等实现。

   - 引入传统元素与现代潮流相结合：将孙悟空的形象与当下流行的潮流元素相结合，创造出与时俱进的潮玩IP玩具。例如，可以融入现代时尚服饰、配件或科技元素，使其更具吸引力。

   - 多样化的功能和互动体验：除基本的展示功能外，考虑引入一些互动设计，例如可进行动作变换、发出特定的声音效果或灯光效果等。此外，还可以开发一些小游戏或互动配套设备，让用户可以更加享受与孙悟空IP的互动体验。

2. 工具和材料：

   - 3D设计软件：使用专业的三维建模软件如AutoCAD、Solidworks等进行外观设计和结构设计。

   - 3D打印机和材料：用于制作原型和部分组件的3D打印机，并选用适当的材料如ABS或PLA进行打印。

   - 声音模块及灯光模块：用于实现声音效果和灯光效果的电子组件。

   - 涂料和装饰物料：用于在玩具表面进行绘画、装饰和涂饰。

3. 费用和时间规划：

   - 费用：由于设计中使用了多种工具、材料和技术，费用可能因具体需求而有所变化。一般而言，需要考虑到3D设计软件的许可费用、3D打印机和材料的成本、电子组件的费用以及人力成本等方面。

   - 时间规划：根据具体设计复杂度和制作工艺，制定详细的时间规划。其中包括3D设计的时间、3D打印和组装的时间、涂装和装饰的时间等。