如何在 Web3 产品中构建符合 Web2 用户预期的用户体验

Web3 产品的一项核心挑战，是底层技术逻辑与用户认知之间存在明显差距。

用户想完成的事情通常很简单：收款、转账、兑换资产。但进入钱包后，他们可能需要先理解 Gas、原生代币、网络、Swap 和 Bridge，再决定下一步怎么操作。

对于已经习惯 Web2 支付工具和中心化交易所的用户，这些额外判断会增加认知负担，也会直接影响首次充值和交易的完成率。

在我看来，Web3 产品经理需要做的是：将链上的技术能力转化为用户熟悉的操作方式，让产品承担更多复杂度。

结合对不同钱包的观察，以及 GM Wallet 的产品实践，我想从三个方向展开：流程简化、用户认知，以及交易反馈。

一、隐藏复杂度并缩减流程，降低用户的决策成本

1. Gas 抽象：将网络费用纳入交易流程

“钱包里明明有 USDT，为什么还需要先买 ETH 才能转账？”

这类问题暴露了 Web3 与传统支付体验之间的差距。用户能理解转账需要手续费，却未必能理解为什么必须提前持有另一种资产来支付。

借助账户抽象相关能力和 EIP-7702 等方案，钱包可以引入 Gas 代付、以其他代币支付网络费等机制，减少用户预先准备原生代币的需要。EIP-7702 官方提案

MetaMask 已经提供了相应体验：部分交易支持使用其他代币承担网络费，也有由平台承担费用的代付场景。具体由谁付费可以不同，但它们都减少了“先购买 Gas 资产，再回来操作”的流程中断。MetaMask 网络费说明、代付说明

对用户而言，确认页需要清楚呈现的就是：转账金额、手续费、费用支付资产，以及预计到账金额。

Gas 抽象的产品价值，在于降低交易门槛。用户理解“这笔操作需要多少手续费”，就应该足以完成大多数日常操作。

Gas Limit、Gwei 等参数可以保留在高级设置中，默认流程应围绕转账本身展开。

MetaMask 手续费支付或 Gas 代付界面

2. 统一 Swap 与 Bridge，以用户意图组织交易入口

用户的需求是“把资产 A 换成资产 B”，至于需要同链 Swap，还是跨链 Bridge，取决于资产所在的网络。

如果产品在流程开始时就让用户选择 Swap 或 Bridge，就相当于要求用户先理解执行方式，再表达交易需求。

OKX Wallet 将 Swap 和 Bridge 区分为不同模式；Trust Wallet 则将同链与跨链兑换整合进统一的资产选择流程。对于面向主流用户的钱包，我更倾向于后一种信息架构。

在同一个页面中，用户选择支付资产、目标资产和数量，钱包根据资产与网络组合判断交易类型，完成Bridge/swap选择，再展示报价、总费用和预计耗时。

这里的关键是减少用户对执行路径的判断。资产所属网络仍然要明确展示，因为它决定了用户最终收到什么、在哪里使用。

以用户意图组织入口，可以让复杂的多链交易呈现为一个连续的兑换任务。 对产品来说，这比简单地把两个按钮放到同一页更重要。

Trust Wallet 的统一兑换页

OKX Wallet 的 Swap／Bridge 模式

3. 降低跨应用操作摩擦

不少 Web3 钱包的充值体验，在展示收款地址后就结束了。但用户的任务才刚进行到一半。

接下来，他们还需要打开其他钱包或交易所，找到转账入口，粘贴地址、选择网络，再回到当前钱包查看到账情况。跨应用切换和重复输入，都会增加操作成本与流失机会。

GM Wallet 的直接跳转充值，就是围绕这段完整路径做优化：从当前钱包选择资金来源，直接进入支持的钱包或交易所操作流程，减少用户自行寻找入口和复制粘贴的步骤。

对产品而言，这属于首次充值转化的一部分。评价体验时，应关注用户能否顺利把资金转入，而不只是收款页面是否足够简洁

GM Wallet 选择资金来源并跳转充值的流程

4. 拆分较长流程

用户在单次操作中的耐心有限，尤其是在登录和创建钱包阶段。注册账号、设置钱包、备份助记词等步骤如果集中出现，很容易让用户在体验产品价值之前就流失。

在 GM Wallet V3 中，我们重新梳理了首次使用流程，将创建钱包的主要路径从接近 20 张页面缩减到 3 张页面。创建阶段只保留必要操作，账号完善、钱包备份等任务按使用场景逐步引导。例如，在首次收款前引导用户完成备份，此时用户即将存入资产，更容易理解备份的必要性，也更有动力完成。

渐进式引导，核心是把任务安排在用户有明确需求的时刻。产品经理需要同时考虑首次使用的转化率与后续关键步骤的完成率，让用户更快进入产品，也在资产转入前完成必要的安全准备。

GM Wallet V2 与 V3 创建钱包流程对比：从接近 20 张页面缩减到 3 张页面。

GM Wallet UI V3版本创建/导入流程

