您可以将通过QA、通过商店审核并仍然在首五分钟内让用户失望的跨平台应用程序交付。登录功能正常。导航技术上正常。API 返回数据。然而，评论说应用程序感觉慢、不自然或不可靠。
这是一个 应用程序用户体验 的领域。
Capacitor 和 Electron 团队经常遇到这个问题，因为特性交付在团队内部可见，而摩擦在团队外部出现。一个WebView需要多一点时间才能变得交互。一个桌面窗口在奇怪的状态下恢复。一个表单旋转器没有解释工作是否正在进行中还是冻结。一个更新修复了一个bug，但在几天内留下了用户基数的一半仍在使用旧的捆绑包。这些问题在冲刺演示中看起来并不夸张。然而，它们定义了人们是否继续使用产品的使用情况。
糟糕的用户体验不再是外观问题。 Adjust 的报告显示，90% 的用户说糟糕的性能是他们停止使用应用程序的核心原因 在其关于移动应用程序用户体验的指南中。对于工程团队，这改变了对话。用户体验不是在应用程序工作后添加的层次。它是性能、可靠性、清晰度和用户快速达到价值的运营结果。
对于跨平台团队来说，这既是风险，也是机会。风险在于，一个代码库可以将相同的摩擦传播到iOS、Android和桌面。机会在于，如果你能够在关键时刻监测并安全地发布更新，一次测量的修复可以改善所有地方的用户体验。
目录
- 介绍 为什么一个‘正常工作’的应用程序还不够
- 现代应用程序用户体验的四大支柱
- 如何使用可操作指标测量应用程序用户体验
- 实用策略提高跨平台应用程序UX
- 可靠更新在持续的用户体验改进中的作用
- 将所有东西都放在一起：您的第一个UX改进周期
介绍：为什么一个‘正常工作的’应用程序是不够的
一个正常工作的应用程序可以完成任务。一个好的应用程序可以帮助人们在不犹豫、困惑或猜测的情况下完成任务。它们不是同一件事。
很多团队在发布后才发现这一点。内部测试者对产品非常熟悉，所以他们在流程中很有耐心，并且带有上下文。真正的用户不一样。他们冷冰冰地来到这里，使用的是小屏幕，中间有会议，网络信号很弱，或者笔记本电池快要耗尽了。他们不在乎架构是多么的优雅，如果第一个有用的动作花了太长时间或者UI在他们点击时暂时卡住了。
技术上可接受的用户体验的隐含成本
跨平台堆栈在特定方面放大了这个问题。Capacitor应用程序经常继承了不适合原生移动条件的web假设。Electron应用程序可能会变得很重，尤其是当团队把桌面当作无限环境时，并且在启动时、后台同步和前端包中堆积起大量工作。
结果并不是总是会崩溃。有时它是更静悄悄的：
- 犹豫不决： 用户因为下一步不是很明显而停顿一下。
- 延迟： 按钮响应的时间足够长，以至于人们会再次点击。
- 不信任： 数据看起来过时了，所以用户会怀疑是否同步成功了。
- 流失： 技术上完成了导航，但人们从来没有到达产品的核心价值。
实用规则： 如果用户将应用程序描述为“笨拙”，他们通常是在报告一系列小型工程和产品决策，而不是单个视觉设计问题。
对于习惯于使用功能路线图的团队来说，这种情况可能会令人沮丧，因为UX反馈比失败的测试用例要混乱得多。但是，当您将其视为一个系统时，它仍然是可管理的。您需要查看首次会话行为、错误状态、加载行为、更新采用率和任务完成率，而不是询问界面“看起来现代”吗？
为什么这与工程有关，而不仅仅是设计
在跨平台产品中，许多最高影响力的UX问题来自实现细节。缓存失效会影响内容是否可信。捆绑大小会影响到交互时间。状态持久会影响用户是否在重新打开应用程序时感到定向。更新交付会影响到在现场中何时消失的摩擦。
这就是为什么成熟的团队会将应用程序用户体验视为产品、设计、QA和工程之间的共享工作。设计师塑造流程。产品优先考虑结果。工程师决定在真实条件下体验是否保持快速、稳定和可恢复。
如果应用程序只有在一切都顺利时才工作，用户仍会将其称为故障。
现代应用程序用户体验的四个支柱
将UX从模糊中分离出来的最简单方法是将其分成四个支柱： 可用性、性能、可靠性和价值。如果其中一个弱点，用户会感觉到，即使其他几个都很强。
易用性是指路径明确
易用性是指用户是否能知道下一步该做什么，并且在出错时能恢复。包括导航标签、控件放置、表单行为、空白状态以及应用是否尊重平台期望。
在Capacitor应用中，易用性往往表现为团队将web交互复制到移动设备上却没有适配。悬停假设不存在。密集的设置页面变得令人疲惫。触摸目标感到拥挤。一个在桌面上看起来不错的模态堆栈在手机上却变得混乱。
好的易用性不是炫酷的。它是缺乏摩擦的体现。
性能和可靠性塑造信任
性能回答应用是否响应迅速。可靠性回答应用是否预测性地行为。用户很少清晰地分离这些概念。他们只是知道是否信任应用。
一个在瞬间显示的屏幕但在同步时失败仍然是一个糟糕的体验。一个稳定的应用但需要太长时间才能变得交互也会失去用户。这就是为什么会话级别分析很重要。在其关于"UX score"的文章中，Dynatrace描述了一个模型，该模型将每个会话分类为"满意的","令人沮丧的"或"可忍受的" 通过将性能分析和错误检测合并为一个指标。对于开发者来说，这是一个有用的思维方式，因为平均页面速度无法告诉你哪些旅程感到破碎。易用性 易用性 易用性和愉悦性
对于 Electron 团队来说，这通常意味着监控启动行为、内存压力和渲染器响应性。对于 Capacitor 团队来说，这意味着关注启动序列、桥接调用以及网络依赖的屏幕是否能优雅地降级。
用户并不体验到您的架构图。他们体验的是一次会话一次。
价值是人们回来的原因
一个应用可以是可用的、快速的、稳定的，但如果延迟了用户获取自己想要的东西的时刻，它仍然可能会表现不佳。价值是结果层。用户是否完成了任务、解决了问题，还是达到了打开应用的理由所带来的好处？
许多功能丰富的产品经常会遇到困难：团队会添加新的界面、设置和个性化功能，而不是优化核心体验。应用程序变得更加复杂，而不是变得更好。
评估四个支柱的有用方法是问这些问题： 1. 什么是我们的目标？ 2. 我们的优势在哪里？ 3. 我们的劣势在哪里？ 4. 我们的机会在哪里？
| 柱子 | 核心问题 | 跨平台应用常见的故障模式 |
|---|---|---|
| 易用性 | 用户知道下一步该做什么吗？ | 在移动或桌面设备上，web样式的流程保持不变 |
| 性能 | 应用是否能快速响应，给人一种活跃的感觉? | 重度打包、阻塞启动、过度过渡 |
| 可靠性 | 用户是否能信任应用持续工作? | 崩溃、卡顿同步、冻结UI、不一致的本地状态 |
| 价值 | 用户是否能达到安装它的目的? | 漫长的引导、延迟激活、噪音的功能路径 |
四个支柱也使团队的对话保持在实地。相反，团队不再说“UX需要改进”，而是说引导路径是可理解的，但太慢了，或者功能是有价值的，但在弱连接时不可靠。这样团队就能改善应用用户体验。
如何用可操作指标来衡量应用用户体验
避免UX问题的最快方法是看安装数量和广泛的参与总数，而不测量摩擦。下载量并不能告诉你人们是否卡住了、变得不耐烦了，还是在达到价值之前就离开了。
对于跨平台应用，具有最实用的指标是将技术行为与用户结果联系起来。您希望知道是否由于崩溃、冻结的界面、混乱的引导程序或更新延迟而导致的糟糕体验。
在衡量规模之前，测量摩擦
从实际使用中暴露痛点的信号开始。在其关于 移动应用分析指标的指南中，UXCam建议跟踪 无崩溃用户率 目标值为 每日, UI冻结 定义为 2秒以上未响应 [__CAPGO_KEEP_0__]快速点击 被定义为 在1秒内点击4次以上 在同一个元素上。同样的指南说，用户在 60秒内触发激活事件的用户 在首次会话后的用户留存率会大大提高。
这些指标非常有用，因为它们直接连接到用户的感受：
- 无崩溃用户率 告诉你崩溃是否是普遍现象还是孤立现象。
- UI冻结 揭示了用户认为应用程序停止响应的时刻。
- 快速点击 expose 控制器看起来可用但不响应明显。
- 到达第一个有意义的动作的时间 告诉你用户如何快速到达第一个真正的收获。
对于实施监控的团队，一个实用的起点是设置 在Capacitor应用中 并使那些首次会话事件对产品和工程都可见。
产品和工程的实用指标集
并不是每个团队都需要一个庞大的分析分类法。 大多数团队需要一个小的、可信赖的、每次发布都要审查的指标集。
| 指标类别 | 关键指标 | 它衡量什么 | 它对用户体验的重要性 |
|---|---|---|---|
| 技术健康 | 无崩溃用户率 | 用户完成会话的崩溃率 | 稳定性是基本期望 |
| 技术健康 | 无崩溃会话 | 会话结束崩溃率 | 显示崩溃是否集中还是广泛 |
| 技术健康 | UI冻结 | 界面非响应的时刻 | 捕捉到用户感受到的延迟，而不是后端计时 |
| 技术健康 | 愤怒点击 | 短时间内重复点击同一元素 | 表示混乱或缺乏反馈 |
| 激活 | 到达第一个有价值事件所需的时间 | 用户快速到达第一个有价值事件 | 显示是否延迟引导有价值 |
| 参与度 | 会话长度 | 用户活跃时间 | 在与任务上下文一起使用时有用 |
| 参与度 | 活跃用户和回访行为 | 是否有用户反复来访 | 表示习惯、有用性或两者 |
| 漏斗分析 | 步骤转化 | 每个关键流程阶段的完成率 | 定位准确的掉落点 |
| 旅程分析 | 屏幕流程和路径 | 用户实际采取的路线 | 暴露循环、死胡同和拐点 |
在这里，几个注意事项很重要。
首先，不要认为更长的会话一定是好的。 在支持应用中，长会话可能意味着混乱。 在内容应用中，它可能意味着满意。 上下文很重要。
第二，不要让单个平均值掩盖用户的痛苦。 中位数的加载时间可能看起来是可接受的，而在旧版Android设备上，特定的引导屏幕可能会冻结，或者在唤醒后休眠时，桌面同步屏幕可能会挂起。
跟踪用户失去信心的时刻，而不是仅仅关注你的仪表板看起来健康的时刻。
目标不是收集一切。 而是建立一个可以帮助你决定下一步该修复什么的测量层。
改善跨平台应用用户体验的实用策略
团队经常试图通过添加首先的细节来改善用户体验。 新的动画，更多的空白状态图像，更加丰富的设置，额外的个性化。 这些变化可能会有所帮助，但它们很少能拯救一个弱的体验。
对于跨平台产品，基础知识往往更有效。 用户可以感受到的速度。 解释发生什么的反馈。 能够在网络不佳时生存的流程。 支持设备的界面。
优化用户感知的速度
用户体验中的工程可以在不重写整个应用的情况下创造出巨大的用户体验收益。 用户不需要每个字节都加载得很快。 他们需要快速的证据表明应用准备好了，响应良好，并朝着他们的目标前进。
通常意味着：
- 显示即时反馈： 按钮应在点击时立即改变状态。如果工作开始，请说明。
- 谨慎使用骨架屏幕： 它们在预测最终布局时有效。它们不会帮助隐藏可避免的后端延迟。
- 延迟非关键工作： 分析初始化、次要请求和低优先级资产不应阻塞第一个有用屏幕。
- 减少资产重量： 跨平台团队经常携带比实际需要的大型图像、字体和前端依赖项。
当您需要向利益相关者或应用商店审查员解释更改时， 创建高质量的产品演示 有助于使UX改进在截图无法做到的方式中可见。
在实践中，“足够快”的概念需要团队达成一致，一个更深入的视觉导览可以帮助实现这一点。
适应弱网和设备不均衡的设计
在很多 UX 建议中，假设网络连接稳定，硬件设备也很新。然而，真实用户并不是生活在这样的世界中。Prototypr 上有关的文章 移动端用户体验问题 calls out a neglected question: how the app behaves with no network, poor network, or expensive data. That’s especially important for Capacitor teams shipping to broad mobile audiences.
实用性容错模式包括：
- 缓存最后有用的状态： 如果没有最新的数据，显示最后一次已知的有效数据并显示状态。
- 用户意图队列： 如果有人在离线状态下草拟、提交或修改偏好，应保存该操作并在适当时机同步。
- 简明地解释同步状态： “本地保存”和“等待同步”比无文本的加载动画更能减少用户的焦虑感。
- 减少网络噪音： 在可能的情况下批量请求，避免在小操作后进行全屏刷新模式。
对于跨 iOS、Android 和共享 Web层的 UI 详情，值得审视 跨平台 UI 和 UX 实践以优化Capacitor应用.
在恶劣条件下可靠性往往比添加另一个功能选项卡更重要。
在正确的地方保持交互模式的平淡
这是反对派的一部分。出色的应用用户体验并不是来自新颖性的。它往往来自克制。
导航应与平台匹配，除非有强烈的理由不这样做。后退行为应可预测。桌面窗口应清洁地恢复。确认模式应保留摩擦力以风险较高的动作，而不是日常动作。
Capacitor和Electron使它容易共享code。它们并没有消除尊严上下文的需要。用户仍然期望移动和桌面表现像自己一样，而不是像一个妥协的中间平台一样。
可靠的更新在持续改进用户体验中的作用
改进用户体验不是一个设计项目的完成线。它是一个发布纪律。您衡量摩擦力，发布修复，观察发生了什么变化，然后重复。
即使是在跨平台工作中，这个循环也更为重要，因为许多UX问题虽然小，但却迫在眉睫。一个破碎的加载状态、延迟的按钮反馈、陈旧的副本、糟糕的空白状态或不适合的引导步骤如果修复在JavaScript、CSS、配置或资产中可能不值得进行一次完整的商店提交周期。但是，如果它留在现场，仍然会伤害用户。
只有当用户实际接收到UX修复时，才会有意义。
很多团队都在谈论内部指标的迭代速度。用户体验它的方式不同。对于他们来说，问题很简单：应用程序是否快速改善了，还是同样的烦人的问题在周围停留了几个星期？
Glassbox在其概述中指出 移动应用程序指标 现代应用程序UX被评判为重复使用、漏斗完成和可靠性，包括 日-1、日-7和日-30的保留率 以及
99.5%以上的无故障会话率
作为成功的主要指标。这种框架将注意力从运输量转向是否能在时间内将改进传递给用户旅程以至于它能发挥作用。可靠的更新是其中的一部分。如果半数观众仍在使用旧的Web包，指标就会变得模糊。产品会看到混合行为。支持无法解释为什么一些用户仍然会遇到已解决的问题。工程师会失去对发布影响的信心。
A更好的模式是将交付机制视为应用程序用户体验的一部分。
这意味着做一些事情，如：
- 逐步发布： 将UX变化发送给内部用户、beta组或定义的分段之前广泛发布。
- 监测采用和失败： 您需要对哪些设备更新、哪些失败以及哪些回滚有可见性。
- 将发布小组与行为关联起来： 比较首次会话激活、漏斗完成或沮丧信号在更改之前和之后。
- 保留快速回滚路径： UX实验仍然是生产更改。如果新流程混淆了人们，快速逆转。
在Capacitor生态系统中工作的团队，服务将解释 如何为Capacitor实时更新工作 让本次发布循环更容易操作化。一个选项是 Capgo，它将签名的Web包传递到目标渠道，适用于Capacitor和Electron应用，下次启动时应用更新，并提供回滚和可观察性功能。这种情况在UX变化位于Web层时有用，需要控制迭代，而不必等待完整的商店周期。
快速迭代只有在发布安全性足够好时才有用，团队才会实际发布修复。
强大的可观察性和更新可靠性相遇。最好的UX团队不仅仅是识别摩擦，他们还会在可以清晰地测量差异时移除它。
将所有内容放在一起 Your First UX Improvement Cycle
许多团队不需要UX重构。他们需要一个紧密的周期来证明流程有效。
从用户经常访问的旅程开始。首次启动、引导、登录、搜索、结帐、表单完成或返回正在进行的任务都是不错的候选项。选择直接影响用户是否达到价值的那一个。
从一个旅程开始，而不是整个应用
一个实际的第一步看起来像这样：
- 选择一个结果指标： 到达首个有意义动作的时间是一个强大的候选者，适用于许多应用。
- 检查流程中的摩擦信号： 寻找崩溃、冻结、重复点击、令人困惑的循环和放弃点。
- 定义一个狭窄的修复方案： 减少启动工作、清晰化一个屏幕、移除一个阻塞步骤或改善离线处理的一个动作。
- 向受限的受众发布： 确保爆炸半径足够小，以便您可以安全地学习。
- 发布后比较行为： 寻找更干净的路径完成和更少的沮丧指标。
这强制了纪律。团队停止在抽象中辩论UX，并开始测试是否一个具体的实现改善了一个具体的用户旅程。
运行一个小循环并快速学习
关键是使循环足够有趣，以便您会重复它。不要从一个巨大的重设计开始。那些通常混杂了太多变量，难以知道哪个变量起到了作用。
相反，改进一个路径一次，并建立围绕证据的共同习惯。产品应该知道哪个指标最重要。工程师应该知道哪个事件标记成功。支持应该知道发生了什么变化，并如何识别更新不匹配。如果您正在协调发布通信以围绕新工作流或功能进行，一个结构化的 新产品介绍手册 可以帮助团队统一宣传信息、推出预期和内部准备工作。
好的应用程序用户体验通常是这样产生的。不是从一个单一的精彩的重新设计中产生的，而是通过许多经过测量的修正来消除犹豫、恢复信任并帮助用户更快地获得价值。
如果您正在运送Capacitor或Electron应用程序，并需要在生产环境中安全地迭代用户体验，则 Capgo 值得评估。它让团队能够快速推送Web层修复、复制更改、配置更新和资产，使用目标发布、回滚保护和发布可见性，这使持续改进用户体验变得更容易管理。
从App用户体验：Capacitor和Electron团队指南
继续 App User Experience: A Guide for Capacitor & Electron Teams App用户体验：__CAPGO_KEEP_0__和Electron团队指南 Capgo Plugin Directory Capgo插件目录 Capacitor 插件由 Capgo 为 Capacitor 插件由 Capgo 的实现细节 添加或更新插件 为添加或更新插件的实现细节 Ionic 企业插件替代品 为 Ionic 企业插件替代品的产品工作流程 Capgo 原生构建 为 Capgo 原生构建的产品工作流程
