Ray Li / Blue Champagne Portfolio

Projects become scenes with evidence.

Until real work is added, these are flagship slots. Later each row becomes a case study entry with motion stills, process frames, AI explorations, experience maps, and final outcomes.

Nebula OS Nebula OS

Nebula OS is the end-to-end HMI system created for the Nebula NEXT 01, a production four-door supercar developed under the Dreame - Starry Sky Program. I led the team from zero to one across the instrument cluster and center display, guided by a clear ambition: match the market in the overall experience and lead through standout modules. The result brings vehicle performance, contextual intelligence, and brand expression into one coherent cockpit experience, defining not only how the interface looks, but how the car communicates, responds, and feels in use. Nebula OS 是面向追觅-星空计划四门超级跑车 Nebula NEXT 01 打造的完整 HMI 系统。在项目从概念走向量产的过程中，我带领团队从 0 到 1 完成仪表与中控体验设计，并以“整体体验跑平，亮点模块领先”为目标，将车辆性能、情景智能与品牌表达整合为连贯统一的座舱体验。它不只定义界面如何呈现，也定义车辆如何与人沟通、响应并建立感受。

System / 01

Opening: Understanding the World Through the Screen 开篇：透过屏幕，理解世界

We live in both a physical and a digital world. Roads, vehicles, and surroundings shape the journey, while content, services, and entertainment shape digital life. They meet on the cockpit screen. Nebula OS keeps this relationship clear across driving, riding, and parked states: the desktop sustains awareness, cards interpret context, applications connect digital life, and the cluster protects essential driving information. 我们生活在物理与数字两个世界。道路、车辆与环境构成出行体验，内容、服务与娱乐构成数字生活。进入座舱，两者在屏幕上交汇。Nebula OS 在驾驶、乘坐与驻车场景中建立清晰秩序：桌面维持感知，卡片解释情境，应用连接数字生活，仪表守住驾驶信息。

Desktop Sustains Awareness 桌面维持感知

3D vehicle controls, wallpapers, and SR rendering have become common desktop forms for expressing technology, immersion, and personalization in smart cockpits. We organize these forms into three cognitive spaces: Drive Space presents the vehicle and its surroundings, Aura Space supports expression and mood, and Connected Space links people with vehicles and devices—helping users understand the moment before entering a task. 3D 控车、壁纸与 SR 渲染等桌面形态，已成为智能座舱强化科技感、沉浸体验与个性化表达的常见方式。我们将这些形态组织为三种认知空间：驭境呈现车辆与环境，光境承接个性与情绪，觅境连接人与设备；用户先理解此刻，再进入对应任务。

Nebula OS Drive Space ECO driving mode interface

Nebula OS Drive Space Comfort driving mode interface

Nebula OS Drive Space Normal driving mode interface

Nebula OS Drive Space Sport driving mode interface

Nebula OS blue-accent Sport Plus cockpit

01 / 05

Nebula OS Aura Space controls, widgets, and dock over a personal theme

Nebula OS Aura Space controls, widgets, and dock over a whale theme

Nebula OS Aura Space desert landscape scene

Nebula OS Aura Space translucent glass bloom scene in soft blue light

01 / 04

Beyond a 3D desktop that responds to day and night and an SR interface for active driving, we introduced driving-mode visualization into the 3D vehicle-control scene. Color, lighting, and motion express the performance character of each mode, while Sport+ shifts in sync with the interior color theme to deepen the immersive supercar driving experience.除随昼夜变化的 3D 桌面和驾驶状态下的 SR 界面外，我们还在 3D 控车场景中加入驾驶模式可视化，以色彩、光效与动态氛围呈现不同模式的性能特征；Sport+ 模式还会与内饰配色同步变化，进一步强化超级跑车驾驶体验的沉浸感。

Cards Interpret the Moment 卡片解释情境

Interviews revealed different preferences for card density, but a shared need to organize information freely by context. We atomized card content into large and small formats with flexible combinations, allowing the desktop to shift between rich detail and simplicity. In the future, voice could generate cards on demand. 访谈显示，用户对卡片的信息密度偏好不同，但共同诉求是能够按情境自由组织信息。我们将卡片内容原子化，并提供大、小两种尺寸与多种组合，让桌面在信息丰富与简洁之间灵活切换；未来还可通过语音按需生成卡片。

Nebula OS large card configurations for media, weather, energy, and tire pressure

Applications Open Up Digital Life 应用展开数字生活

Applications support both full-screen and split-screen layouts. Users can switch freely while working and swap the left and right panels at any time. This enables focused single-task use or parallel access to navigation, settings, and controls, while a consistent visual language and interaction logic keeps every layout familiar. 应用支持全屏与分屏两种布局，用户可在使用过程中自由切换，并随时互换左右区域的位置。既能在单一任务中保持专注，也能并行查看导航、设置与控制等信息；不同布局沿用一致的视觉语言与操作逻辑，让界面随任务变化，而不增加学习成本。

