Test the design in the real environment
Providing the best OEM data that enables the best expriences for B2B and B2C services
ALLDATA provides OEM automotive repair and collision information that is considered the most high quality and complete in the industry. Founded in 1986, the California-based company has more than 115,000 subscribers worldwide who rely on ALLDATA for diagnostics tools, OEM-accurate mechanical and collision repair information, and shop management software.
Jimmy has more than two decades of auto repair expertise under his name. He's been subscribed to ALLDATA's Repair for over 10 years and is thinking about getting other services of the ALLDATA suite too. He's interested in leveraging those new services to manage his shop and his customers. Majority of ALLDATA's products serve business, and the rest are for their customers and the auto repairing communities. So in short, our users include:
Research was an ongoing effort at ALLDATA. We monitored customer service tickets, community activities and their reports; We teamed up with marketing on surveys and outreach groups; we followed a cadence for onsite / field researches and usability tests. Let's take a look at the onsite research I led in the winter of 2015.
Research is definitely a team effort.
The Design team was small. How might we cover ongoing research while continuing to deliver design and support implementation? Well, good planning and teaming with other functional teams, like product, training, and marketing, worked well for us.
Check out the testing scheduleIt was before there was Dovetail, Airtable, or Optimal Workshop's tagging feature. To capture both the quantitative and qualitative essence of the research data, we decided to adopt the research finding matrix, a tool I'd been developing from years ago.
Check out the research finding matrix
To support all current and upcoming product releases and feature blocks. To engage in the tight SaaS development cycles. To explore and execute the best and most viable solutions for the problems at hand.
To understand where we want to be in 5 years, or even further. To develop concepts and pilots based on research and discovery to explore and verify possible solutions, which will impact business decisions, product direction, and strategy in the long run.
The application helps the auto shop generate quotes for the auto parts and services they are going to provide to their customers. We hope it will create a framework that can be scaled in the future when the customer can also access or even utilize Quotes.
Mechanics can be working on multiple vehicles or sharing a computer with others. Making the car info (year, make, model, and engine) clear and prominent reduces errors and assure efficiency, especially during context switch. See the comparison of current and proposed designs.
This is a self service tool for the shop owners or managers to generate and organize everyday shop documents like estimates, repair orders, and invoices. It also allows them to manage the ALLDATA accounts and licenses.
ALLDATA's search is quite robust, for its data structure was based on a powerful and accurate taxonomy. But mechanics weren't satisfied with just that, they wanted a smart and forgivable search that would make their job easier even when their search had a typo; and they wanted search returns to include both "throttle" and "accelerator" when searching either term.
We were aiming to provide a seamless experience for all ALLDATA web apps and native apps. For web apps, we promised a web framework that is fully responsive from smartphones to desktop devices.
Check out the coded prototypeDesigners and engineers were working shoulder to shoulder on different native apps & devices for inspection, diagnosis, estimates, and so on. Building prototypes in mobile early could help us identify issues early.
A seamless experience for the fully responsive web app is easier said than done. Take a look at complex data tables, how could it be rendered gracefully on smaller devices? Research actually suggested avoiding it altogether on small devices. We collected the existing solutions we could find from research and explored more with the engineering team. We minimized them to 2 options. We also looked into how other components, like lists, articles, and cards, could provide the ease of use on devices with different sizes and interactive models.
