Move the slider above up & down to see the before [top] and after [bottom] of the redesign.

Main Vehicle View — All details for an individual vehicle are accessible in the above user interface.

I start with questions.

Who will be using the software? What do they need to achieve? What elements must remain manual, which can be digital or automatized? What does the ideal system look like in their minds? 

The primary users were the internal team of employees and administrators who run the auction weekly.

With nearly a dozen different departments handling various aspects of the auction process—bidder check-in, financing services, dealer closeout, arbitration, and titles—the overlapping layers of dependencies were challenging to sort out.

Auction preparation takes place each week; afterward, many “post-auction” processing tasks need completion before moving to the following week.

Additionally, the client had an in-house loan and lending operation they wanted to manage within the software. There was talk of extending some functionality, allowing customers to register and obtain auction numbers for the upcoming auction. It would free up needed human resources.

Screen captures of different interfaces required for the project.

Roles + Responsibilities

I was one of approximately a dozen (12) team members, with team size fluctuating according to the depth or urgency of client needs as well as the complexity of functionality in development at any given time.

Once my design colleague kicked off the project with the client, our two-person design team got cracking with the increased workload. Later, I became the sole designer working on the project until Covid-19, and the client put the project on hold.

Dealer Close Out user interface to close a dealer's account after an auction.

Title Information user interface tracks the vehicles tied to the titles.

Scope + Constraints

This project reinforced the essential nature of candid transparency when scoping a project and kicking it off.

To serve a client well and to feel well-served, there can be no hesitancy to expose the "dirty laundry" of just how messy a current software is. Sharing “worst practices” is a way of getting to best practices!

I had no insight into some software sections or tools before designing them. I feel part of this was based on the clients' hesitancy to expose the "dirty laundry" and trying to explain bad habits and practices.

Compromised exposure and insight made laying the groundwork for those later sections more challenging. I was more than a year into the overall design, and I still had not seen some areas of the software or business rules or met the people who would be using that software daily to complete their work—it was highly problematic.

Process + Deliverables

As part of our standard discovery process, we interviewed vital stakeholders during online video calls to discuss progress, current user needs, and what components of the process were analog versus digital.

Next, we wireframed screens to walk a user through the steps required to perform functions. For those currently analog only, we had to create entire workflows from the ground up.

We completed one section, or set of functionalities, at a time: unpack, redesign, propose, revise, approve and implement.

The users of a 30-year-old legacy system have their ways of doing things. Open-mindedness to change was not significant.

I was highly aware of the end-users and their concerns. I would ask them what their most "pie-in-the-sky" feature request would be regardless of money or other resources. I am always looking for ways to incorporate their functionality into the software and design.

There's no doubt there would be pushback on certain sections of workflows; it's what allows us to get to the best solutions. I'd make revisions, and we would meet until everyone was satisfied with a particular section.

Once the client signed off the designs, I handed specifications to the front-end developers. This process repeated for two years, where I worked on multiple software sections. You'll see many screens captured here in this case study, but it is not all of them.

SAFS Landing Page — where SAFS team members administer loans for dealers

SAFS Loan Administration user interface showing an 'over limit' status for a dealer.

Outcomes +
Lessons Learned

This project was left uncompleted due to COVID-19; soon after the outbreak, the client put the brakes on everything and never restarted it.

They took all our development (roughly 85% of the software) and finished the project in-house. The sections we finished and delivered were MVPs (minimally viable products) in and of themselves.

Despite this, I honed valuable skills in this work: I learned to work with internal and sizable client teams. I learned how to engage with users and listen to understand their wishes and fears as we advance and learn techniques to help them lessen their anxiety.

Upon reflection, I wish we had done a better job handing off a comprehensive design system to the client.

Internally, we had the system working to consistently present information between areas of the software, not to mention all the different data requirements. Still, we did not pass this along to the clients because the project stopped abruptly due to COVID-19.

The client never requested it, and there was no budget to complete it.

Variations of a search result drop-down

SOCIALS

LOCATION

Ojai, CA 93023

PHONE

+01 (805) 225-7061‬

OTHER LINKS

Cookie & Privacy Policy

Colophon

SEND A QUICK NOTE

MISCELLANEOUS

Copyright ©MCMXCII–MMXXII — Bert Mahoney.
All rights reserved unless otherwise noted about specific content.