When you see low adoption or users not using a product as intended, what is the easiest thing to do? Blame training. "We aren't training users well enough. We need to double down on training."
But what happens when users spend more time in getting trained, learning what type of issues can occur, how to avoid them, and how to solve them, rather than actually engaging with the product?
Training and Product are a Cohesive Experience
It is necessary to treat physical training as part of the overall product experience, especially for products that have both physical and digital touchpoints. You cannot compensate for product complexity simply by doubling down on training.
For example, in healthcare screening camps where setups are highly mobile, you have to pack, unpack, and move machines and hardware daily. The hardware to enable the software is equally important, one cannot exist without the other. Setting up the hardware experience shouldn't be treated as an afterthought compared to the app or software. No one touchpoint is superior to the other.
Both physical and digital touchpoints need to feel cohesive to users, rather than making them feel like they are being trained to use two completely different products. In some cases maybe complexity is unavoidable, like screening camps will have a complex process to connect all machines and equipment together but that friction should not overpower the actual value the product provides or make users question its worth.
Training is helpful when it complements the product, not when it makes users feel like, "This is too much work, and I don't see any value in using this." If either the physical or digital touchpoint feels heavier than the other, product adoption will get impacted negatively.
When troubleshooting dominates the experience, users end up interacting with two products:
- Product A: The core product designed to make their daily tasks easier.
- Product B: The complex set of workarounds required just to keep Product A running.
If Product B requires more time and mental energy than Product A, adoption will drop the moment the trainer walks away.
A quick way to identify this: watch for users skipping steps in the workflow, or raising issues before completing it, and saying the product is not working.
Even when a domain or industry is inherently complex and environmental challenges are unavoidable, the solution is to design around that complexity to create a unified experience.
If your software depends on how successfully physical hardware is connected, that setup must be simplified. You have to design in a way that actively removes barriers to entry, rather than relying on trainers to go out and teach users workarounds again and again. Constant troubleshooting doesn't help users in the long run, it just leads them to stop interacting with the product altogether. If a user does not interact with your product after onboarding, it's not always on the trainers. Training can only do so much. At the end of the day, training should never feel heavier than the actual value the product delivers.