Nebula OS split-screen layout with navigation on the left and vehicle settings on the right

Nebula OS split-screen layout with vehicle settings on the left and navigation on the right

Nebula OS full-screen driving and navigation interface

01 / 03

VPA Exploration / 04

VPA Carries Identity Across Devices VPA 延续跨端身份

In the VPA design, beyond Dreame’s own IP characters “Bad Boy” and “Dundun Beast,” users can create a personal avatar from a photo on mobile, customize its voice, and send it to the in-vehicle system. The same VPA identity then carries across avatar selection, listening feedback, and phone-assisted task execution, making every VPA unique to its user. 在 VPA 的设计中，除了追觅本身的 IP 产品“坏小子”和“墩墩兽”，我们还可以让用户在手机端通过个人照片生成专属形象，定制声音并发送至车机。同一 VPA 身份随后延续到形象选择、聆听反馈与调用手机完成任务等状态，千人千面。

Instrument Cluster / 03

The Cluster Safeguards Driving 仪表守住驾驶

The cluster remains focused on driving decisions. Alongside familiar navigation, ADAS, and vehicle-status views, we developed multiple digital cluster styles grounded in the brand language and the character of each model. Their visual themes shift with the selected drive mode, keeping the interface aligned with the vehicle’s state and feedback. Speed, performance, energy, and alerts are reorganized by driving priority, while distinct information hierarchies and motion cues reinforce the vehicle’s personality. 仪表始终服务于驾驶判断。除了承载导航、ADAS 与车辆状态等传统驾驶信息，我们也结合品牌语言与车型特性，设计了多种数字仪表样式。仪表的视觉主题会随驾驶模式同步切换，使界面状态与车辆反馈保持一致。速度、性能、能量与告警信息按照驾驶优先级重新组织，并通过差异化的信息层级和动态反馈强化车型性格。

Nebula NEXT Sport Plus digital instrument cluster with red performance accents

Nebula NEXT Normal digital instrument cluster with driving and media information

01 / 03

Appearance / 04

Between Day and Night 昼夜之间

Day and night modes adapt contrast, brightness, and surface treatment to changing cabin light without changing the information architecture or control positions. The theme shifts naturally across environments, keeping every action familiar and legible while reducing visual strain. 日间与夜间模式会随座舱光线调整对比度、亮度与界面材质，但不改变信息架构与操作位置。主题在不同环境中自然切换，让每一次操作始终熟悉、清晰，也减少明暗变化带来的视觉负担。

System Surfaces / 05

Beyond the Desktop 桌面之外

Beyond the desktop and applications, the cockpit experience is also shaped by notifications, quick controls, device connections, climate, ambient lighting, calls, phone projection, and charging. A consistent hierarchy, surface logic, and feedback pattern connect these frequent scenarios—keeping everyday actions lightweight while allowing deeper settings to expand only when needed. 除了桌面与应用，座舱体验还由通知、快捷控制、设备连接、空调、氛围灯、来电、手机投屏与充电等系统界面共同组成。我们用一致的信息层级、浮层逻辑与反馈方式连接这些高频场景，让日常操作保持轻量，也让复杂设置只在需要时展开。

Nebula OS track telemetry with lap timing and tire pressure

Nebula OS Dreame Home Z60 Pro control interface

POC 概念验证

From late 2024 to mid-2025, I led a long-cycle POC for the P01 and P11 large SUVs, validating cockpit and whole-vehicle chassis capabilities before platform development. With limited software and hardware resources, we built a complete HMI solution combining live interfaces and demos across the instrument cluster, integrated center and passenger display, and rear overhead screen. Let’s continue below. 2024 年底至 2025 年中，我带领团队完成了一项持续数月的 POC 项目，围绕 P01 与 P11 两款大型 SUV，对座舱体验与整车底盘能力进行平台化车型开发前的全量验证。在软硬件资源尚不完备的条件下，我们尽可能地构建了一套完整的 HMI 解决方案，并以真实功能页面与演示视频交错呈现，覆盖仪表、中控与副驾一体屏，以及后排吸顶屏。让我们接着往下看。

First Things First

This section presents the integrated center and front-passenger display in an ultrawide 32:10 format. As the intelligent cockpit’s interaction hub, it is also the first visual focal point users encounter when they enter the vehicle. In response to real project needs, we developed three scenario-based desktop demonstrations around chassis, cockpit, and intelligent-driving capabilities. Together, they showcase whole-vehicle chassis performance, 3D vehicle controls, and an experience that integrates maps with intelligent driving.

01 / 03

Effective Design

At the application layer, we adopted a card-based window model to avoid a fragmented composition when apps run simultaneously across the center and front-passenger displays. At the same time, it keeps information more focused and the experience more coherent. Li Auto’s 2026 platform solution reflects a similar direction; I had already explored this approach in the ultrawide-screen concept for Great Wall Motor’s CUX 2.0 in 2021. Effective design does not chase changing forms—it solves real problems and creates a clear, coherent experience.