GM Wallet UI V2版本的创建流程

二、兼容主流用户与专业用户的心智模型

同一个功能，不同用户可能有完全不同的理解方式。收款流程就是一个典型例子。

Kraken Wallet 的收款流程以钱包和网络选择为起点，再展示地址。对于熟悉多链账户体系的用户，这很直接：我需要某条链上的收款地址。

Kraken Wallet收款页面

但对于习惯中心化交易所的用户，认知顺序通常是“我要收什么币”，然后才是“使用哪条网络”。这种已有的心智模型，会影响他们如何理解钱包里的入口与信息。

因此，在 GM Wallet 中，我们采用了更符合这类用户习惯的默认路径：

选择币种 → 选择网络 → 展示收款地址。

GM Wallet默认收款流程

对专业用户，则提供长按快捷入口，直接展示收款地址，减少每次收款时的重复选择。

GM Wallet快捷收款

这种交互分层，让默认流程承担必要的引导，同时为熟练用户提供更高的操作效率。面向主流用户的 Web3 产品，需要尊重他们从 Web2 和交易所带来的使用习惯；面向专业用户，也要保留直接访问核心功能的能力。两者可以通过默认路径与快捷操作共存，不必让所有人接受同样的步骤。

三、弥合链上延迟与即时反馈之间的预期差

Web3 交易具有明显的异步特征。转账需要区块确认，跨链还涉及源链、跨链服务和目标链的协同处理。用户完成签名，并不意味着整个任务已经完成。

这也是 Web3 产品体验中容易产生焦虑的环节：资产已经扣除，目标资产还没出现，界面甚至可能没有“处理中”。

链上结算需要时间，UI 仍然可以及时反馈。 产品要把交易进展转化为用户能理解的状态，让用户知道资金在哪里、接下来会发生什么，以及是否需要继续操作。

用交易状态机管理完整生命周期

OKX Wallet 跨链流程中值得参考的一点，是提交后持续跟踪交易进度，并提供预计耗时与交易记录入口。OKX 跨链流程说明

设计类似能力时，需要先建立交易状态机，再将状态映射到界面。以跨链为例，可以表达为：

待签名 → 已提交 → 源链已确认 → 跨链处理中 → 目标链已到账。

OKX Wallet较完整的交易状态

同时覆盖失败、超时和需要用户继续操作的情况，让交易从发起到结束都有对应反馈。

其中，源链交易成功与目标资产到账也必须区分。用户关心的是这次跨链是否完成，产品应跟踪整个交易生命周期，而不止是一笔链上交易的回执。

例如，“源链已确认，正在等待目标链到账，你可以离开此页面”，就同时说明了当前进度和用户可以采取的行动。

让状态反馈跨越页面和会话

用户关闭详情页、切换 App 或重新打开钱包后，应该能够继续查看同一笔交易的最新状态。

超过预计耗时，也需要明确说明目前的进展和后续入口。超时不等于失败，引导用户重复发起交易反而可能增加问题，应该适当引导用户联系客服解决焦虑

对 Web3 产品来说，完整的状态反馈能减少重复刷新、重复提交和查询交易的负担，也能让用户更有把握地等待最终结果。

后端建设：用 Web2 的服务能力承接 Web3 数据

上述体验需要后端能力支撑。只在前端优化页面，很难解决多链数据加载、持续交易跟踪和离线通知的问题。

在 GM Wallet，我们通过后端扫块和链上监听，持续整理所支持网络上的用户钱包交易与历史记录，再通过统一 API 提供给 App。

这层服务承担了链上数据的索引、聚合与状态同步，让客户端可以直接读取结构化的余额、交易历史和交易进度，减少每次打开 App 时对多条链逐一查询和拼接的依赖。

通过主动推送，完成交易通知闭环

主动的系统推送

当后端监听到收款或交易状态变化后，可以通过系统通知触达用户。即使用户没有打开 App，也能及时获知结果，并通过通知进入对应交易详情。

这让钱包从“用户打开后才查询”，变成持续提供交易反馈的服务。对于资金类产品，到账通知本身就是用户体验的重要组成部分。

通过缓存与异步刷新，改善加载体验

余额和历史记录可以由后端缓存，App 打开后先展示已有数据，再异步更新。这样可以缩短首屏等待，让用户更快看到可用信息。

缓存也需要配合状态同步：待确认交易应明确标记，新交易发生后及时更新相关数据，提交交易前重新校验余额和费用。加载速度与数据准确性，需要根据不同场景分别抉择

从架构上看，我们是在链上能力与客户端之间，补上一层成熟的 Web2 服务能力。它负责数据组织、缓存、通知和状态管理，让 Web3 App 更符合用户对加载速度与即时反馈的预期。

做 Web3 产品，既需要理解协议和链上机制，也需要判断哪些复杂度应该由系统承担、哪些信息需要让用户看见。

一切都一切，最终都指向同一个目标：降低用户完成任务的成本。

Web3 还有很多体验值得优化，希望能和更多关注产品与用户体验的朋友一起 Build