“Good morning, CNC Solutions.”
“The machine stopped again. There’s some code on the screen, X98-something.”
“Press X and Y, then hit Start. It’s in safety mode.”
“Oh. It’s working again. Thanks!”
Ring.
“Good morning, CNC Solutions.”
“Hi, yeah… the machine’s showing an error again.”
Bart runs customer support at a company that builds industrial machines. He hears this conversation ten times a day.
Four of his team members handle these calls full-time. In the product meeting, the diagnosis comes quickly: error handling needs to improve. Another €100k toward the backend for better fault detection and an auto-reboot feature.
Bart knows the problem isn’t in the code. It’s in how information reaches the customer.
Following the logic
At tech companies, technical thinking tends to dominate. UX challenges often get picked up “on the side” by in-house developers with no design background or training.
The problem: these developers spend their days deep in complex code and systems that maybe 0.3% of the world truly understands. They think in logic, structure, and technical correctness because that’s their daily reality.
But the user on the other side of the screen doesn’t share that reality.
A system can run flawlessly and still be incomprehensible to the person operating it.
That gap explains why Bart’s support team was drowning. The company had built a control interface that made perfect sense to the engineers: a Linux dashboard full of codes, statuses, and technical fault messages.
The people operating the machines aren’t engineers. They’re warehouse operators, often wearing thick gloves. What they saw was a screen full of code and tiny buttons. Every time something went wrong — even something as simple as a package blocking the path — they got a cryptic error message.
No explanation. No instructions. So they call support.
The solution wasn’t better error handling in the backend. It was a redesign of the user’s experience:
- Clear visual feedback
- Step-by-step instructions for common issues
- Larger buttons
- A logical error-handling flow
The result? Three out of four support staff could move on to more valuable work.
What poor UX actually costs
Four employees working full-time on avoidable tickets: even at modest salaries, that adds up to around €200,000 a year. In practice, small friction in your design can quickly generate €30k to €150k in extra support costs annually.
But the costs don’t stop at support:
- Poor onboarding makes customers drop off before they experience your product’s value
- Sales cycles stretch because prospects doubt usability
- Engineers spend time on “bugs” that aren’t bugs
- Support morale drops when they answer the same avoidable questions every day
- At trade shows and demos, competitors who look easier to use instantly gain an edge
These costs don’t appear on a single line in the P&L. They’re scattered, indirect, and easy to overlook — until you add them up.
What UX design actually is
Good UX design comes down to one thing: Closing the gap between how your product works and how your user thinks it should work. On one side you have the implementation model — the technical reality of your product, with all its complexity. On the other side, the mental model of your user — their intuitive expectation of how things should work.
In between sits your represented model: the interface. It can cling to the technical logic — full of system messages only engineers understand. Or it can shift toward the user — intuitive, predictable, aligned with how people actually think.
That technical dashboard of Bart’s? It sat flush against the implementation model.
First steps to understanding your user
To shift toward the user, you first need to understand how they think. A few ways to get there:
Step 1: Go observe. Call your customers and ask if you can watch them work. You’ll discover stakeholders you didn’t know existed and usage patterns no one in R&D anticipated. Test with non-technical friends — even strangers. The wider you look, the clearer the picture.
Step 2: Build personas. Turn your observations into concrete archetypes. Not “User Type A”, but: Nick de Vries, 54, machine operator at Valk Steel. Works in gloves. Zero patience for manuals. These personas become the benchmark for your represented model: every design choice needs to work for Nick.
Step 3: Map the flow. Sketch how people currently move through your product — from their perspective, not the machine’s. Where do they get stuck? Which screens does no one visit? Where do support tickets originate? You’ll likely end up with a tangle of lines and dead ends. That’s your starting point: simplify until a logical path remains.
Next steps
These four steps are merely the blueprint. Anyone who takes this seriously will quickly hit the next, more complex, engineering challenges:
- Requirements: What can our core technology realistically support in the interface?
- Prioritization: Which friction points (features) must we fix first to unlock the most value for Bart’s support team?
- Testing: How do we set up reliable A/B tests to prove the new design works? (Remember: data, not opinions.)
Need some help getting started? At Kinekt we are specialized in getting you up and running on a better product experience. Click here to schedule a first conversation.