Playful Explorations

Beyond the HMI design, the project also included vehicle-exterior showcases and a chassis-dance capability demonstration. These pieces supported content presentation on the rear overhead display while helping internal R&D engineers with vehicle tuning and functional validation.

HMI Design Guide HMI 设计指南

This HMI design guide is grounded in Android Automotive OS platform-vehicle and POC projects, our real UI Kit, and our Icon Library. Its information architecture studies mature design guides such as Apple HIG, while every platform rule, interaction constraint, component, and state is rewritten for our own Android-based in-vehicle system. These guidelines are not fixed answers. When safety, efficiency, sense of control, and experience quality compete, they help teams decide what appears first, how the system responds, and when it should step back. 这套 HMI 设计指南基于 Android Automotive OS 平台车与 POC 项目，以及我们的真实 UI Kit 和 Icon Library。信息架构参考 Apple HIG 等成熟设计指南，但平台规则、交互约束、组件和状态都重新落到我们自己的 Android 车载系统中。这些规范不是固定答案，而是在安全、效率、控制感与体验品质发生冲突时，帮助团队判断什么应当先出现、系统怎样反馈，以及何时应该退让。

Design for people in motion

In-vehicle experience begins with an ongoing understanding of how people observe the road, interpret vehicle state, make decisions, and work with the cockpit. These principles come from real platform-vehicle and POC practice, and provide a shared basis for the foundations, patterns, and component guidance that follows. They are not a single template. When safety, efficiency, sense of control, and experience quality compete, they help teams decide what appears first, how the system responds, and when it should reduce distraction and return agency to the user.

Focus

Keep the most important task for the current journey front and center.

Every in-vehicle context has one goal that matters most. Present the information and actions needed for the next step, and let secondary capabilities appear only when useful so attention stays on the road and the task at hand.

Safety

Make risk visible before features.

Takeover requests, faults, driving restrictions, and critical vehicle states must remain stable, persistent, and easy to understand. Feedback needs to state what happened, its impact, and what to do next; essential information must never depend on transient or hidden presentation.

Control

Let the system help proactively without deciding in silence.

Suggestions, automation, and mode changes need to explain the current state, why they occurred, and what may happen next. Where safety permits, provide cancel, undo, or return paths so people always know what they can do.

Consistency

Let the same things appear and work in the same way.

Key regions, component names, control positions, states, and feedback need to follow stable rules. An interaction learned on one page should transfer naturally to another without requiring people to relearn the system.

Adaptation

Let the experience change depth with context without changing its underlying logic.

While driving, keep essential tasks with low glance and interaction demand; unlock browsing, fine adjustment, and combined configuration when parked. Adaptation is not simple removal — it reprioritizes information, input methods, and feedback timing.

Coordination

Let different inputs converge on one system state.

Actions started by touch, voice, or physical controls need to share the same result, focus, selection state, and confirmation feedback. When an input is unavailable, explain the constraint promptly and offer an alternative that does not increase driving demand.

Recovery

Let interruptions pause a task without erasing progress.

When a system overlay, permission request, network failure, or driving restriction interrupts a task, preserve completed choices and context. Return to a clear anchor afterward and state what was saved and what still needs attention.

Quality

Let every detail build trust and delight.

Use precise copy, stable layouts, reliable states, natural motion, and clear audio to reduce decision cost. Brand expression should support the task and the intended emotion, and be validated continuously in platform vehicles and POC prototypes instead of relying on decoration to create a fleeting sense of technology.

Use stable patterns across pages

Patterns explain how components work together. First decide whether information must persist or interrupt the task, then choose the system shell or transient feedback.

System shell: Status Bar and Dock

The Status Bar and Dock are persistent anchors across pages. Place product content inside this stable shell; do not treat either region as movable decoration.

Status Bar and Dock UI Kit evidence — **Status Bar · Dock**Real UI Kit composition evidence

Use real variants and reserve space

Choose Status Bar Dark/Light by mode, default fullscreen to Dock=normal, and reserve 120 at the top and 176 at the bottom.

Don’t

No redraws or page-level drift

Do not rebuild system bars per page, hide anchors without product rules, or place critical feedback inside the Dock.

States

Keep structure stable across modes

Light and dark modes can change appearance, while position, hierarchy, and content clearance remain stable.

Vehicle adaptation

Reconfirm safe areas per vehicle

Do not transfer the 3K reference directly to other resolutions, aspect ratios, or split-screen states; recheck anchors and usable content space per vehicle.

Settings tasks

Settings are not a component inventory; they form a task from understanding the current value through adjustment and confirmation. In Android driving state, keep only essential low-load settings and reserve fine configuration and long lists for parked use.

Entry

Enter by user goal, not system module

