Mediation
从0到1设计一个低代码数据转换解决方案，连接原始用量数据与计费系统
项目背景
在当今快速变化的商业环境中，越来越多的企业转向基于用量的计费模式。对这些企业来说，收集用量数据仅仅是第一步，关键在于如何将这些数据清洗和汇总，以便计费系统能够顺利处理。这正是 Mediation 的价值所在。它能够实时地自动化处理原始数据，将其转化为可计费的项，并发送给计费系统。
我的角色
独立设计端到端的用户体验
时间线
2023年7月 - 2024年4月
项目成果
10个客户
(截至2025年3月)
团队
1 名产品经理，1 名研发主管
2 名前端研发，7 名后端研发
TL;DR 太长不看版
阶段一
快速定义主流程以获得领导层的支持
3天
3天内快速理解项目背景和用户需求，定义用户主流程，并与团队评审，最终获得领导层支持以推进项目。在设计过程中，根据Mediation的特点对复用的设计模式做出了针对性调整。
阶段二
拓展功能集
5个月
在开发新功能的早期阶段，我与后端开发人员紧密合作，了解功能逻辑，并将这些信息翻译成清晰易懂的界面表达。
阶段三
优化和打磨
2个月
我根据解决方案架构师团队的反馈优化了设计，并更新了Mediation的视觉设计，使其更具特色和现代感。
正式发布 (GA) 🎉
2024年2月
战略目标
Zuora 需要加速战略落地，
打造一站式用量计费解决方案。
Mediation 是连接原始用量数据与计费系统的桥梁。它不仅保证了数据的准确性，还支持实时处理，并具备足够的灵活性，响应了基于用量的定价模式的需求。适应用量计费模式是Zuora在快速变化的订阅经济中的核心战略。
用量数据
Mediation
数据处理
计费系统
收入系统
问题
Mediation 解决的是用量数据处理和变现困难的问题，用户痛点包括：
数据分散在多个来源
需要硬编码逻辑以满足业务需求
手动处理的数据缺乏可信度和可追溯性
亮点 1
通过低代码界面构建数据转换流程，
轻松整合分散的数据
亮点 2
可追溯性赋予数据更高的可信度
截止2025年3月
生产环境客户数:
10
我是如何设计这个产品的
方案背后的故事：
挑战、错误和经验教训。
从“复制粘贴”开始
我刚加入团队时，接手了几张和Workflow（我之前支持过的项目）几乎一摸一样的概念图。我被告知只需复用所有的设计元素，将几张原型拓展成完整的用户流程，以展示给领导层，争取他们的支持。
Workflow截图（线上）
Mediation概念图
阶段一
快速定义主流程
挑战 1
快速接手项目并在3天内设计出主流程
参加完第一个产研沟通会议后，我的任务是在当周内设计出用户主流程原型图。这意味着我必须在短短三天内快速理解项目背景和目标，了解目标用户及其任务，研究竞品，绘制流程图，完成原型设计并与团队评审。
理解问题
我通过产品经理沟通，并进行了桌面研究，以理解该产品试图解决的问题。
4W1H
Who
IT 团队
What
很难将原始用量数据转换为可靠的计费项目
When
随着基于用量的定价模型日益流行，IT团队需要定期将处理过用量数据上传到计费系统。
Why
数据分散在多个来源
需要硬编码逻辑以满足业务需求
手动处理的数据缺乏可信度和可追溯性
How
设计一个解决方案：
从多个来源自动收集原始数据
可配置转换流程
数据处理流程可追溯
我们面临哪些竞争对手，
他们在哪些方面表现优异或不足？
市场是一个细分领域，DigitalRoute 是我们直接的竞争对手。我查看了他们的评论，以识别他们做得好的地方和不足之处。
优点
可靠的系统
良好的客户支持
缺点
只支持预置功能
对于非技术用户来说不友好
初学者难以理解和使用
评论表明，DigitalRoute 的用户包括技术用户和非技术用户，这和我们的定义的目标用户不同。这让我思考：我们的目标用户到底是谁？跟竞品一样吗？
在与我的项目经理交谈后，我们的假设是这个工具将被多个角色使用，包括技术用户和非技术用户。IT团队将负责设置数据输入和输出，而计费运营团队将专注于构建转换流程，以满足业务需求。
总结
多受众：技术用户和非技术用户
设计应对非技术用户友好，同时在需要时为专业人士提供高级选项。
机会：专注于优化新用户的体验
竞争对手的弱点是我们的机会。
我们如何设计一个自动化数据转换产品，
支持多个数据源且转换流程可自定义，并且具备可追溯性？
遵循已有的 UI 框架和模式，进行线框设计
挑战 2
融合旧设计和新的情景需求
我被要求复用另一个产品的UI框架和设计模式，以降低开发成本和风险，因为这是一个经过验证的设计。但我避免盲目复制过去的成功做法，而是深入挖掘这两个产品的差异，确保 Mediation 的用户体验能够充分满足其独特需求
识别差异以提出更有针对性的设计
Mediation和Worklow从表面上看都是用于流程搭建和自动化执行的产品。从用户体验的角度来看，Mediation 和 Workflow 的关键区别是什么？这些区别会导致不同的设计选择吗？
差异
对设计的启示
用户及其技术知识
Workflow的用户是IT团队;
Mediation的用户除了IT团队还有计费运营，他们了解计量过程中的业务需求，但可能缺乏技术知识。
设计应对非技术用户友好，同时在需要时也为技术人员提供高级选项。对于基本配置，设计应使用简单的语言，避免使用技术术语。
流程构建的灵活性
Workflow自动化多步骤的流程，通常与外部的企业系统集成；
Mediation自动化数据转换，通常连接数据源和计费系统。
设计应引导用户定义一个数据源和一个数据去向，作为流程的起点和终点。
触发
Workflow可以通过用户手动操作、定时或基于事件来启动；
Mediation持续运行，在数据到达时即时进行处理。
设计应允许用户查看流程状态，并提供相应的操作来管理流程。
设计应注重时效性，明确告知用户当前查看的数据的接收和处理时间，并提供相应操作以获取最新数据。
运行结果
Workflow基于任务，任务数量较低，运行情况通常由API返回的结果判断;
Mediation基于数据，事件数据的数量较高（每秒最多20w个），单条事件数据可能包含数十个字段。
设计应首先展示概览，避免信息过载，并帮助用户获得所需的信息。
根据 Mediation 的特点调整设计
要点 1
Meter Stream (编辑转换流程)：
为数据源和数据去向设计占位卡片，以简化学习成本，并减少用户错误。
Mediation流程必须以数据源开始，以数据去向结束。为了明确和执行这一要求，我设计了带有占位符的空状态，避免用户错误的同时，也指引了新用户如何开始构建转换流程。
Meter Stream（编辑流程）
要点 2
Audit Trail (查看日志)：
用户可以通过分屏视图能在各组件间轻松跳转，追踪数据；
在右侧抽屉里，优先呈现关键信息，再提供更深入的探索方式。
在Audit Trail日志中，用户可以点击左侧流程中的模块，在右侧抽屉中查看输入和输出数据。然而，由于数据量大（每秒高达 20w条）且每个事件的字段多（数十到上百），在有限的空间内无法展示所有数据。
因此，我的策略是首先展示关键信息（总数据量 + 错误量），然后允许用户根据场景进一步探索，包括：
对于验证，提供全屏展开功能，让用户可以在更大的空间中查看字段。
对于调试，提供“Show Errors Only”开关，帮助用户找到有问题的事件。
此外，我将流程方向改为垂直布局。这一改变基于Workflow用户的反馈，因为用户很难在竖向视图中查看横向流程。
Audit Trail（日志）
要点 3
设计原则：为非技术用户简化，赋能技术用户
隐藏高级配置，以减少非技术用户的认知负担，同时为技术用户提供代码输入选项，以满足预置功能之外的需要。
包含高级功能的配置
主流程的原型
回顾这一阶段，在匆忙中我忽略了什么？
我们从领导层收到的重要反馈是，需要一种更简化的配置方法，以便处理简单的用例，如计算最大值、最小值或计数。这让我意识到，在设计过程中缺乏对用例的了解——我们的解决方案对于这些简单场景来说显得过于复杂。
为了解决这个问题，我们在后续的迭代中引入了 Standard Meter，这种 Meter 具有预定义且用户不可见的转换流程，用户只需进行简单的字段映射即可完成配置。
我们设想的体验，即可以自定义流程的 Meter 被称为 Custom Meter。后续在与客户接触的过程中，我们验证了自定义流程的必要性，因为我们的主要客户的用例大多涉及较为复杂的流程。
经验教训
需要有意识地寻找与填补信息缺口
最终，产品设计的目的是解决人们面临的真实问题。我从这次经历中学到，我需要不断质疑自己的假设，并意识到自己认知的局限性，因为忽视关键细节或信息空白会导致设计无法更好地满足用户需求。
阶段二
开发和扩展功能集
进入第二阶段，前端团队开始开发定稿的设计。与此同时，我开始与后端团队协作设计更多的功能模块。
挑战
转化后台逻辑为简单的用户体验
在开发新功能的早期阶段，我与后端开发人员紧密合作，了解功能逻辑，并将这些信息翻译成清晰易懂的界面。
案例
查找字段功能：在技术限制与体验之间寻求平衡
用户需求
用户需要查找来自 Zuora Billing 的字段以进行后续转换。
技术限制与解决方案
查询数据耗时较长（可能需要几个小时），严重影响运行性能。为了解决这个问题，后端团队开发了一个预加载和查找的功能，将经常使用的数据加载到一个单独的表中，并创建一个快速查找索引，从而减少多个数据库查询的需要，加速了数据处理。
对用户体验的影响
引入了额外的配置
数据预加载需要等待时间
1
/ 6
从理解后端如何运行开始着手解决问题
2
/ 6
我们如何掩盖不必要的技术复杂性以创造一个简单、流畅体验？
3
/ 6
构思流程
4
/ 6
连贯一点？
5
/ 6
我们能否消除手动操作并最小化用户感知到的等待时间？
6
/ 6
与团队讨论解决方案
1
/ 6
从理解后端如何运行开始着手解决问题
2
/ 6
我们如何掩盖不必要的技术复杂性以创造一个简单、流畅体验？
3
/ 6
构思流程
4
/ 6
连贯一点？
5
/ 6
我们能否消除手动操作并最小化用户感知到的等待时间？
6
/ 6
与团队讨论解决方案
1
/ 6
从理解后端如何运行开始着手解决问题
2
/ 6
我们如何掩盖不必要的技术复杂性以创造一个简单、流畅体验？
3
/ 6
构思流程
4
/ 6
连贯一点？
5
/ 6
我们能否消除手动操作并最小化用户感知到的等待时间？
6
/ 6
与团队讨论解决方案
1
/ 6
从理解后端如何运行开始着手解决问题
2
/ 6
我们如何掩盖不必要的技术复杂性以创造一个简单、流畅体验？
3
/ 6
构思流程
4
/ 6
连贯一点？
5
/ 6
我们能否消除手动操作并最小化用户感知到的等待时间？
6
/ 6
与团队讨论解决方案
解决方案
混合方式：在运行时自动预加载 + 手动加载
我们选择了混合方式，既支持在运行时自动预加载，又允许手动加载。这使得用户能享受自动预加载的便利，同时也能根据需要手动加载或刷新，增强了控制感。
对于新用户来说，使用 Zuora 标准字段丰富事件数据非常直观，他们只需选择所需字段。预加载过程是隐蔽的，唯一的提示是在首次运行时会告知需要较长的初始化时间。对于经验丰富的用户，他们可以手动预加载数据，从而减少等待时间。
增加功能后的Enrichment模块原型
阶段三
优化和打磨
根据内部反馈优化设计
到12月时，核心功能的开发已经完成，我们开始与更多潜在客户接触，这需要根据他们的用例定制Demo。我们与解决方案架构师团队合作准备这些Demo，他们提供了很多用户体验相关的宝贵反馈。在这个阶段，我根据他们的意见优化设计。
根据反馈优化设计的例子
改进视觉设计
当我们向现有客户介绍Mediation时，由于相似的设计，他们觉得这是另一个Workflow。为了改变这种看法，我对Mediation的视觉设计进行了改造，使其更加独特和现代（Workflow的设计多年未变）。
最终设计
反思
如果重来一次，我会有什么不同的做法？
这个项目一直节奏很快，我必须在不确定性中进行设计，许多设计决策都是基于假设做出的，并且没有机会去验证这些假设。
然而，在敏捷开发环境中，很少有明确的“完成”时刻来进行用户测试。因此，必须在项目进程中不断寻找验证机会。如果我重新处理这个项目，以下是我会做得不同的地方：
记录设计决策和假设：为设计选择提供清晰的理由，以便后续验证。
主动与内部用户互动：更主动地与解决方案架构师沟通，了解他们如何使用这个功能，并验证我不确定的设计选择。