Auto Shopping and Financing

Problem Statement

Create a location based responsive auto shopping application.

Introduction

As the sole designer creating new digital product for Wells Fargo, this was the follow up to an initial request to create a native mobile auto shopping app. It was created to fill the business needs of allowing users to use Wells Fargo as not just a auto financing resource, but also a resource for researching and shopping for new and used vehicles, in hopes it would motivate users to get financing with a Wells Fargo auto loan.

NOTE: Right clicking on an image below and selecting “open image in new tab” will bypass opening the image in the lightbox and allow zooming into full detail.

Project Details

Client Wells Fargo Innovation Group
Timeline 4 months
Contribution Lead/Solo UX designer

Step 1: Interview stakeholders and review assets

This project jumped off of a similar project who’s direction was to create an iOS native app, but after extensive review, user testing, and my recommendations, we were able to switch gears from a native app and actually figure out what the users want, both in a platform for searching for cars, as well as features.

One of the core findings of the user research: Users do not want to be limited to using a mobile device. They also don’t want tons of extra features getting in the way of them accomplishing their task of finding a new car.

Step 2: The User Journey

After all the stakeholders have been interviewed, user research reviewed, it’s time to create a user journey, use case, or basically map out how the user gets from point A (wanting a new car) to point B (owning a new car).

Step 3: Whiteboarding the User Story

Ok, so now that we have a User Journey that maps out the progress of our 3 personas (previously defined in the prior native app project), we have something that we can map out all our steps to. We also have a quick list of features to include in this product. Out of the whiteboarding session, we have two different options that seem to work well for our flow. One is more of a decision tree style, and the other putting all the features first and foremost on one page using 3 different panels.

From here out, all our wireframes should map to a step in this user journey. Anything else is just an extra feature which may not be necessary.

Step 4: Low fidelity wireframes

So we now have two different options. Time to build those out as wireframes and start plugging in some content. Remember, at this point, everything on the wireframes should fit in with a step of our user journey.

We can also link our Sketch file with Invision so that we can create a click through prototype, which is great when showing stakeholders, as well as reviewing the overall flow through the app.

Step 6: Test with users

Ok, time to take this to the users to see what they think of the design. For this, we teamed up with Answer Labs, a testing facility located in San Francisco. The test was two parts. One, for the business unit, can we validate the design enough to justify taking this into production to make this an actual product. And for us, what do we want to find out about the design to improve on it.

The two key areas we wanted to test was the panel on the right, the estimator/calculator. Do users understand how to use it, and do they understand this is about the loan itself and not about a specific vehicle, while at the same time do they understand that it can be used to filter their search results? And the other area we want to test is the flow. Do users understand how to move forward and back through the flow? Well, moment of truth as we sit in a dark room behind a one way mirror and find out during a full day of testing!

And as the sliders are a key thing we wanted to look at, we couldn’t build this out as a click through prototype, so we recruited some dev resources to build this as a working functional html prototype.

Step 7: Test results & conclusion

The testing was very useful. Here we were able to validate a few things we were hoping would work for users, but also learned some other things we did not know.

• Users understood the purpose of the Dealer Services concept and had a positive response to it.
• All but one participant easily navigated through the initial screens to begin the process.
• All understood the Estimator and had a positive reaction to it, but a few did not immediately see how it filtered their results.
• Some were confused and didn’t understand the difference between seeing a model overview and vehicle details.
• All could move forward through the flow, but a few struggled to move back.
• Some were confused by the term pre-qualifying, and were not sure what the next steps after submitting the application should be.

Step 8: Final iteration and delivery

With the test results in hand, it was time to make some final tweeks to the design and then turn it over to the production team who would spend the next 3 months building it out and integrating the UI with the different APIs.

A couple of key design changes based on the testing:

• The intro screens were cleaned up, so that the first two pages didn’t look so similar.
• Each screen now only has one primary button, this button is on the screen that the user is expected to interact with next to move forward.
• A back button was added to each of the screens to allow for easier backwards navigation.
• The model overview and vehicle details cards were cleaned up so that they looked visually different from each other.
• A header was added to each center panel so it was clear what the user was looking at.
• Additional screens that had been explored but not tested were cleaned up to be handed to production.
• A high fidelity flow showing the small screen version was created.