Organize groups around recognizable objects and outcomes; backend signals, domain controllers, and engineering modules must not become navigation labels by default.

Current value

Show state before adjustment

Use the row label, supporting text, and inline control to expose the current value; do not hide the existing state until a secondary page opens.

Restriction

Explain why an action is unavailable while driving

When Android Automotive UX restrictions or project safety policy blocks an action, preserve context and state that it is available when parked; never leave an entry silently inactive.

Confirmation

Confirm the result at its source

Update the control and value immediately. Use a Toast only for transient, non-blocking results, and keep the reason and recovery action on the originating row when saving fails.

Toast feedback

Use a Toast for transient, non-blocking feedback directly related to the current action. It cannot replace persistent, actionable, or safety-critical alerts.

State the result or next step directly

Use a short sentence for outcomes such as park to adjust, network unavailable, or download failed.

Placement

Clear the Dock and primary controls

Do not obscure required vehicle state; keep recovery actions in controls on the originating page.

Don’t

No safety-critical duties

Do not use for takeover, severe faults, required confirmation, or durable state, and do not tint ordinary cards red to imitate alerts.

Behavior

Keep feedback transient and non-blocking

A Toast disappears automatically, does not steal focus, and never requires acknowledgement; keep any action on the originating page.

Overlays

Popup and Slideover present supplemental choices or secondary tasks while preserving the originating context. Overlay depth follows task complexity and never hides information that should remain persistent on the page.

Choice

Use Popup for short choices and Slideover for a task

Use Popup for a few discrete choices. Use Slideover for a secondary task that requires reading, adjustment, or multiple steps, with an explicit return path.

Context

Preserve the overlay's origin

Use the mask, entry direction, and title to show origin. On dismissal, return to the initiating control without changing unconfirmed primary-task state.

Driving state

Do not open complex overlays while driving

Long copy, keyboard input, fine sliders, and multistep choices are parked-first. When the system restricts use, block or dismiss the overlay and preserve task progress.

Interruption and recovery

Calls, alerts, permissions, network changes, and Android driving-state restrictions can interrupt a task. An interruption may pause interaction, but it must not erase progress people have already understood or completed.

Preserve

Keep confirmed state and recoverable drafts

Separate applied settings from uncommitted choices. On return, make saved state explicit and avoid silent rollback or duplicate execution.

Return

Return to a clear anchor, not a transition midpoint

Restore the initiating row, current page heading, or stable system region, and synchronize focus, selection, and status feedback.

Failure

State impact and next step

When network, permission, or service failure occurs, explain the impact on the current task and offer only real actions such as Retry, Back, or Continue when parked.

Browse components by purpose

Choose a component group from the user task, then review context, behavior, and limitations. Only components that exist in the UI Kit are listed here.

System structureStatus Bar · Dock · SidebarNavigation Bar · Tab Bars
Actions & selectionButtons · Toggle · SegmentedSlider Controls · List Button
Content & settingsLists · WidgetsPage Indicator
Presentation & feedbackPopup · Slideover · ToastNotifications · OSD
Text & data inputText Fields · KeyboardsPickers

Sidebar navigation

Use Sidebar as a stable row grid for peer-level navigation. Size follows window state, while selected and unselected items share icon and label baselines.

Sidebar Full and Half variants with selected state — **Sidebar · Full / Half**Window-size and selection-state evidence

Window state selects Size

Use Full for fullscreen and Half for split or half windows; content needs determine Icon+Title versus Title.

Grid

Every row shares one baseline

The full row is 412×104 with 48 horizontal, 28 vertical, and 16 icon-label spacing; keep row, icon, and text origins aligned.

Don’t

Do not detach selection from the grid

No detached centered pill, per-row offsets, globally bright unselected items, or redrawn icons.

Non-touch input

Do not enable rotary navigation without focus states

Sidebar has no reusable focus, disabled, or overflow states; use it for touch navigation only until those states are defined.

Navigation Bar

Navigation Bar identifies the current page, hierarchy, and return path. The UI Kit provides Half, Full, and Size3 variants; window configuration chooses the size, not the temporary length of a title.

Hierarchy

Use the title for location

Name the area people are in. Do not repeat body copy or place state, promotion, or transient feedback in the title.

Back

Provide predictable return from every deeper level

Return restores the previous level's position, scroll, and selection. Android Automotive does not guarantee a hardware or system back affordance, so each project must assign that responsibility explicitly.

Adaptation

Switch the real Size variant with the window

Use the matching variant for full, half, and project-specific window states; do not invent a size by shrinking type or clipping the title.

Settings lists

Settings lists organize related settings into scannable rows with an inline control for choice or adjustment. Keep each row focused on one setting.

Organization

Group settings by task

Keep settings that support one goal together; do not divide them by backend module, signal source, or team ownership.

Focus

Keep each row focused

Make the label, description, and control answer one question together; give a related but independent setting its own row.

