This project was for a company that specialized in software for car dealerships. With this Dealer Management System (DMS), dealers can to keep track of their inventory, sales, paperwork, and more. Despite the software offering extensive capability, one of the draw backs was that it is not a SaaS based system. It must be installed locally on a computer, and thus is only useful when the user is physically inside the dealership and in front of their computer. If they are a salesmen out on the lot, they have to rely on printed reports for information such as available inventory, prices, and additional paperwork if they want to know specifics about the vehicles they have on the lot. This limitation was detrimental to the salesman’s and the customer’s experience, and was having a negative impact on dealerships overall. These rumblings of these concerns were growing throughout the company and the opportunity was taken to start preliminary work on gathering data to help secure stakeholder buy-in and kickstart the project.
So in short, we had to:
· Come up a tool for dealers to access their inventory remotely
· Make it responsive and intuitive for the target audience
· Find out other features this tool could offer the user
· Communicate its value to stakeholders
This was a big undertaking for a company that had no UX team or processes, and one look at the base program made this abundantly clear.
While simply asking users if they want something is not always the most productive course of action (as they will often say “sure!”), this did help us ask follow-up questions and gain further insights in a public forum setting. We framed it as a “Frazer Mobile App” and did not list any features it would include. This quickly became the most popular request on the site with users saying it was a severe need for their daily operations. With these data in hand, we were able to gain approval from the primary stakeholder, the owner of the company, and proceed with our efforts.
We created a report based on customer feedback and competitive analysis with other desktop and mobile applications in the industry, but we did not just stop there. We also conducted competitive analysis of other widely used phone apps and websites that users that matched our personas might use. We were able to determine what apps this may be by surveying our customer base. We presented management with a design according to their vision, and one that more closely aligned modern applications. To our (happy) surprise we were given permission to proceed with a design free of constraints of the current look of the program.
The design went through many iterations. We moved our prototyping to Axure RP so we could do more interactive usability testing on the prototypes. This usability testing allowed us to refine the design and test various looks, navigation methods, and sitemaps within the app. We conducted usability testing with our customer service employees on site, as well as remotely with customers who utilize our software. This helped get us to our final design.
The months of research, design, and testing produced wonderful results. We decided to streamline the entire process and focus on the main point of the application - Inventory. This made the workflow more natural while reducing the sitemap and requiring less screens for the dealers to navigate to get to the data they need. We also decided to break from the color scheme of the software entirely and merely utilize blacks/greys/whites in the application for a modern yet minimalist look. The application was also renamed from “Frazer Mobile App” to “Frazer Sidekick” as the former name could be misleading in the applications capabilities.
The launch of the Frazer Sidekick app helped serve to keep the platform competitive within the industry. During the planning stages the idea that the application could be sold as an add-on had been tossed around, however it was decided that the extra tool would be included with the normal subscription as just another great reason for a dealer to use our software overall.
Vehicle Inventory App
Site Mapping
Stakeholder Interviews
Contextual Interviews
Competitive Analysis
Surveys
Usertesting.com
Optimal Workshop
Survey Monkey
Abstract
Sketch
Invision
Axure RP
Design System
Tools:
Wireframing
Prototyping
Design
Usability Testing
Skills:
The Problem
The Process
From our customer service logs we had heard requests from users to have some way to access their inventory while out on the lot. To make sure that this was a feature that our dealers actually desired we first posed the question on our user feedback site, uservoice. Uservoice not only allows users to post their ideas, but also reply to other user’s posts with their thoughts as well as upvote ideas that they also support.
We began conducting research on what our dealers expected a mobile Frazer application to be capable of. We conducted an UX audit of the features our base program offered and documented which ones may be optimal for a remote experience. User data was gathered through user posts on our Uservoice forum, scanning customer call logs in our in-house CMS, as well as conducting contextual interviews via email and telephone calls.
We developed user personas, as well as established the basic features that our mobile app should have. Working with our developers, we found the customer’s desires lined up with our expectations and our capabilities. We these details decided we could proceed with the project.
From here we developed user journeys and low-fidelity wireframes in proto.io. With the overall workflow and look approved by developers and stakeholders, we produced some high-fidelity wireframes to highlight an issue we believed may be present. The issue was management wanted us to produce a tool that maintained the look and feel of the software itself.
The software, while functional, exhibited an extremely dated look and had some extensive usability issues to match. These at proliferated through the years as usability testing was never conducted, and everything was purely conceptualized and implemented straight by the developers. The company took the stance “our customers will let us know if we got something wrong”. This was an antiquated and ineffective approach, but none the less prevented us from touching the primary software as the owner feared “if we make changes we could lose our loyal customers” and failed to acknowledge what the company could potentially gain with increased user-friendliness and a modern look.
