Select Page

Auto Shopping and Financing

Wells Fargo Auto Shopping
The original brief was an iOS native app. User research changed the brief.

 

Wells Fargo’s Innovation Group wanted to expand beyond auto financing into auto research and shopping — giving users a reason to start their car-buying journey with Wells Fargo, not just finish it there. A prior project had scoped this as a native mobile application. After reviewing that research and conducting stakeholder interviews, I recommended a platform change. Users didn’t want to be limited to mobile. The product became a location-based responsive web application instead.

 

As the sole designer on this project, I took it from research review through user testing and final delivery over four months.

Project Details

Client    Wells Fargo Innovation Group
Timeline    4 months
My Role    Lead/Sole UX designer
My Contribution    Platform recommendation, user journey mapping, wireframes across all screen sizes, iterative stakeholder reviews, coordinated external user testing, and final delivery to the production team.

User Research
Discovery: research that changed the brief
 
This project built on a prior initiative that had been scoped as an iOS native app. Before designing anything, I reviewed the existing research, interviewed stakeholders, and assessed the prior project’s assets.
 
The key finding from user research: people don’t want to shop for a car exclusively on a mobile device. They also don’t want a feature-heavy experience that gets in the way of a straightforward task. Both findings pointed away from a native app and toward a responsive web experience that could meet users wherever they were in the process.

 

User Journey

With the platform direction established, I mapped the user journey from intent (wanting a new car) to completion (owning one). Three personas had been defined in the prior project; I applied them here to structure the journey steps and identify what the product needed to support at each stage.

 
The journey became the through-line for the rest of the design — every screen in every wireframe had to map to a step in it. Anything that didn’t map to the journey was a candidate for removal.
User Journey
Whiteboarding Option A

Whiteboarding Option B
Exploring directions
 

A whiteboarding session produced two candidate design directions, both mapped against the user journey:

  • A decision tree model — guiding users through a sequential flow step by step
  • A three-panel layout — putting all major features on one screen and letting users engage in any order
Both directions had logic to them. The decision tree kept users oriented in the process. The three-panel layout gave power users faster access to the tools they needed. Both were developed into wireframes for stakeholder evaluation.

 

Low-fidelity wireframes
 
Both directions were built out as low-fidelity wireframes with real content plugged in — enough to evaluate the flow, not just the concept. The wireframes were linked in InVision for a clickthrough prototype, which made stakeholder reviews and flow critiques significantly more productive than reviewing static screens.
Low Fidelity Option A

Low Fidelity Option B
Refinement
 
Stakeholder reviews narrowed the direction to one. From there, I iterated on the chosen direction — building it out at higher fidelity, resolving the small-screen behavior, and defining the content of the left information panel used for browsing models, vehicles, and dealerships.
Low Fidelity Final Option

Small Screen Flow
High Fidelity Wireframe
Info Panel
User testing
 
We partnered with Answer Labs, a professional user testing facility in San Francisco, for a full day of moderated testing. The session had two goals: validate the design well enough to justify moving to production, and surface specific usability issues to fix before handoff.
Two areas were the primary focus:

The estimator panel — a loan calculator that also functioned as a search filter. Did users understand how to use it? Did they understand that it was about the loan, not about a specific vehicle — and that adjusting it would filter their search results?

The navigation flow — could users move forward and backward through the product comfortably?

Because the estimator used sliders as a core interaction, a clickthrough prototype wasn’t sufficient. I brought in developer resources to build a working functional HTML prototype so the sliders could be tested as they would actually behave in production.
User Testing
User Testing
Testing results
 
The testing validated the core concept and surfaced specific, fixable issues.
 
What worked:
  • Users understood the Dealer Services concept and responded positively to it
  • All but one participant moved through the initial screens without difficulty
  • All participants understood the estimator and responded positively to it
What needed work:
  • A few users didn’t immediately see how the estimator filtered their search results
  • Some were confused by the visual similarity between the model overview and vehicle detail views
  • Most users could move forward through the flow, but several struggled to navigate backward
  • The term “pre-qualifying” confused some participants, and a few were uncertain what to do after submitting their application
Clear findings, actionable direction.

Final iteration and delivery

With testing results in hand, I made targeted changes before handoff:
  • Differentiated the first two intro screens, which had looked too similar
  • Reduced each screen to one primary action button, positioned on the screen where the user needed to act next
  • Added a back button to every screen
  • Visually differentiated the model overview and vehicle detail cards
  • Added a header to each center panel to orient users to what they were looking at
  • Cleaned up additional screens that had been explored but not tested
  • Created a complete high-fidelity flow for the small-screen version
The final designs and specs were handed to the production team, who built out the product over the following three months.
Final delivery screens

Small Screen Flow

Conclusion

The platform decision made early in this project — switching from native iOS to responsive web based on user research — defined everything that followed. A native app would have delivered the wrong product to the wrong context. The responsive web application reached users at every stage of the car-buying process, on whatever device they were using.
 
The product shipped. Three months of production work followed the design handoff, integrating the UI with the relevant APIs.