Control choice

Match the control to the decision

Use Toggle for a binary state, Segmented for mutually exclusive choices, Slider for a continuous value, and List Button for discrete options.

Driving load

Reserve dense configuration for parked use

While driving, keep only essential low-load adjustments; make multi-option browsing, fine sliders, and combined settings parked-first.

Copy

Use concise labels

Name the setting directly in the label; add a description only when the outcome, constraint, or condition would otherwise be unclear.

Feedback

Make changes immediately clear

Show the current choice or value clearly after an action; when saving fails or an action is restricted, state the outcome and recovery path.

Configuration	Use when	Current evidence
Default	Explain a setting without inline adjustment	Title and description styles confirmed
Segmented Controls	A small set of mutually exclusive choices	Nested composition confirmed
Slider Controls	Continuous value adjustment	Nested composition confirmed
Buttons	A clear action or a few discrete options	`Large / Border Gray / Enable / Text`

Toggle

Toggle represents an immediately applied binary state only. The source component name remains Togle and currently exposes On and Off; disabled, loading, and error states are not stable variants yet.

Binary

Use only for on or off

The setting must naturally answer whether something is enabled. Use another control or flow for more than two outcomes, required confirmation, or consequential side effects.

Immediate

Apply and reflect the change immediately

If the action still requires Save, a Toggle creates the wrong expectation; use a selection control and explicit commit action instead.

Gap

Do not improvise an unavailable state with opacity

There is no verified Disabled variant. If a project needs one, define state semantics, reason copy, and focus behavior before using it on a page.

Segmented Controls

Segmented Controls switch among a small set of mutually exclusive options in one context. The real component covers Segments, Selected, and On Materials combinations with text and icon body variants.

Exclusive

Keep one option active at a time

Options must be peers that act on the same object. Settings that can be enabled together belong in Toggles or separate rows.

Count

Keep the set short and balanced

Use short labels people can scan side by side. Move a long, explanatory, or driving-restricted set to a list or secondary page.

Material

Choose On Materials for the host surface

Do not switch material versions merely for emphasis. Validate selection meaning and contrast across light, dark, regular, and material surfaces.

Slider Controls

Slider adjusts a continuous value within a known range. The real component exposes Slider and Type combinations; fine values, ticks, focus, and restricted states require explicit project definitions and cannot be inferred from appearance.

Range

Make range and current value understandable

Familiar ranges such as temperature or volume can rely on context. Consequential values need labels, units, or discrete steps.

Feedback

Keep feedback synchronized during adjustment

Keep visual position, displayed value, and system state aligned. If application is delayed, show progress instead of letting the thumb drift ahead of the real result.

Driving state

Reserve fine adjustment for parked use

While driving, keep only essential tolerant adjustments with immediate feedback. Tasks requiring precise readings or repeated correction are parked-first.

List Button

List Button holds one to five defined buttons inside a settings row. It supports a small set of discrete actions or options and replaces neither a menu nor a continuous-value control.

Capacity

Use the real one-to-five-button variants

Let the option set determine the variant. Do not compress widths or layer external buttons to exceed component capacity.

Outcome

Label the resulting choice directly

Use explicit values such as High, Medium, and Low or clear actions; avoid abbreviations and technical fields that require interpretation.

Alternative

Move complex choice to a list or overlay

When choices exceed capacity, need explanation, or require scrolling, move them to a structured list or parked overlay instead of inventing a custom menu.

Buttons

Buttons initiate a clear action or choose from a small set of discrete options. Visual hierarchy follows task priority, while press feedback, current selection, and the business result remain distinct.

Verified scope90

Verified Button variants in the UI Kit, reused rather than redrawn in the guide.

Variant axes4

Size × Style × State × Label Type

List composition1–5

Settings rows provide verified containers for one to five buttons.

When to use

Use for actions or a few discrete choices

Use a button for an immediate action or a choice among a few clear outcomes. Use Slider for continuous values and Toggle for an immediately applied binary state.

Hierarchy

Use Style to express task priority

Decide primary, secondary, and restricted actions before choosing the matching Style from the Kit. Do not recolor a button for one page or let multiple actions compete at the highest level.

Size & placement

Choose Size by placement without shrinking the hit area

Keep height, spacing, and baselines consistent within an action group. Settings use the verified one-to-five-button containers; when options exceed capacity, move them to a list or overlay instead of shrinking buttons.

State & feedback

Separate press, selection, and execution result

State variants express component state. Press confirms input receipt, selection identifies the current value, and business feedback confirms completion. An unavailable action also states its reason and recovery condition.

Labels

Name the action and object

Prefer a concise verb and object or a clear outcome. Avoid technical fields, placeholders, and context-free labels such as Confirm. Use an icon alone only for a frequent action with stable meaning.

Driving state

Keep only essential low-load actions while driving

