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

我国支付体系由众多参与者构成，其中包括人民银行、商业银行、清算机构、三方支付机构、四方支付机构等，如图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生图工具、组件拆分，将每个重要元素设计出来，同时结合三层架构的方法，像玩乐高一样，把相应的“积木”拼起来，逐步进行调整和优化，一个运营活动页面就成型了。

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

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