LeapOS 3.0 digital key
Optimized digital carkey system to enhance experience conherency and integrity, delivering a seamless senseless entry experience.
Role
User experience Designer
Timeline
August. 2024 - Jan. 2025
Team
4 Devs, 4 PM, 1 UX
Impact
Adoption Rate 5% ↑

Adoption Rate Challenges
相比于依赖网络的4G远程解闭锁和需要贴靠的NFC,无感蓝牙钥匙具有近场通信优势,在地下车库等弱网环境下表现高效。然而私有蓝牙钥匙开通率未达预期。
蓝牙钥匙团队于24年末下发25年初Over-the-air(OTA)升级任务,目标提升私有蓝牙钥匙功能的开通率和蓝牙解闭锁成功率,从而整体提高用户满意度,缓解地库罚站问题。
Pains & Frustrations
我们原设计上做了UX Audit,并结合用户运营侧的一些问题反馈,发现了以下几个主要问题:
a. 阻塞的权限引导流程:目前的交互逻辑将“功能开关”与“全量权限引导”进行了强制联动(Forced Linkage),当用户点击开启蓝牙钥匙时,系统会立刻触发一个不可跳过的多页面的权限开启引导流程(Sequential Flow)。
用户被迫在“引导页”与“手机系统设置页”之间进行反复的来回跳转(Constant Switching)。只要用户中断了其中任何一步,整个功能就无法开启,极大地增加了操作阻力和流失率。
b. 权限丢失诊断流程长:用户在初次跑通流程后,往往会因系统误操作关闭后台权限。由于用户对“权限”与“蓝牙钥匙功能”之间的强依赖关系不明晰,导致钥匙失效时用户茫然。
老版本设计用户必须手动点击“故障诊断”进入三级页面做一个耗时的诊断(Time-consuming Session),诊断结果又有较多技术信息露出。这极大地增加了用户恢复功能的认知门槛和时间成本。

Closing the loop
我们的设计原则是:
「短」:操作路径尽可能缩短 「平」:信息层级尽量少 「快」:快速及时的反馈
针对上述问题,我们做了以下设计改进:
a. 取消故障诊断入口及耗时判断,将权限异常卡片前置于数字钥匙首屏,并透传至爱车页面,保证无感解闭锁最核心基础功能主链路畅通;
b. 开关与权限引导页解耦,蓝牙钥匙默认开启,列表形式展示待开启权限,针对性得给予权限开启操作引导。
c. 必要权限、辅助权限分离,降低用户的认知负担,提升权限开启率。


How UWB blends in?
核心问题:不同蓝牙通信技术导致现有交互框架无法兼容。
业务背景:原致字钥匙技术仅含私有BLE方案以及ICCOA厂商钥匙,现3.5架构涵盖ICCOA、UWB CCC 2.0&3.0、 私有NFC等多技术并存的生态,原有的产品设计已无法适应新的复杂性。
项目契机:UWB钥匙的增配以及卡片NFC体验问题导致手机私有NFC重新推进,成为数字钥匙模块体验重构契机。这迫使我们将所有钥匙类型视为一个完整的“数字钥匙“体验体系,进行顶层重新设计,而非继续打补丁。
项目目标:构建统一直观可扩展的数字钥匙交互总架构,向用户隐藏技术复杂性,提供无缝可靠的用车体验。
设计一个以“解闭锁“快速用车为中心,而非以解释“钥匙技术”的信息架构,简化成功用车的整个操作路径,尽量避免用户找不到钥匙状态异常根源而导致的罚站问题。
构建弹性交互框架,使其能够平滑接入UWB等未来新数字钥匙。

Problems Breakdown
问题拆解:
「设计一致性缺失」不同技术标准的钥匙能力集不统一,导致无法用单一,统一的交互逻辑/认知模型覆盖所有场景,被迫暴露技术细节(如UWB数字钥匙的蓝牙能力缺失导致的独立的BLE入口),入口混乱。
「决策负荷加剧」向用户呈现厂商“数字钥匙”和私有“蓝牙钥匙/NFC”等切换入口或二级页面Tab,会传递错误心智,让用户困惑于“我该用哪个?“,而非聚焦于“解闭锁“这一核心任务。
「可扩展性不足」当前架构无法兼容未来可能新增的更多钥匙类型以及手机厂商、车型能力,每次技术升级都可能引发新的体验断裂。
设计方向:
「交互扁平化」不同协议钥匙卡片显示形态统一,保持界面逻辑一致。不增加不必要层级带来的理解负担。
「能力自适应」针对不同车端/手机系统能力,动态展示卡片,保证始终有钥匙可用。
「体验一致性」解决不同协议共存状态下,配置项的冲突、重复设置问题,进行全局配置项同步,保证体验一致性。

Elastic framework for Usage Scenarios
建立动态自适应的钥匙卡片显示逻辑以适配各种使用场景。
「场景A」默认状态(未开通高阶钥匙):二级页面清晰展示两张基础钥匙卡片:「私有蓝牙钥匙(默认开启)」和「私有NFC钥匙(需手动激活)」。此状态覆盖最广泛的设备和用户,提供基础且可靠的钥匙能力。
「场景B」开通功能完备的ICCOA/CCC 3.0钥匙后,界面简化,仅显示集成的厂商钥匙卡片(如”小米手机钥匙”“苹果手机钥匙”)。因其已囊括蓝牙,NFC或UWB能力,故隐藏冗余的私有钥匙卡片,为用户提供最简洁的视图。
「场景C」开通能力受限的CCC2.0钥匙后:界面智能补充,同时显示「苹果手机钥匙(CCC 2.0)」和「私有蓝牙钥匙」卡片。此举既提供了苹果生态的NFC安全解锁,又通过保留蓝牙钥匙入口,确保用户不丢失丰富的私有蓝牙设置功能(如感应区调节)。
Elastic framework for Usage Scenarios
1、多协议弹性架构
横向拉齐BLE/ICCOA/UWB/NFC等多端诉求,收拢为统一的“数字钥匙”卡片,完成从“暴露技术细节的Tab切换”到“以‘解闭锁’核心任务为中心”的转变。
2、无感降级兜底
厂商钥匙异常时,自动复现私有 BLE/NFC 卡片,确保极端边缘场景下用户始终“有钥匙可用”,解决“罚站”。
3、能力设置双向同步
实现手机厂商钥匙与自研BLE设置项(如解闭锁方式)的双向同步,保障蓝牙能力体验一致性。


Improvement Activation rate & Usage rate
24Fall OTA后三个月数字厂商钥匙开通率月环比提升3%,从88%提升至97%。
蓝牙钥匙开通耗时感知平均缩短30s,成功开通率提升5%,蓝牙解闭锁使用率月环比提升5%。


Next Project
Workflow Tool
UX Architecture