Dense choices, irreversible actions, and tasks requiring extended confirmation are parked-first. A restricted action never fails silently; preserve the reason, an alternative, or a clear entry to continue when parked.

Verified UI Kit list rows with button compositions — **UI Kit evidence · Buttons in settings lists**The real UI Kit shows one-to-five-button containers with consistent height and spacing; product copy and state follow the task

Slideover

Slideover is composed from the real Mask, Slideover, and Windows Grabber components and hosts a secondary task while preserving the primary page context. It is neither an ordinary card nor transient notification.

Task

Host one secondary task with a clear end

The title, content, and primary action complete one goal. Do not stack unrelated modules in one Slideover.

Dismissal

Resolve uncommitted changes before dismissal

Return directly when no side effect exists. For unsaved changes, offer Save, Discard, or Continue editing rather than letting a mask tap silently erase progress.

Restriction

Do not keep complex interaction active while driving

When Android UX restrictions activate, block or exit a complex Slideover, then restore a clear entry and saved context when parked.

Accessibility

Viewing distance, ambient light, vehicle motion, and divided attention can all change how usable the same interface feels. Accessibility is not an add-on; it keeps essential information perceivable, understandable, and operable across people and in-vehicle contexts.

Multiple cues

Never let color carry meaning alone

Express a state change with text, an icon, shape, or stable placement as well as color. Color can reinforce recognition, but it cannot replace the state name, impact, or next step people must understand.

Real conditions

Validate at in-vehicle viewing distance

Check readability in platform vehicles and POCs across day, night, seating positions, and vehicle motion. Critical states must not depend on small type, light weights, weak contrast, or transient presentation.

Alternatives

Converge supported inputs on one result

Offer touch, voice, or physical controls only where the project truly supports them, and keep their state and feedback aligned. Explain an unavailable input instead of inventing a fallback that does not exist.

Color and modes

Color starts with an information role before a visual value. Light and dark modes may change variable values, but they must not change text hierarchy, surface relationships, state meaning, or action outcomes.

Semantics

Choose by role before value

Distinguish primary and secondary text, page backgrounds, surface fills, brand emphasis, and state feedback before choosing a variable. Raw hex values are not cross-page rules.

Modes

Change appearance, not hierarchy

Check text, icons, surfaces, and imagery separately in light and dark modes. Primary hierarchy, selection meaning, and system-region placement remain stable across appearances.

State

Give state evidence beyond color

Show selected, disabled, success, failure, and restricted states through text, icons, shape, or component state as well as color. Color speeds recognition but never carries a critical conclusion alone.

Semantic	Source variable	Dark	Light
Primary text	`Labels/Priamry`	#ffffff	#000000
Secondary text	`Labels/Secondary`	#f5f6ffdb	#37383ddb
Primary background	`Backgrounds/Primary`	#000000	#edeef2
Secondary background	`Backgrounds/Secondary`	#18181a	#ffffff
Secondary fill	`Fills/Secondary`	#7b7b8029	#7a7b8029
Brand primary	`Colors/Brand/Priamry`	#d9ba71	#e6ca83
Toast background material	`Misc/Toast_Background_Materrial`	#7d7d8066	#ffffff

App icons

An app icon represents a complete application or service. Clear, distinctive artwork summarizes purpose and character, helps people find a destination during a brief glance, and sets the right expectation before entry.

Platform car Settings app icon — Settings

Platform car Around View app icon — Around View

App icons

App icons appear in the App List, Dock, and other entry points. Artwork enables rapid recognition and the label confirms identity; together they communicate which product will open, not a single action. System apps use the HMI visual language, while third-party apps preserve the identity people already know.

Composition

Platform-car app icons use a stable rounded container as a shared boundary, one clear subject to communicate identity, and limited color, light, and depth to improve recognition. Depth separates the subject rather than adding decoration; at Dock size, the app characteristic must remain more visible than the effect. Exact layers and parameters follow the source UI Kit component instead of being inferred as a universal template.

Enlarged platform car Settings app icon — Settings uses one system metaphor to establish a clear entry.

Enlarged platform car Around View app icon — Around View uses the vehicle object to describe its scope directly.

Design

Keep the core image simple and specific

Choose the object or metaphor that best represents the app and remove details that only work when enlarged. Music, Map, and Around View establish recognition through sound, route, and vehicle cues.

Keep one app's identity continuous

Preserve the core mark, name, and signature color when an app moves between entry points. Adapt subject scale, edge spacing, and optical weight without creating unrelated artwork for the list and Dock.

Preserve familiarity for third-party apps

Third-party apps retain the brand mark, primary color, and core composition people already know from phones, tablets, and other devices. HMI normalizes entry size, spacing, contrast, and rhythm without redrawing the brand or changing its color for neatness.

Use our visual language for system apps

Settings, Phone, Map, and other system apps have no external brand asset that must be copied, so they use a shared container, centered subject, and restrained depth. Each app still keeps a distinct core object instead of collapsing into one generic symbol.

