CASE STUDY
INTERNET-BASED SOFTWARE APPLICATION
VEHICLE
Auction
software
EXPERIENCE & INTERFACE DESIGN
Move the slider above up & down to see the before [top] and after [bottom] of the redesign.
Name
Auction Software Design
Industry
Automotive, Auctioneering
Type
Software Application
Medium
Internet
Duration
Twenty-Four months, ending 2019
My Role
User Experience & Interface Design
Scope
Discovery, Define Needs and Workflow. Designs UI Screens in support of workflow and User Experience client expectations.
Constraints
Redesign of existing 30+ year old, undocumented, legacy software.
Departments were siloed within the organization.
Company and business processes inside the legacy software are largely undocumented—information is inside people's heads.
Deliverables
Dozens of Screen Designs, working with end users, client developers, and A+L Developers to ensure users' needs are met.
Outcome(s)
COVID-19 arrived, and the client put brakes on the project. Brought all design and development in-house. Unfortunately, I was unable to see the project to completion.
Full text and more samples are available on the desktop version of this case study.
An early hand sketch of the Dealer Check-In user interface.
Move the slider above up & down to see the before [top] and after [bottom] of the redesign.
This client is a leader among many national wholesale automotive auction houses, and their once-weekly auctions run 20 lanes of vehicles simultaneously. Automotive dealers and wholesalers are bidding in person and online bidders, as cars move through each auction lane at an average of one per minute.
This project goal was to replace 30-year-old, completely overwhelmed, and undocumented legacy software with a modern Internet-based software application.
The legacy software was incapable of managing the entire auction process. People still completed some procedures by hand that the software could automate, such as vehicle titles and various DMV paperwork. Redundancies and inefficiency everywhere you looked.
Also, some “company knowledge” was not codified or documented; instead, it’s living inside people’s heads—for example, rules regarding how customers are charged based on specific conditions.
The current software had reached its limits, and people knew it was time for a serious upgrade.
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.
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.
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.
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.
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.
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
Click on any image to see it larger, and in slideshow format
Copyright ©MCMXCII–MMXXII — Bert Mahoney.
All rights reserved unless otherwise noted about specific content.
Copyright ©MCMXCII–MMXXII — Bert Mahoney.
All rights reserved unless otherwise noted about specific content.