Phase 01 — Discover

Mapping the regulatory and user landscape

I began by auditing the CVAA requirements alongside our Accessibility Leader to understand the exact 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 what they expected from 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 inside 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 survive 70dB road noise. (3) Every interaction must have a visible confirmation step. (4) Features must be fully operable via rotary input only. (5) No accessibility feature changes the experience of 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.