Appearances

The current platform-car UI Kit node verifies app icons in a dark interface. Check boundary, contrast, and subject recognition against the real background, at actual size, and beside neighboring content. If light or other appearances are added later, preserve the core image and product identity while changing only what the environment requires. The guide does not invent appearances absent from source files.

Platform-car considerations

Validate at the real entry size

In the platform-car Dock, 56 × 56 icon artwork sits inside a 96 × 96 interaction slot. Review recognition and contrast at this size instead of judging only an enlarged source asset.

Let artwork and labels share recognition

The App List keeps a label for precise confirmation, while unlabeled entries such as the Dock require recognizable artwork. Do not bake the label into the icon or make complex text the primary recognition device.

Specifications

Dock icon artwork	56 × 56
Dock interaction slot	96 × 96
Source component radius	16 (current platform-car Dock source component)
Verified appearance	Dark

System icons

System icons communicate interface actions, objects, and states. They help people understand what they can do, what they are viewing, and what is happening. They are not app entry points and do not carry product identity; their purpose is to reduce interpretation and interaction effort through direct, stable, consistent graphics.

The Icon Library is the source of truth for system-icon components. Start from meaning, select an existing component from the relevant category, and verify line or fill state, optical weight, and its relationship with text in the real interface. When no accurate symbol exists, record the gap instead of redrawing an approximation or borrowing another platform's symbol.

Meaning

Give each icon one stable meaning

Keep the same meaning for a symbol across pages. Use different icons when similar objects lead to different outcomes instead of relying on position or context to resolve ambiguity.

State

Use line and fill for component state

Use existing component variants for selected, on, or persistent states. Color may reinforce state but cannot replace the name, impact, or next step that must be understood.

Labels

Pair text with infrequent or critical actions

Use an icon alone only for a frequent action with stable meaning across pages and low risk of serious misunderstanding. First-use, infrequent, safety-related, or irreversible actions require a clear label.

Usage

Use the real component, not a copied image

Use Icon Library components so size, states, and future updates stay connected. Do not trace, screenshot, or replace an existing icon with a text character; route missing items through the asset workflow.

Unify every input around one system state

Android Automotive OS can run across vehicles with different combinations of touch, rotary, keyboard focus, voice, and physical controls. Input methods may differ, but object names, availability, outcomes, and confirmation feedback must stay aligned. This guide treats verified touch states in the UI Kit as the current delivery baseline; other focus and feedback states require project validation.

Touch

Touch is the most fully evidenced input baseline in the current UI Kit. Component hit regions, state change, and page feedback must be validated at real in-vehicle viewing distance, seating position, and vibration conditions.

Target

Make the hit region larger than the visible mark

Use existing row height, button size, and spacing to create a continuous hit region; never make the small icon itself the only tappable area.

Feedback

Separate press, selection, and result

Press feedback confirms input receipt, selection shows the current value, and the result confirms system execution. One highlight cannot replace all three.

Driving state

Reduce repeated taps and fine aiming

While driving, keep essential actions in stable positions, shorten hierarchy, and increase tolerance. Keyboard entry, dense lists, and fine sliders are parked-first.

Rotary and focus

Android Automotive rotary input relies on the same focus mechanisms as keyboard navigation. The current UI Kit has only a small number of Focus variants; Sidebar, Lists, and primary controls do not yet form a complete focus, disabled, and overflow system, so rotary support remains a project-level gap.

Order

Match focus order to task and reading order

Move from page context and the current task to primary and then secondary actions; never follow arbitrary layer or implementation order.

Visible

Keep focus visible on every surface

Focus cannot rely on a subtle color change alone; provide a stable boundary and scroll following across light, dark, material, list, and overlay contexts.

Current gap

Define component states before claiming support

First define focus, disabled, scrolling, and return behavior for Sidebar, Navigation Bar, Lists, Toggle, Segmented, Slider, Button, and Slideover.

Voice

Voice can reduce visual and manual demand, but listening state, interpretation, and execution must remain visible. The current VPA / phone-vehicle source page is empty, so this chapter defines cross-input principles without claiming a reusable VPA component.

State

Expose listening, interpretation, and execution

People always know whether the system is listening, what object it understood, and whether the action completed; timeout, permission, and unavailable states are equally explicit.

Confirmation

Require explicit confirmation for consequential actions

For vehicle control, privacy, purchase, deletion, or irreversible outcomes, restate the object and result and provide a safe cancel path.

Sync

Synchronize voice results with touch UI

After voice changes climate, media, or settings, synchronize Toggle, Segmented, Slider, and text values instead of creating a separate voice-only state.

Physical controls

Steering-wheel buttons, knobs, and vehicle hard keys depend on the vehicle. The screen does not imitate their physical form; it provides unified feedback for state, range, unavailability, and results.

Mapping

Keep one action name across entry points

