Audi Payment Estimator



In June 2020, the world was starting to realize that COVID was here to stay, meaning the number of customers visiting car dealerships was rapidly dwindling. As a result, Audi needed to rethink their e-commerce experience ASAP in order to continue selling their luxury vehicles.

As a UX intern at a creative agency called BIMM, with Audi as my major client, my job was to support this transition, and I did so through a complete redesign of the vehicle payment estimator feature in a span of 3 months.



Rethinking an entire e-commerce experience was a broad challenge that needed to be narrowed down. I began by exploring Audi’s existing online purchase process.

My major finding? The vehicle purchase funnel was fragmented.

The customer:

  1. Visits the Audi website
  2. Selects a base vehicle
  3. Customizes the vehicle
  4. Goes to estimate the payment
  5. Is redirected to an external payment estimator (PE) website, where they must re-enter all their customizations

User Pain Points

    Customization was done on the dealer website, and payment estimation was on a separate website, with no data transfer between the two
    Customer had to re-enter all the customizations from the configurator into the payment estimator
    Could not see how pricing would be impacted while making customizations to the base vehicle

Business Pain Points

    A poor user experience can cause frustration and lower sales potential
    A lead may not even be generated if the customer does not fill out the external PE form because none of the data from the customizer is transferred to the external PE


I demonstrated the pain points to the client with a walkthrough presentation of the current purchase process, identifying the gaps and potential consequences as I went.

Ultimately, we decided it was necessary to do away with the externalized PE, and integrate it within the configurator, enabling customers to simultaneously build and price their vehicle.


Previously, requirements were composed by the client independently, inputted into Word documents, and posted to Jira. We would then have multiple meetings together to review and revise these requirements, sending updated docs back and forth.

This process was inefficient, so I decided to try something new. To gather requirements for the integrated payment estimator, I popped open a Figma file, dropped in a mobile frame, and worked with the client to roughly map out the requirements in context of an actual interface.

Figma > Word Docs

Bidding a final FINAL goodbye to static Word documents.

  1. Figma documents are live and collaborative. That meant all information and updates were contained in a single dynamic document.
  2. With just a mobile frame to work with rather than an infinite length Word doc, we cut down on the verbosity. Only key words were included.
  3. Anyone can edit a Figma document in real-time. For example, during our meeting, we could all watch as the PM played with the layout to improve the flow.


The PE CTA is what customers select to access the payment details about the Audi that they customized in the configurator.

The Old PE CTA

In the old configurator summary page, there is an “Estimate payments” CTA. Selecting the CTA leads to the external PE website. There is no payment estimation information in this CTA, and none of the vehicle customizations carry over to the external PE form that the CTA leads to.

When building their vehicle, the user has no idea what it’s ultimately going to cost.

The New PE CTA (Mobile)

With minimal real estate consumption, I designed a new toggle bar-CTA that shows the available payment methods, and their corresponding price estimates. The price estimates update dynamically as the user customizes their car, providing the customer with relevant information in context.

The user must be aware that the price estimates are location-based for legal purposes, so I included a location disclaimer that disappears on scroll. The toggle bar gets top-pinned such that the user can consistently view price updates as they customize their car.

The payment term, interest rate, and tax information needed to be shown to indicate how the cost estimate had been derived. To avoid consuming more vertical real estate,  I made each payment method in the toggle bar individually expandable to expose additional cost information. A back button returns the user to all the methods.

The New PE CTA (Desktop)

After finalizing the mobile CTA, I went on to design the toggle bar for the desktop breakpoint. Below are some iterations of the desktop CTA and rationale for each.

Iteration 1

I used the additional screen width to move up the location disclaimer and minimize vertical real estate consumption. However, the distinction between the payment methods and the disclaimer was insufficient.

Iteration 2

I pulled the location disclaimer down again for better distinguishability. However, the information contained in each tab is too close to the edge, making it hard to identify where one tab ends and the next begins.

Iteration 3

I added more negative space within each toggle for better separation between the payment methods. I also further distinguished the location disclaimer with a subtle but still accessible background colour.

In context:


