UX doesn't end at launch: designing adoption for complex software

UX doesn’t end at launch: designing adoption for complex software

“The biggest challenge wasn’t teaching users where to click. It was helping them understand why the workflow mattered.”

The uncomfortable truth about intuitive software

One of the most persistent ideas in UX is that great software shouldn’t require training. If we’ve done our jobs correctly, users should intuitively understand how a product works, move through workflows effortlessly, and achieve their goals without needing documentation or guidance.

It’s a wonderful aspiration, but after more than fifteen years designing enterprise software, I’ve found it rarely reflects reality.

The idea works well when we’re talking about everyday consumer products. Ordering dinner, booking accommodation, or checking the weather should require very little explanation. The interaction itself is the task.

Enterprise software is different.

In highly specialised industries such as mineral exploration, logistics, agriculture, and geoscience, users aren’t trying to learn software. They’re trying to solve complex business and scientific problems. The software is simply a tool that helps them achieve those outcomes.

The challenge becomes even greater when the product introduces an entirely new way of working.

When users aren’t just learning software

One of the most interesting examples of this in my career has been Comet, Fleet Space’s geochemical modelling platform.

Comet enables exploration teams to use existing geochemical assay data and estimate quantitative mineralogy using thermodynamic modelling. While that sounds straightforward enough on paper, the reality is that many users had never worked this way before.

Historically, mineralogical interpretation often relied on a combination of geological expertise, visual core logging, laboratory testing, and years of accumulated experience. Comet introduced a different approach by allowing exploration teams to extract entirely new insights from data they already possessed.

Initially, it seemed the onboarding challenge would revolve around explaining software functionality. We assumed users would need guidance on uploading files, selecting mineral systems, configuring models, and interpreting results.

What quickly became apparent was that none of those things were the real obstacle.

Users weren’t asking where to click.

They were asking whether they could trust the results.

They wanted to understand the assumptions behind the models, how the outputs aligned with traditional geological interpretation, and how the results could be applied within existing exploration workflows. These weren’t software questions. They were confidence questions.

That distinction changed how we approached onboarding entirely.

Nobody wants training

One of the biggest lessons I’ve learned throughout my career is that users rarely want education for its own sake.

Nobody arrives at work excited to complete a training course. Nobody blocks out an afternoon hoping to read documentation. People engage with learning because they believe it will help them achieve a meaningful outcome.

Unfortunately, many onboarding experiences are still designed around features rather than goals.

The result is often a comprehensive explanation of every menu, setting, and configuration option available within the system. While technically accurate, this style of onboarding frequently overwhelms users with information before they’ve developed any understanding of why the product matters.

When developing learning materials for Comet, we deliberately shifted our focus away from features and towards outcomes.

Instead of explaining how individual controls worked, we focused on helping users understand geological context, mineral systems, modelling assumptions, and practical applications. Rather than teaching screens, we taught workflows. The software became a supporting actor in a larger story about exploration decision-making.

That shift dramatically changed the quality of conversations we were having with users.

Stumbling into instructional design

If I’m being honest, I never set out to become someone who creates onboarding experiences.

My background is product design. Over the years I’ve designed logistics platforms, geoscience applications, breeding management systems, AI-powered products, cloud software, and enterprise tools. Yet regardless of the industry, I repeatedly found myself becoming involved in onboarding, enablement, documentation, and training.

Not because I had formal instructional design qualifications.

Because UX naturally sits between users, products, and business outcomes.

When users struggle, designers are often uniquely positioned to identify where the confusion originates. We understand what the product is trying to achieve, what the business needs users to do, and where users begin to lose confidence.

Over time, that naturally led me towards creating onboarding experiences using a variety of tools and formats. More recently, that included Articulate 360, which allowed us to create structured, interactive learning experiences rather than relying solely on traditional documentation.

What I found particularly valuable wasn’t the technology itself. It was the ability to guide users through a narrative that progressively built understanding and confidence.

Subject matter experts are the real heroes

One of the biggest mistakes designers can make in highly technical industries is assuming they need to become the expert.

I’ve learned the opposite is usually true.

I am not a geologist, geochemist, or mining engineer. My role is not to replace decades of scientific expertise. My role is to work alongside experts and translate that knowledge into experiences that are approachable, understandable, and actionable.

Throughout the Comet project, close collaboration with domain experts became one of the most valuable parts of the onboarding process. These specialists possessed enormous amounts of knowledge, but they were often so familiar with the concepts that it became difficult to recognise where new users might struggle.

Designers are uniquely positioned to bridge that gap.

We identify assumptions, uncover hidden complexity, and help structure information in ways that allow users to build confidence gradually rather than becoming overwhelmed. In many ways, creating effective learning experiences isn’t all that different from creating effective interfaces. Both disciplines involve helping people move from uncertainty towards confidence.

The onboarding became user research

One of the most unexpected outcomes of building onboarding content was how much we learned about the product itself.

Every question users asked revealed something about their mental models. Every moment of hesitation exposed a potential gap in understanding. Every support request highlighted assumptions we had unknowingly built into the experience.

In several cases, what initially appeared to be a learning problem turned out to be a product problem. Users weren’t confused because the onboarding content was inadequate. They were confused because the workflow itself wasn’t communicating intent clearly enough.

This created a powerful feedback loop.

The onboarding improved the product.

The product improved the onboarding.

Together, they improved adoption.

Measuring more than usability

One of the reasons I’ve become increasingly interested in onboarding is because it sits so closely to business outcomes.

Following the rollout of structured onboarding pathways, guided learning experiences, and supporting educational content for Comet, we saw measurable improvements in user perception and engagement.

Results

• 23% increase in System Usability Score (SUS)
• 82% Customer Satisfaction Score (CSAT)
• Interactive onboarding delivered through Articulate 360
• Reduced uncertainty around geochemical modelling workflows

These outcomes weren’t driven by onboarding alone. The product continued evolving alongside the learning experience. However, the results reinforced something I’ve suspected for years: helping users understand a product is often just as important as building the product itself.

UX doesn’t stop at the interface

Looking back across my career, some of the most valuable work I’ve contributed to happened after the software shipped.

Not because interfaces aren’t important, but because adoption is where success is ultimately measured.

Users don’t separate the product from the onboarding. They don’t distinguish between documentation, training materials, help centres, walkthroughs, support articles, and interfaces. To them, it’s all part of the same experience.

The more complex the software becomes, the more important that holistic view becomes.

Today, I no longer see onboarding as a post-launch activity or a box to tick before release. I see it as one of the most powerful design tools available. It builds confidence, accelerates adoption, uncovers product issues, reduces uncertainty, and ultimately helps users achieve meaningful outcomes faster.

That’s why I’ve come to believe that UX doesn’t end at launch.

In many ways, that’s where the real work begins.