Use the same object and outcome language for hard keys, voice, and touch so one function does not gain different meanings by input method.

Feedback

Confirm whether the physical action took effect

Use OSD or stable page state when needed to show the result; never make people repeat an action to guess whether input was received.

Vehicle

Reconfirm hardware capability per vehicle

Do not infer a knob, back key, or steering-wheel mapping from another vehicle or POC. When an entry is absent, the UI still needs a complete reachable path.

AIGC AIGC

As the AIGC wave enters practical work, we turn this capability—from research, creation, and design to direction, automation, and delivery—into a reusable production capability, integrate it into different stages of project development, and explore multiple directions, including generating Figma-deliverable design documents from PRDs, design exploration, intelligent people-vehicle-home experience demonstrations, VPA explorations, and more. 随着 AIGC 浪潮进入实际工作，我们将这项能力从研究、创作和设计，到导演、自动化和交付，转化为可持续复用的生产能力，并融入项目推进的不同环节，围绕多个方向展开尝试，包括基于PRD生成Figma可交付的设计文档、设计探索、人车家智能体验演示、VPA 方向探索等等。

Connected Intelligence

GWM 长城

From 2019 to November 2023, I worked as a core designer on GWM's digital transformation across the CUX 1.0, 2.0, and 3.0 release cycles. The work below presents those outcomes in reverse order, from 3.0 to 1.0. 2019 年至 2023 年 11 月，我以核心设计师身份参与长城汽车的数字化转型，完整经历 CUX 1.0、2.0 与 3.0 三个主要版本周期。以下按 3.0 至 1.0 的倒序呈现阶段成果。

CUX 3.0

CUX 3.0 wallpaper display-area guideline

CUX 3.0 user interface control guideline

CUX 3.0 independent optimization concept

01 / 28

CUX 2.0

01 / 04

CUX 1.0

01 / 03

Hello, and I'm glad you've made it this far. I'm Xiangrui Li. I'm 31, and this is my tenth year of work. Looking back on this decade, my understanding of design, products, and myself has continued to evolve.

I started working in 2017. As I took part in more commercial projects, I came to believe that the real problem is often not a single screen, but how a product organizes information, responds to users, and can ultimately be realized by a team.

Since joining Great Wall Motor in 2019, I have worked as a core designer within the group's digital transformation strategy. I participated in three important project stages from CUX 1.0 through 3.0 and led a small team in completing vehicle-level assignments.

After joining Dreame in 2023, I continued working in HMI design across multiple proof-of-concept and production projects, while also beginning to lead teams through delivery. To me, the focus of team management is to make goals, boundaries, and standards clear; help each person contribute from their strengths; build shared judgment; and move projects forward steadily.

In recent years, AI has further changed how I work. It helps us test ideas quickly and handle repetitive work within established design standards. But the decisions that truly matter, and responsibility for the final result, still belong to people.

This portfolio does not follow the traditional PDF format. Instead, it presents the work more like a product. I hope you can explore it as you would a product: to understand my projects, and also how I observe, judge, validate, and reflect.

Looking ahead, I hope to bring these accumulated lessons into more complex products and more authentic team collaboration, creating experiences that stand up to understanding, validation, and time.

Q&A

How are innovation directions worth pursuing selected?

I do not see innovation as simply producing more ideas, but as a process of progressive convergence: first expand the pool of needs and possibilities, then evaluate them through user value, engineering feasibility, system coherence, and validation evidence, concentrating resources on the few directions that can create real product value. This approach is influenced by our company's user co-creation and “bubble-up” screening practices. The numbers change with project scale; the principle is to let valuable ideas rise through comparison and validation.

What does it mean to pursue mastery within a field?

To me, mastery is not about applying equal effort to every detail. It starts with understanding the whole problem, identifying one or two points that truly determine the experience, and developing them deeply until the result proves their value. In HMI design, that means understanding the vehicle, context, interaction, and visual system as a whole while creating a clearly above-benchmark experience in the modules that matter most.

How do you determine whether an HMI design truly works?

I evaluate it on three levels: whether it reduces cognitive and interaction cost in real driving scenarios; whether touch, voice, physical controls, visual cues, and audio feedback remain consistent across normal, exceptional, and recovery states; and whether the visual and brand expression serves the task and can be validated through a vehicle, prototype, or POC. A good HMI does more than look “high-tech”—it helps people understand faster, stay less distracted, and trust the system.

Contact

Reach me by email, phone, or WeChat.

Phone 131 6238 0561 Email 15938905125@163.com Resume View PDF

Projects become scenes with evidence.

Opening: Understanding the World Through the Screen 开篇：透过屏幕，理解世界

Desktop Sustains Awareness 桌面维持感知

Cards Interpret the Moment 卡片解释情境

Applications Open Up Digital Life 应用展开数字生活

Super Chassis

Settings

Weather

App Store

Time Album

Energy

User Manual

Video

Game