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