myAudi

Overview

myAudi is Audi's digital customer portal, available as a website and mobile app. For eight years, I worked as a UX designer on this product as part of a team at a digital agency contracted by Audi.

My role evolved over that time. I started in the myAudi app team, designing features for the native iOS experience. Later, I moved into a creation-focused team that worked on concepts for both app and web. For the majority of my time, I worked in a cross-functional team, alongside developers, UI designers, and copywriters, focused on the myAudi web portal.

Across these roles, I designed a wide range of features: service appointment booking, EV charging experiences, sat-nav update management, and more. I was involved in the full design process: from concept and user research through wireframing, prototyping, and usability testing to UI design handoff.

This case study gives an overview of how I worked within this environment, with a closer look at the service appointment booking redesign as a concrete example.

Screenshot from the current live version of myAudi.
The visual design has evolved since my involvement, but the UX patterns and flow structure I designed remain in place.

How I Worked

Feature requests typically came from Audi's business experts, domain specialists who combined their own expertise with customer feedback and insights from Audi service partners. Our team would then take these inputs and shape them into a user-centered design.

My responsibilities included:

• Creating UX concepts and wireframes based on business requirements and research inputs
• Presenting designs to Audi stakeholders and iterating based on their feedback
• Planning and co-conducting moderated usability tests with our UX research team
• Analyzing test results and translating findings into design improvements
• Working closely with developers to navigate technical constraints and ensure feasibility

The team operated within Audi's SAFe (Scaled Agile Framework) environment, which meant coordinating across multiple agencies. Some worked on app implementation, others on service partner backend systems. Design decisions were always shaped by this broader context.

Deep Dive: Service Appointment Booking

One of the most impactful projects I worked on was the redesign of the service booking flow: the process through which customers schedule a service appointment at their preferred Audi service partner.

The Challenge

The existing booking flow was a single long page that presented all steps at once and had grown increasingly complex over time.

Beyond the UX issues, there were significant technical constraints: the flow needed to work across multiple service partner backend systems, each with different capabilities and data structures. It also had to function as a responsive web application rendered inside the iOS and Android apps via web views, so every design decision had to work across screen sizes.

Research & Discovery

The redesign was informed by multiple sources:

• Analytics review: Data from the existing flow revealed where users abandoned the process and which steps caused the most confusion.
• Customer and service partner feedback: Qualitative context that explained the patterns behind the quantitative drop-off data.
• User interviews: Our dedicated UX research team conducted interviews with car owners to understand their expectations around service booking. I participated in some of these sessions directly.
• Competitor analysis: We studied how other automotive brands and general service-booking platforms handled similar flows.

What became clear was that the old flow asked for too much information too early. Users were confronted with detailed choices before they had oriented themselves, leading to decision fatigue and abandonment.

The booking flow in the live version of myAudi today, still following the progressive disclosure approach from the redesign.

Design Approach

Based on these findings, I explored several approaches and settled on a restructured flow built around:

• Progressive disclosure: Instead of showing all options upfront, the flow reveals complexity gradually, starting with the most important choice (service partner and service type) and deferring secondary details to later steps.
• Reduced cognitive load: Each step focuses on one decision at a time, with clear progress indication.
• Graceful fallbacks: Since different partner backends offered different data, I worked closely with developers to ensure the experience remained coherent even when certain capabilities were unavailable.

I created wireframes and interactive prototypes that went through multiple rounds of stakeholder review with Audi's business experts. The cross-functional nature of our team meant feasibility discussions happened early and continuously.

Testing & Iteration

Together with our UX research colleagues, I planned and conducted moderated usability tests with representative users:

• Defined test scenarios based on the most common real-world booking tasks
• Ran moderated sessions where participants walked through the prototype
• Analyzed results to identify remaining friction points
• Iterated on the design based on concrete user behavior, not assumptions

The tests confirmed that the progressive approach significantly reduced the feeling of being overwhelmed. They also revealed smaller issues — unclear labeling, unexpected step ordering — that we addressed in subsequent iterations.

Outcome

The redesigned booking flow launched successfully. While I cannot share specific metrics due to confidentiality, service inquiry rates improved and the simplified flow addressed the complexity that had been a recurring source of feedback. Audi stakeholders considered the project a success, and the approach influenced how subsequent features were designed.

Reflection

Eight years on a single product taught me that in enterprise UX, the design challenge is often less about the interface itself and more about navigating constraints: technical limitations, organizational complexity, and competing stakeholder priorities. The most valuable skill wasn't creating wireframes; it was translating between user needs, business requirements, and technical realities to find solutions that worked for everyone.