Don’t forget the technician! Best practices for building maintenance & diagnostic solutions

In 2020, technology has become an integral part of everyday life. Technological progress is developing so rapidly that it’s easy to take it for granted. We get used to things like device computing power, beautiful high-resolution displays and fast internet connectivity. In fact, any digital product targeting consumers must have a rich, beautiful user interface, offer a flawless user experience and be accessible through any digital channel. This user-generated demand for a superior user experience is what drives product development, and the ability to keep up with, or even surpass user expectations, is what counts as a competitive advantage in today’s digitized world. 

Now imagine that the next time you bring your car to the dealer for maintenance, you actually pay attention to the software the technician uses to perform diagnostics. If you do, a few questions will surely come to mind. Why does vehicle maintenance software look so different than the apps I use on a daily basis? Why does the UI seem so outdated? With all the money OEMs have at their disposal, why can’t they keep up with the technological times? 

Here, at Star, we’ve been lucky enough to deep dive into the daily challenges facing those working with vehicle diagnostics and maintenance at OEM production facilities. We work with customers in the automotive industry to develop tools that make life easier for technicians. This work has helped us to reveal the answers to these questions and find salient points for building maintenance & diagnostic solutions for the automotive industry.

This article highlights a few areas we’ve found to be important when developing maintenance and diagnostics software for technicians. You will find here both technical and product-oriented points. While some comments might seem like “common sense” or trivial, in our experience, they are often overlooked or neglected. Let’s get started.

We’ve put together a best-practice document with both practical and technical tips and advice for addressing each of these areas.

Connectivity

Believe it or not, there are still some places on earth with unstable or slow internet connectivity, particularly garages and factories. The nature of technicians’ work often involves moving in and around the vehicle to perform diagnostics. They don’t always have the possibility to sit at a desk and access the Internet. This point is also relevant if the product you’re building is to be used across multiple countries or even multiple continents.

Consider these factors when making decisions about application design and behavior. Specifically:

• Create offline requirements for each feature that has to deal with diagnostics.
• Minimize the response size between the client and server.
• Plan a long-term, client-side storage mechanism to re-send the data once the hardware’s connectivity is restored.
• Implement smart caching on the client side to avoid excessive data exchange between client and server.
• Minimize response times by caching on the server side.

Hardware

The best-case scenario would be that technicians have a smartphone with powerful features in their pocket to work with; however, the reality is that many will be working on a laptop nowhere near as powerful as the average smartphone. 

The laptop’s software, while legacy, is needed for the diagnostics to work. And the challenges could be varied: the software might only run on a specific hardware setup, or the software installation instructions could have been lost or the dealers haven’t upgraded the hardware, or a host of other reasons. 

So at the end of the day, you have to be ready to see your product run on something that is not the latest MacBook Pro or Dell XPS13.

Software

Did you ever imagine that Internet Explorer 11 could top the list of target browsers for a modern web application? Probably not, but you should. 97% of your user base could still be using it for one single reason: that’s what they’ve been using for decades and if it’s not broke…

Is the solution simply asking dealerships or factories to upgrade their software? Or telling them to install modern browsers on every laptop, switch to OS X, install the required plugins or even purchase new software? You could do that, but would every single user of your 100k audience do it? And is every person in your audience tech-savvy and informed enough to know that IE11 is completely outdated? The answer is clear. So what do you do now?

Legacy user experience

Imagine you are creating a new version of a diagnostic application. You are starting from scratch without any constraints and designing it in line with the latest design trends. This would seem like the perfect opportunity to go all-in and completely redefine the user experience.

But there is one pitfall. You already have an audience of thousands of people who are used to doing things in a certain way. Some of them might have been doing their work for decades. Completely changing this traditional application means changing their usual behavior, which will be uncomfortable and embarrassing for some users. And for the business, it means a huge investment in training and change communication, and the possibility of a decrease in productivity (and therefore revenue) if users can’t figure out how to use the new system fast enough.

Operational environment

Expect that your application will be used in a pretty rough environment as compared to an ordinary consumer app. Some activities will be performed in a dark garage, others under bright sunlight. The screen and keyboard could be dirty with dust or oil; the technician could wear gloves or protective goggles. And in all of these situations, technicians must be able to do their job, fast and reliably.

To provide technicians with the best work environment, think about the following:

• Test the UI/UX in a real environment prior to rolling out a new feature.
• Make pragmatic choices when it comes to balancing the cleanliness of a UI with the need for usability and accessibility.
• Take into account the accessibility features your application might need.

Go-live specifics

