Why Employees Quietly Work Around Your Software
How adoption-focused UX design turns unused enterprise software into real usage
- AI Digest
Most enterprise software fails quietly. Nobody files a complaint. The system goes live, gets logged into about once a week, and the real work drifts back to spreadsheets, email threads, and a shared file nobody owns. The features were probably right, the rollout was broadly on plan, the training was duly delivered, and yet the tool sits half-used while the business keeps paying for it. For companies that buy software to run their operations, that quiet failure is expensive.
The encouraging part is that the difference between the software people use and the software they avoid comes down to a discipline that is easy to name: UX design. This piece is about how to get it right.
The hidden cost of software nobody uses
When people avoid the official tool, the cost rarely shows up as a single line item. It hides in the seams of everyday work. The same numbers get typed twice, once into the system and once into the spreadsheet people actually trust. Two versions of the truth drift apart. Reports take longer because someone reconciles them by hand. Errors are entered at every manual handoff. In regulated areas, the shadow process becomes a compliance risk because the audit trail lives in a file that was never meant to hold it.
Industry research shows how common this is. More than 40% of the software licenses companies pay for go unused, according to Zylo’s 2026 SaaS Management Index. The money is only the visible part. The deeper cost is the work that quietly routes around the system you invested in.
For a decision-maker, the translation is simple. You are paying for a system, and paying again for the workarounds that exist because the first investment never took hold.
We explored how parallel digital processes emerge when employees work around official systems in more detail in our Shadow AI at Work → article.
Why adoption is a design question
When usage is low, the reflex is to blame the people. Run more training. Send a reminder. Escalate the matter to change management. That reflex usually misses the mark, because people follow the path of least friction. If the spreadsheet takes four clicks and the official screen takes fourteen, the spreadsheet wins every time, no matter what the training schedule says.
Adoption is decided in the design, long before launch. A well-built interface makes the right action the easy action, mirrors how the work actually flows, and removes the small frictions that send people back to old habits. That is the real job of user experience design: it makes the work faster than the workaround.
The financial case for taking design seriously is well documented. McKinsey tracked 300 companies over five years and found that the strongest design performers grew revenue far faster than their peers, with the gap reaching 32 percentage points. Design rigor shows up on the income statement. This is where many custom software and application development projects stumble. They get the features right and the experience wrong, then read the resulting low usage as a people problem while the cause sits in the design.
What low adoption looks like in retail and wholesale
In retail and wholesale, the cost of low adoption is unusually visible because the software sits in the middle of daily operations. Consider a point-of-sale (POS) system that runs half a second too slow at the counter during a rush. Staff start keeping a paper tally to stay safe, then reconcile later. Or a loyalty-program app where signing up a customer takes too many taps, so cashiers stop offering it, and enrollment quietly stalls. Or a wholesale ordering portal confusing enough that key accounts phone their orders in, which undoes the entire purpose of the self-service channel.
In each case, the feature exists, and the function works. The experience is simply inconvenient enough to lose, and every lost interaction is measurable: a missed enrolment, a slower checkout, a re-keyed order.
How adoption-focused UX design works
So how do you design software people actually use? The answer begins earlier than most teams expect, in how the problem is understood. After 15+ years of building and integrating enterprise systems, we have learned that the real bottleneck is rarely the one written in the brief. We work hands-on, mapping your actual workflow with your team, on a wall, step by step, and watching where the real work goes. More often than not, the real problem hides somewhere you would not have flagged. The screen everyone complained about turns out to be fine, while the silent obstacle is a handoff two steps earlier.
From there, adoption-focused design treats usage as a number to measure and act on.
Measure what people actually do
Track adoption and engagement, DAU/MAU, and task efficiency, meaning how long the real job takes in the tool compared with the workaround. Licenses sold tell you what was bought. Usage tells you what was adopted.
We explored how technology usage can be linked to measurable business value in more detail in our Understanding ROI in AI Projects →article.
Test and iterate with real users
Put early versions in front of the people who will live in the tool, on real tasks, before the build is locked. McKinsey singled out this very habit, steady listening to end users and iteration as the build evolves, as one of the four design actions that set the leaders apart. Let the friction the data exposes guide each revision.
Redesign, then automate
Where a step keeps getting skipped because it is tedious, the answer is often to redesign it and then automate it so the interface handles the boring part, and using the system stops being extra work. Good design and automation reinforce each other at exactly this point.
Adoption starts before the first screen
Here is the uncomfortable part. Most adoption problems are settled before anyone opens a design tool, by how the problem is framed. Define the project as building a loyalty app, and you get a loyalty app that may go unused. Define it as getting cashiers to enroll customers in under ten seconds during a rush, and you get something people reach for. The right problem definition is the precondition for adoption, the first thing to get right at kickoff.
So before your next build, one question is worth sitting with: do you know how your team works around the system you already have?
The takeaway
None of this calls for rare talent. It calls for a few habits applied consistently. Measure real usage rather than assume it. Map the work with the people who do it. Design the easy path toward the action you want, and keep testing after launch. Good software begins with a clear question about how your business actually works, and it earns its keep when people reach for it without thinking. If your software is live but underused, the place to start is defining the right problem before a line of code is written. That is what Omnit’s Service Design engagement is built for: we map your real operations, pin down the actual problem, and turn it into a development concept designed for adoption, with automation that removes the friction that drives people toward workarounds.Sources and further reading
This article draws on Omnit’s project experience and the figures below, which support its broader claims about how much software goes unused and how design performance links to financial results.
- Zylo. (2026). 2026 SaaS Management Index. Zylo. Read article →
- McKinsey & Company. (2018). The Business Value of Design. McKinsey & Company. Read article →
Csaba Fekszi
Csaba Fekszi is an IT expert with more than two decades of experience in data engineering, system architecture, and AI-driven process optimization. His work focuses on designing scalable solutions that deliver measurable business value.
Related posts
A field guide to clear, credible, conversion-ready writing in the age of AI
Turning Organizational Knowledge into Confident Decisions
Turning Ambition into Real, Scalable Results
Are you sure AI is the right next step?
We help uncover the real opportunities, limitations, and realistic next steps.