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 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 the 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 applications for the automotive industry.

This article highlights a few areas we’ve found to be important when building diagnostic and maintenance applications 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.


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.


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. 

Here’s what this means for your application development:

  • Technicians’ screens might not be retina screens. They can be low-contrast and even damaged. So a beautiful UI with 30 shades of grey might look good on the mockups, but would be a nightmare in real life.
  • The mouse on the laptop could be a tad less precise than an Apple trackpad. Going for a more pragmatic, but less fancy, UI might be the better option.
  • Compute-intensive features on a client-side might work a lot slower in real life as compared to your development environment.


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?

When it comes to software, you should consider these things:

  • Never assume that support for outdated browsers is out of the question. Research your audience’s setup before starting development.
  • Carefully think when choosing the client-side SDKs and libraries. Some of them might not work in outdated browsers.
  • Think of the required test setup. For example, for legacy Windows-based setups we’ve successfully used a combination of actual hardware and free virtual machines provided by Microsoft that run on VirtualBox. Of course, setup will vary based on your target platforms.

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.

To avoid this painful process, and keep both your customers and end-users in their comfort zone, we recommend the following approach:

  • Go modern, but be mindful of your audience’s legacy behavior patterns.
  • Prepare to invest time in training and creating training materials. Users should be able to easily access these from inside your application at any given time.
  • Prepare user communication channels beforehand. Your users should have a way to report suggestions for UX improvement and quickly get feedback.

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 diagnostics and maintenance applications 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 timezones 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. 

Suggestions to keep in mind:

  • Implement blue-green deployments as your deployment strategy.
  • Keep “the application” online, while deploying a new version of software by rolling upgrades.
  • Use SaaS monitoring and alerting. We’ve successfully used a combination of Datadog, PagerDuty and Slack-based notifications. 
  • Use Global CDNs (Incapsula, CloudFlare) for improving application security, improving performance and dealing with regional limitations for infrastructure access that might be present in some countries.

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 maintenance applications 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. 


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. 

To make this process easier for you, consider:

  • Extensive user actions capturing. We’ve successfully used ELK stack for this, but there are also a lot of SaaS solutions like FullStory, Segment or Google Analytics that might be an option for your application.
  • Think through your logging strategy and log processing stack beforehand. And think through how you are going to review thousands of lines of logs to find the required line. Splunk, Loggly, ELK stack and similar tools could be the default option for starting an investigation.

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. 


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? 

Don’t increase the cost of your process and product. Before launching, consider:

  • No matter how good your emulator is, always perform the final testing on real vehicles and hardware.
  • Invest extra effort into defining UX for cases where user actions are required to recover from failure. You have to make sure it’s clear for them what to do and what the consequences might be.
  • Think over disaster scenarios in your integration tests, where the 3rd party is unavailable, or has a very slow performance. This should be done for every feature partially or fully dependent on a 3rd party.
  • You should always be able to tell users something more useful than the irritating “Internal error occurred, try again later” message, so clearly define API contracts for 3rd party software in advance, including error messaging.

Wrap up

So, to return to the questions posed at the outset, we’re not quite at the point where diagnostics and maintenance software can be just as visually attractive as most applications on your smartphone. However, with the right approach and by keeping the end-users’ 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.