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