你可以开发一个通过QA检查、通过商店审查并且在首五分钟内仍然让用户失望的跨平台应用。登录功能正常。导航技术上是正常的。API返回了数据。然而，用户评论说应用程序感觉慢、不自然或不可靠。
那就是 app 用户体验 lives.
Capacitor 和 Electron 团队经常遇到这种情况，因为功能交付是可见的，而阻力则在团队外部显现。一个 WebView 需要一秒钟的时间才能变得交互。一个桌面窗口在奇怪的状态下恢复。一个表单旋转器无法解释工作是否正在进行中还是已冻结。一个更新修复了一个 bug，但在几天内将半数用户留在了较旧的捆绑包上。这些问题在 sprint 演示中看起来并不夸张。然而，它们共同定义了人们是否会继续使用产品的关键因素。
不良 UX 不再是外观问题。 Adjust 的报告显示，90% 的用户表示，性能不佳是他们停止使用应用程序的核心原因。 在其关于移动应用程序用户体验的指南中，Adjust 提到这一点。
对于工程团队，这改变了对话。 UX 不是您在应用程序工作后添加的层次。它是性能、可靠性、清晰度和用户快速达到价值的运营结果。
对于跨平台团队，这创造了风险和机会。风险在于，同一代码库可以将相同的阻力传播到 iOS、Android 和桌面。机会在于，如果您能够测量并安全地部署更新，那么一个修复措施就可以改善每个平台的用户体验。
- 目录
- 为什么这与工程团队有关，而不仅仅是设计团队有关 ‘现代应用程序用户体验的四大支柱’
- 如何使用可操作指标测量移动应用用户体验
- 实用策略来改善跨平台应用用户体验
- 可靠的更新在持续改进用户体验中扮演了什么角色
- Putting It All Together Your First UX Improvement Cycle
介绍 为什么一个“工作”的应用程序是不够的
一个工作的应用程序完成任务。一个好的应用程序帮助人们在不犹豫、困惑或猜测的情况下完成任务。它们不是同一件事。
很多团队在发布后才发现这一点。内部测试者对产品很熟悉，所以他们耐心地通过流程。真正的用户不一样。他们冷着板，来到一个小屏幕，中间有会议，网络连接不稳定，或者笔记本电池快要耗尽。他们不在乎架构是多么的优雅，如果第一个有用的动作花了太长时间，或者如果 UI 在他们点击时暂时锁定。
技术上接受的 UX 的隐含成本
跨平台堆栈在特定方面放大了这个问题。Capacitor 应用程序经常继承了 web 假设，但这些假设在原生移动条件下不成立。Electron 应用程序可能会变得很重，尤其是当团队把桌面视为无限环境，并在启动时、后台同步和前端包中堆砌大量工作时。
结果并不是总是会崩溃。通常是更静悄悄的：
- 犹豫： 用户因为下一步不明显而暂停。
- 延迟： 用户点击按钮时，按钮反应过慢，导致用户再次点击。
- 不信任： 数据显示为过时，用户开始怀疑数据同步是否成功。
- 流失： 用户完成了注册流程，但从未真正体验到产品的核心价值。
实用规则： 如果用户描述应用程序为“笨拙”，他们通常是在报告一系列小的工程和产品决策，而不是单个视觉设计问题。
对于习惯于使用特性路线图的团队来说，这可能会感到沮丧，因为UX反馈比失败的测试用例更混乱。但是，当您将其视为系统时，它仍然可以管理。您需要查看首次会话行为、错误状态、加载行为、更新采用率和任务完成率，而不是询问界面是否“现代化”。
为什么它与工程相关，而不是仅仅是设计
在跨平台产品中，许多最高影响力的UX问题来自实现细节。缓存失效影响内容是否可信。捆绑大小影响到交互时间。状态持久性影响用户是否在重新打开应用程序时感到定向。更新传递影响到在现场中何时消除摩擦。
这就是为什么成熟的团队将应用程序用户体验视为产品、设计、QA和工程之间的共享工作。设计师塑造流程。产品优先考虑结果。工程师决定体验是否在真实条件下保持快速、稳定和可恢复。
如果应用程序只有在一切都顺利时才正常工作，用户仍会称其为故障。
现代应用程序用户体验的四大支柱
将用户体验分成四个支柱是保持其简单性的最简单方法： 可用性、性能、可靠性和价值如果其中一个支柱弱化，用户会感觉到，即使其他支柱强大。
可用性意味着路径是明显的
可用性是关于用户是否知道下一步该做什么，并且在他们犯错误时能恢复。包括导航标签、控件放置、表单行为、空状态和应用程序是否尊重平台期望。
在一个Capacitor应用程序中，糟糕的可用性通常会在团队将Web交互复制到移动设备而没有适应它时出现。悬停假设不存在。密集的设置页面变得 exhaustion。触摸目标感到拥挤。一个在桌面上看起来不错的模态堆栈在手机上变得混乱。
好的可用性不是flashy。它是缺乏摩擦的。
性能和可靠性塑造信任
性能回答应用程序是否响应。可靠性回答它是否预测性地行为。用户很少清晰地分离这些概念。他们只是知道是否信任应用程序。
A屏幕在瞬间出现但在同步过程中失败仍然是一个糟糕的体验。一个稳定的应用程序如果启动太慢也会失去用户。这就是为什么会话级别分析很重要的原因。在其关于 UX score的文章中，Dynatrace描述了一种模型，该模型将每个会话分类为 Satisfying, Frustrating, or Tolerable ，通过将性能分析和错误检测合并为一个指标。对于开发者来说，这是一个有用的思维方式，因为平均页面速度无法告诉你哪些旅程感觉破碎。
对于Electron团队来说，这通常意味着监控启动行为、内存压力和渲染器响应性。对于Capacitor团队来说，这意味着关注启动序列、桥接调用和网络依赖屏幕是否可以平稳地降级。
用户并不体验到您的架构图。他们一次会话一次体验到。
价值是人们回来的原因
一个应用程序可以是可用、快速和稳定，但仍然会低效，如果它延迟了用户获取他们来这里的价值。价值是结果层。用户是否完成了任务、解决了问题或达到了实现应用程序的目的？
许多功能丰富的产品经常会遇到困难：团队添加了表面、设置和个性化功能，但在核心旅程上没有加强。应用程序变得更加广泛而没有变得更好。
评估四个支柱的有用方法是问这些问题：
| 支柱 | Core question | 典型的跨平台故障模式 |
|---|---|---|
| 用户体验 | 用户能否知道下一步该做什么? | 将Web流程直接复制到移动或桌面 |
| 性能 | 应用是否能快速响应以产生生动感受? | 庞大的包文件、启动阻塞、过度的过渡 |
| 可靠性 | 用户是否能信任应用程序持续工作? | 崩溃、同步卡顿、UI冻结、局部状态不一致 |
| 价值 | Do users reach the reason they installed it? | 长期的引导流程、延迟激活、噪音的功能路径 |
四个支柱也会让团队的对话保持在实地。相反于说“UX需要改进”，你可以说引导流程太慢或者功能在弱连接时不可靠。这样团队就可以改进应用用户体验。
如何用可操作的指标来衡量应用用户体验
错过UX问题的最快方法是看安装数量和广泛的参与度总数而不测量摩擦。下载量并不能告诉你人们是否卡住了、变得不耐烦了还是在达到价值之前离开了。
对于跨平台应用，使用技术行为来连接用户结果的最有用的指标。您希望知道是否由于崩溃、冻结的界面、混乱的引导流程或更新间隙而使用户在旧版上留下的体验不好。
在衡量规模之前，先测量摩擦
从真实使用中暴露痛点的信号开始。它的指南中列出了重要的移动应用分析指标 UXCam建议跟踪无崩溃用户率 目标值 __CAPGO_KEEP_0__ 超过 99% 的日常, UI 停止响应 被定义为非响应状态 2+ 秒, 和 愤怒点击 被定义为 4+ 秒内在同一元素上进行的点击次数。同样的指南说，用户在首次会话中 在 60 秒内触发激活事件 的用户会保留得多。这些指标是非常有用的，因为它们直接连接到用户的感受： 用户在首次会话中
60 秒内触发激活事件
- 稳定性率 告诉你是否是广泛的不稳定还是孤立的。
- UI 停止 揭示用户认为应用程序停止监听的时刻。
- 愤怒点击 暴露看起来可用的但不明确响应的控件。
- 到达第一个有意义的动作所需的时间 告诉你用户如何快速到达第一个真正的回报。
对于实施监控的团队，一个实用的起点是设置 在Capacitor应用程序中 并使那些首次会话事件对产品和工程都可见。
产品和工程的实用指标集
不每个团队都需要一个庞大的分析分类体系。大多数团队需要一个他们信任并在每个发布中审查的小集合。
| 指标类别 | 关键指标 | 它衡量什么 | 为什么它对用户体验很重要 |
|---|---|---|---|
| 技术健康状况 | 无故障用户率 | 多少用户能够完成会话而无故障 | 稳定性是一个基本期望 |
| 技术健康状况 | 无故障会话 | 多少个会话以无故障结束 | 显示失败是否集中还是广泛 |
| 技术健康状况 | UI 停滞 | 界面不响应的时刻 | 捕捉到用户感受到的延迟，而不是后端的延迟 |
| 技术健康状况 | 愤怒点击 | 短时间内重复点击同一元素 | 表明用户感到困惑或缺乏反馈 |
| 激活 | 到达第一个有价值事件所需的时间 | 用户快速到达第一个有价值事件的时间 | 是否延迟用户体验 |
| 参与度 | 用户活跃时间 | 用户保持活跃的时间 | 与任务上下文一起使用时很有用 |
| 参与度 | 活跃用户和返回行为 | 人们是否反复回来 | 表示习惯、有用性或两者 |
| 漏斗 | 每个关键流程阶段的完成率 | 每个关键流程阶段的转换率 | 定位准确的下落点 |
| 旅程分析 | 屏幕流程和路径 | 用户实际走的路线 | 暴露死胡同、循环和拐点 |
注意事项有几点。
首先，不要认为长时间的会话一定是好的。
在支持应用中，长时间的会话可能意味着用户的困惑。
在内容应用中，长时间的会话可能意味着用户的满意。
上下文很重要。
其次，不要让平均值掩盖用户的痛苦。
平均的加载时间可能看起来是可以接受的，但某个特定的引导屏幕在老式安卓设备上可能会卡住，或者桌面同步屏幕在唤醒后可能会卡住。
对于跨平台产品来说，基础知识往往更为重要。用户感受到的速度。解释正在发生的事情的反馈。能在网络不佳的情况下生存的流程。遵循设备约定的界面。
优先解决用户感受到的速度问题
用户体验中的工程可以在不重写整个应用的情况下创造出巨大的收益。用户并不需要每个字节都立即加载。他们需要快速的证据表明应用已经准备好、响应并朝着他们的目标前进。
通常来说：
- 显示即时反馈： 按钮应该在点击时立即改变状态。如果工作开始了，应该说出来。
- 谨慎使用骨架： 它们在预测最终布局时有效。它们并不能帮助避免延迟的后端工作。
- 延迟非关键工作： 分析初始化、次要请求和低优先级资产不应该阻塞第一个有用屏幕。
- 减少资产体积： Cross-platform teams often carry oversized images, fonts, and front-end dependencies longer than they realize.
后来，当您需要向利益相关者或应用商店审查员解释更改时 创建高质量的产品演示 有助于使UX改进在截图无法做到的方式中可见
深入的可视化导览可以帮助团队在实践中确定“足够快”的概念：
为弱网络和不均匀设备设计
很多UX建议假设稳定的连接和当前硬件。实际用户生活在那个世界里。Prototypr的文章《被忽视的移动用户体验问题》 指出一个被忽视的问题：应用程序在没有网络、网络差或数据费用高的情况下如何运行。特别是，对于__CAPGO_KEEP_0__团队正在向广泛的移动用户群发布应用程序的团队来说，这是一个重要的问题 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.
缓存最后一次有用的状态：
- 如果最新的数据不可用，请显示最后一次已知的良好数据并显示清晰的状态. 缓存最后一次有用的状态：如果最新的数据不可用，请显示最后一次已知的良好数据并显示清晰的状态.
- Queue user intent： 如果用户在离线状态下草稿、提交或修改偏好，应保留操作并在适当时机同步。
- 简明说明同步状态： “本地保存”和“等待同步”比无文本的旋转器更能减少用户焦虑。
- 减少网络流量： 在可能的情况下批量请求，避免小操作后全屏重新加载模式。
对于iOS、Android和共享Web层的UI细节，值得审视 跨平台UI和UX最佳实践以优化Capacitor应用.
在恶劣条件下可靠性往往比添加另一个功能选项卡更重要。
在适当的地方保持交互模式的平淡
这就是相反的部分。出色的应用用户体验并不总是来自新颖性。它往往来自克制。
导航应与平台匹配，除非有强有力的理由不这样做。后退行为应可预测。桌面窗口应清洁地恢复。确认模式应保留风险行为的摩擦，而不是日常行为。
Capacitor 和 Electron 让您轻松共享 code。它们并没有消除尊重上下文的需要。用户仍然希望移动和桌面设备表现出像它们自己一样的行为，而不是像一个被损害的中间平台一样的行为。
可靠更新在持续性用户体验改进中的作用
改善用户体验不是一个设计项目，具有终点线。它是一个发布纪律。您衡量摩擦，发布修复，观察发生了什么变化，然后重复。
在跨平台工作中，这个循环更为重要，因为许多用户体验问题都是小的，但紧急的。一个破碎的加载状态、延迟的按钮反馈、陈旧的副本、糟糕的空白状态或不适合的引导步骤可能不会证明修复存在于 JavaScript、CSS、配置或资产中是否值得进行一个完整的商店提交周期。但是，如果修复留在现场，仍然会伤害用户。
只有当用户实际接收到修复时，修复才会有意义
许多团队谈论内部指标的迭代速度。用户体验它的方式不同。对于他们来说，问题很简单：应用程序是否快速改善了，还是同样的烦人的问题在周围停留了几个星期？
Glassbox 在其概述中指出 移动应用程序指标 现代应用程序用户体验是通过重复使用、漏斗完成和可靠性来评估的，伴随着 1天、7天和30天的保留率，以及超过99.5%的无故障会话率 as primary indicators of success. That framing shifts attention away from shipping volume and toward whether improvements reach the user journey in time to matter.
Reliable updates是成功的关键指标之一。如果半数用户仍在使用较旧的Web包，指标就会变得模糊。产品表现出混合行为。支持团队无法解释为什么一些用户仍会遇到已解决的问题。工程团队对发布影响的信心会下降。
将发布控制作为UX工作流程的一部分
将交付机制视为应用用户体验的一部分
这意味着做一些事情，如：
- 首先进行狭窄的发布： 将UX变化发送给内部用户、beta组或定义的分段之前进行广泛发布。
- 观察采用和失败： 您需要了解哪些设备更新、哪些失败以及哪些回滚。
- 将发布分组与行为相关联： 比较首次会话激活、漏斗完成或沮丧信号在变化之前和之后。
- 保留快速回滚路径： UX实验仍然是生产变更。如果新流程让人困惑，快速逆转它。
对于在Capacitor生态系统中工作的团队，解释 如何为Capacitor实时更新 使本次发布循环更容易操作化。一个选项是 Capgo,它将签名的Web包传递到Capacitor和Electron应用的目标通道，下次启动时应用更新，并提供回滚和可观察性功能。这种情况在UX变更位于Web层时很有用，需要在等待完整商店周期时进行控制的迭代。
快速迭代只有在发布安全性足够好，团队实际上会将修复发布时才有用。
强大的可观察性和更新可靠性相遇。最好的UX团队不仅仅是识别摩擦。他们在可以清晰测量差异时移除它。
将所有内容汇总起来：您的第一个UX改进周期
许多团队不需要进行UX大改造。他们需要一个紧密的周期来证明流程有效。
从用户经常访问的旅程开始。首次启动、登录、搜索、结账、表单完成或返回正在进行的任务都是很好的候选项。选择直接影响用户是否达到价值的那一个。
从一个旅程开始，而不是整个应用
A practical first pass looks like this:
- 选择一个结果指标： 首要行动时间对于许多应用来说是一个强大的候选项。
- 在流程周围查看摩擦信号： 查找崩溃、冻结、重复点击、混乱循环和放弃点。
- 定义一个狭窄的修复方案： 减少启动工作、清晰化一个屏幕、移除一个阻塞步骤或改进离线处理一个动作。
- 将其发布到一个受限的受众中： 保持爆炸半径足够小，以便您可以安全地学习。
- 比较行为后发布： 查找更干净的路径完成和更少的沮丧指标。
这强制团队遵守纪律。团队停止在抽象中辩论用户体验，开始测试某个具体实现是否改善了某个用户旅程。
快速学习，跑小圈
让循环变得足够乏味，以至于你会重复它。不要从巨大的重设计开始。那些通常混杂了太多变量，难以知道哪个变量起到了作用。
改进一条路径一次，围绕证据建立共享习惯。产品应该知道哪个指标最重要。工程师应该知道哪个事件标志成功。支持团队应该知道发生了什么变化，并且如何识别更新不匹配。 如果您正在协调发布通信，围绕新工作流或功能进行，一个结构化的 新产品介绍手册
可以帮助团队对齐消息、发布预期和内部准备。
If you’re shipping Capacitor or Electron apps and need a safer way to iterate on UX in production, 如果您正在部署Capgo或Electron应用，并需要在生产环境中安全地迭代用户体验， __CAPGO_KEEP_0__
Keep going from App User Experience: A Guide for Capacitor & Electron Teams
继续阅读：App用户体验指南：__CAPGO_KEEP_0__ & Electron团队 如果您正在使用App用户体验指南：Capacitor & Electron团队 为native插件工作做好准备，连接它 Capgo 插件目录 在 Capgo 插件目录中， Capacitor 插件由 Capgo 在 Capacitor 插件由 Capgo 中的实现细节中， 添加或更新插件 在添加或更新插件的实现细节中， Ionic企业插件替代品 在 Ionic企业插件替代品的产品流程中， Capgo 本机构建 在 Capgo 本机构建的产品流程中。
