In Production

Interaction Design

Automotive HMI

SDK Design System

Multi Brand

Accessibility Platform for VW brand vehicles

Inclusive mobility. Volkswagen Group. CARIAD Inc

I designed how people learn to use in-vehicle accessibility features and helped define where they go to manage them.

MY ROLE

Senior UI Designer

In partnership with UX researchers, SWE, and the Accessibility leader

My Focus

Design of Tutorials and accessibility settings. Development with engineers and implementation in a multi-brand environment

TIMELINE

2022 – 2024
V1 released 2025, V2 in 2026

In Production

SUCCESS

Integrated into 4+ brands architected on the SDK. Shipped in 20M+ vehicles globally

01 Brief

02 Tutorial

03 Menu

04 Outcome

01 - Brief

Bring familiar tools into the car

Regulatory deadline

The CVAA (Communications and Video Accessibility Act) was extended to connected vehicle interfaces. CARIAD had 18 months to ship compliant accessibility features across multiple brands for a platform where a misplaced touch could cause a crash.

The Translation problem

Every accessibility pattern users relied on VoiceOver, TalkBack, Switch Control was designed for a hand-held screen. In a vehicle traveling at 70mph, those same patterns become dangerous. Nothing could be copied directly from a mobile.

Scale with no room for error

Unlike a mobile app update, a flaw in this system ships inside 20 million vehicles. There's no over-the-air quick patch for a driver on a German autobahn. Every decision had to be defensible before it shipped.

02 - ONBOARDING

Teach one interaction at a time

EXPLORE THE TUTORIAL PATTERN

01 / INTRODUCE

Start with what the feature does

A short explanation gives the user a reason to try the interaction.

People who already relied on accessibility tools on their phones brought those expectations into the vehicle. The interface, input methods, and attention demands were different.

I reviewed mobile accessibility patterns and drew on research with people with disabilities to design the tutorial sequence, write on-screen instructions, and determine when the vehicle interface needed a prompt or confirmation. I collaborated with UX research, accessibility, and engineering partners.

I broke the tutorial into steps so each screen could explain one action. I also designed supporting notifications, pop-ups, and microinteractions for moments when users needed guidance within the vehicle interface.

Illustrative sequence showing the design logic. Production screens appear on the original case study.

02 / PRACTICE

Prompt a single action

The tutorial places instructions next to the action the user is learning.

03/ CONFIRM

Explain what just happened

Feedback closes the loop so the user knows the action was registered.

Actual Figma Screen for one of the feature. Production screens appear on the original case study.

03 - ACCESSIBLITY MENU

Actual accessibility menu image for for Audi and Porsche

Accessibility Menu in Audi. User sees only features relevant to them; no "full accessibility mode" forcing all features on.

Accessibility Menu in Porsche. Same interaction logic; Porsche design token layer. No additional feature development required.

Give each feature a predictable home

I helped define where accessibility settings live and how they’re organized. A dedicated menu gives users one place to return to, with separate controls for the features they choose to use.

One entry point

Keep the path to accessibility settings consistent so people can find it again after setup.

Individual controls

Let people independently turn on the features they need. The original case study shows how Audi and Porsche applied that shared interaction logic.

04 - OUTCOME

Shared behavior across brands

The wider team delivered an in-vehicle accessibility platform. The Audi and Porsche implementations illustrate how a shared interaction model can work with each brand’s visual language.

My contribution centered on the steps users take to learn a feature and the path they use to find and manage it afterward.

One SDK,
four brands

The most scalable design decision in this project wasn't a UI pattern — it was the architecture. Rather than designing separate accessibility features per brand, I architected a single SDK with three layers: shared interaction logic, brand-specific design tokens, and hardware abstraction. A new brand could adopt the entire accessibility feature set by implementing only the token layer.

04 - Process

How research shaped
every decision

Phase 01 - Discover

Mapping the regulatory and user landscape

I began by auditing the CVAA requirements with our Accessibility Leader to clarify the legal scope. In parallel, our UX Researcher conducted structured interviews with users across the three disability archetypes — specifically asking about their mobile accessibility habits and expectations for in-vehicle systems. Early sessions revealed a critical insight: users didn't want a separate "accessibility mode." They wanted their existing tools to work.

Research insight that changed the design

Every early concept proposed an "Accessibility Mode" that altered the entire UI. User feedback was clear: this felt stigmatizing and disorienting. We pivoted to an independent toggle model within a dedicated Accessibility hub — invisible when not needed, but always present.

Phase 02 -Define

Setting the design principles for safety-critical HMI

Before sketching a single screen, I defined five binding principles with the platform team:

1) No feature should require more than one hand.

(2) All audio output must be audible at 70 dB road noise.

(3) Every interaction must include a visible confirmation step.

(4) Features must be fully operable using rotary input only.

(5) No accessibility feature should change the experience for non-accessibility users.

My contribution at this stage

I owned the translation of research findings into interaction principles. The UX Researcher synthesized user data; I translated those insights into concrete design constraints that engineering and QA could test against.

Phase 03 - Ideate

Exploring and discarding- three approaches

We explored three distinct directions before arriving at the released design. Direction A was a full-overlay "accessibility skin" that replaced the standard UI entirely — rejected because it broke brand consistency across Audi and Porsche.

Direction B used floating persistent controls — rejected by safety engineering because overlays can obscure driving-critical information.

Direction C was the hub-and-toggle model we shipped: self-contained, opt-in, brand-agnostic.

Phase 04 - Validate

Testing with disability community partners

We ran validation sessions with the Accessibility Leader's disability community partners across both our primary user archetypes. The most significant finding: the continuous narration model in our Screen Reader prototype caused cognitive overload for users in simulated driving scenarios. We iterated to tap-triggered narration — a model borrowed from the "confirm before acting" logic already familiar in automotive contexts. This single change went through three more rounds of testing before final approval.

What I'd do differently

We involved community partners in the Validate phase. They should have been in Define. Their feedback fundamentally changed the Screen Reader interaction model — but we arrived at it mid-build, costing two sprint cycles. Engaging earlier would have been more efficient and respectful of their expertise.

05 - Actual Images of Features

Actual image of Audi A5 2025 - Center infotainment Display - Home screen showing Accessibility Application

Feature 01

Screen Reader

Making every UI element audible on demand, not constantly. Designed for visually impaired users who can drive but can't parse the display in real time. Prioritized in V1 because it addressed the broadest CVAA compliance requirement and leveraged patterns the UX engineering team already understood from WCAG 2.1.

Feature 02

Voice Select

Enabling full UI navigation without touch — for users with limited fine motor control. Labels all interactive elements; the user says the label aloud to activate it. The critical constraint: the vehicle already had a voice assistant with a wake word. Voice Select had to be visually distinct and operationally isolated to avoid command conflicts.