The PE form is where customers can select a payment plan (lease, finance, or cash) and make adjustments to it.

Old Form

The old PE form was situated on an external website. The user would first have to reenter all their vehicle customizations on this website in order to then access the form pictured below.

New Form

The new PE form was integrated directly into the configurator as a fullscreen modal. The modal focused the user’s attention on payment estimation without removing them from the context of the configurator.

Having the payment estimator form within the Audi website meant it could inherit all the vehicle customizations, eliminating information re-entry, generating more leads, and making it easier to finalize the purchase.

Comparing the Old vs. New

Let’s do a direct comparison the old PE form and the new one to highlight some key visual and experience-based differences.

Disclaimer with Information Hierarchy

The old location disclaimer was overwhelming in all-bold, capitalized text.

The new disclaimer has the same content, but uses visual hierarchy to prioritize important information.

Ease of Comparison

Previously, only the selected payment method was highlighted using a full-width bar.

In the redesigned PE form, I used a toggle bar such that the customer could easily compare payment methods while filling out the form.

Reduced Input Effort

The old dropdown selectors required tap and select actions.

Dropdowns were replaced with toggles which only require a select action.

Larger Hit Areas

Previously, the hit areas for toggles were too small.

Hit areas were enlarged to 44x44px for accessibility, as recommended by WCAG.

Optional Trade-in Field

Even if the customer didn’t have a trade-in vehicle, they had to enter $0 to proceed.

Now, the trade-in input field has been made optional and hidden in a switch to avoid consuming real estate unless the customer indicates that they have a trade-in vehicle.

Clearer CTA

It was previously unclear what the “more details” CTA was referring to.

The copy has been updated for clarity, and the CTA has been moved to the top to provide details about the selected payment method before the customer fills out all the form details.

Logical Price Breakdown

Previously, the price breakdown was presented as a cluster of information at the top of the form. When the user scrolled down and made changes to their payment plan in the PE form, they’d have to scroll back up to see the impact on the price.

In the redesign, there is more breathability and better visual flow in the price breakdown through the use of negative space and horizontal rules. The section is also clearly distinguishable from the rest of the PE form thanks to a different background colour, and it has been placed at the bottom of the form, which is better aligned with how receipts and other financial documents are typically formatted, matching customers’ mental models.

Nothing if not responsive...

Designing for mobile first enabled me to create a PE form that was lean, clean, and effectively prioritized information. Once it was established, I moved on to designing the tablet layout, leveraging the additional space to create more breathing room through negative space, and facilitate even better flow.

I designed for a 12.9” iPad Pro rather than a larger desktop screen because this large tablet falls somewhere between a standard tablet and a desktop, meaning it can easily be scaled slightly up or down across these devices.


Prior to handing off the wireframes to our UI designer and developers, I created an information framework with my manager to communicate the basic details about the design. The framework included a title, description, state, breakpoint, and interaction cards which outlined how the design should function, as well as any variations (see Card 2).



    Users could estimate their payments with the existing and redesigned PE via a structured usability test to gather qualitative data about their experience.

    Further quantitative data could then be gathered by collecting users’ responses to the ten standardized System Usability Scale (SUS) questions, which could be adapted to this specific scenario.

    Audi could collect data on user dropoff rates for the PE form in its existing state vs the new state. This would validate the redesign from a business perspective by measuring whether it was resulting in more leads, and eventually, more sales.


As a student who had only worked on intern projects thus far, my initial thought was holy heck (pardon my French), they’re letting me work on a real product. My second thought was, what if this becomes the golden example of what not to do for all future interns?

This was the first major UX project I spearheaded, and I was given a lot of freedom to make decisions. However, with great power comes great responsibility, which meant I would suffer the consequences of any poor decisions.

Citing “gut instinct” as my justification would no longer fly - instead, I learned to gather and rely on data derived from critiques with senior designers, competitive assessments, usability principles, and lots of iteration. If I were to take another stab at this project, I would conduct user research and validation along the way to ensure the design was meeting business and user needs, and to be able to advocate for the user in client meetings using actual feedback from the users.

Other Projects