Always remember that maintenance and diagnostics solutions are usually business-critical. Every minute of downtime means lost revenue for the dealer or factory, and dissatisfied customers. 

Moreover, such applications are usually used in different time zones and have to be up 24/7. Maintenance windows must be minimized or completely absent. And when downtime does happen (even Google and GitHub software occasionally goes down), your MTTR (mean-time-to-repair) should be kept to a minimum, since unavailability basically means delays in production or service operations. Download our recommendations for minimizing downtime.

The voice of the user

While real-world testing is an essential and established part of application development, in our experience OEMs/Tier 1s tend to ignore this step. The user base is solid and often has no alternatives in terms of products they can use to perform the job, so their voice is often ignored. This often leads to numerous iterations of the same feature and dissatisfied users. At the end of the day, such a reactive behavior is also very expensive, as it takes several cycles before a feature starts creating business value.

To understand your user clearly, you should take these steps:

• Prepare clickable prototypes for early-stage validation with end-users.
• Observe target audience behavior in their operational environment by sending the design and product personnel into the “field”.

Application testing

Real-world usage of diagnostics and vehicle maintenance software usually involves thousands of vehicle configurations, numerous versions of middleware, different hardware, endless possibilities on what data the vehicle would return and so on. So answering the “How do we test this?” question is not trivial. 

Setting up the test strategy beforehand is crucial, so consider:

• Creating some type of vehicle emulator. We are now successfully testing 95% of functionality with emulators developed in-house on early project phases.
• Mocking external dependencies where applicable. For example, we frequently rely on fake-s3 or fake-sqs servers when running tests in continuous delivery pipelines.
• Running the User Acceptance Testing process on real vehicles as a final quality gate.

Troubleshooting

Unfortunately, you won’t be getting detailed defect reports from users. They don’t have the time, they’re not incentivized and they lack the input knowledge you require for troubleshooting. Given that the test conditions are so diverse (see the Application testing section), you’ll be running blindfolded unless you can re-create the sequence of steps that caused the issue, as well as the configuration that the user was working with.

The same applies to cases where data gets sent from your system to a 3rd party. Imagine a situation where a 3rd party claims they haven’t received the data that was supposed to be sent out by your application. Unless you have a way to audit the events, you are unlikely to be able to figure out whether it’s your application that hasn’t sent the data out, or the 3rd party app that hasn’t stored it properly. Here’s how we make the troubleshooting process easier.

Integration with existing tools & services

There is a 99.9% chance that your product will have to integrate with a bunch of legacy software that will become an external dependency for you for many years to come. Сloud services supplying the data, desktop middleware, 3rd party SDKs and libraries, legacy dataset, single sign-on solution – the list is endless. Integrations are always risky, time-consuming and heavy on stakeholder management. No one likes them, but there is no way around it. The best way to deal with them is to be proactive.

Better to be prepared and proactive, so you should consider:

• Use a single API documentation format across the involved parties. For example, we’ve successfully used Swagger on multiple projects for aligning web APIs between the parties.
• Factor in the time for mock creation of features that rely on integrations. It’s ok to be pessimistic with estimates in this case.
• Set up automated monitoring of 3rd party applications. Given that your application features are dependent on them, it’s the only way to proactively inform your users that something isn’t functioning at the moment.

Error handling

Delivering an error-free application is an integral part of any modern software product. But in diagnostics and maintenance applications “error proofing” is taken to a whole new level. There are many moving pieces involved: the vehicle, the cable, the hardware used by the technician, the garage’s network setup, the 3rd party software your application integrates with, etc. There are just so many places where things can go wrong. Moreover, the impact of this mistake could even be malfunctioning vehicle parts. Pretty pricey, right? All of this illustrates the importance of considering how you will handle errors (and how to avoid them) before you launch the application.

Wrap up

So, to return to the questions posed at the outset, we’re not quite at the point where diagnostics and vehicle maintenance software can be just as visually attractive as most applications on your smartphone. However, with the right approach and by keeping the end user’s context and circumstances in mind, you can create applications that greatly improve the entire diagnostic and maintenance workflow. And at the end of the day, it’s not about how much new technology is included or how attractive the user interface is; it’s about delivering software that’s efficient and reliable. It’s about creating a product that solves a real problem and makes the lives of thousands of people easier every single day.

Now we’ve gone through 11 areas you need to consider when building diagnostics and maintenance software for technicians. However, you may be asking, “Okay, now I know what to look out for. But how do I deal with it?”

We’ve put together a best-practice document with both practical and technical tips and advice for addressing each of these areas.