Open most enterprise software and you'll see the same thing. Grey tables. Tiny fonts. Buttons everywhere. Sixteen tabs across the top and a sidebar that scrolls forever. Somebody built it to a spec. Nobody designed it for a person.
What You Need to Know
- Enterprise users spend more time in your tool than almost any other activity at work
- Bad UX isn't just ugly, it causes errors, slows people down, and kills adoption
- Design for enterprise means understanding workflows, not just wireframing screens
The Eight-Hour Test
Here's something I think about on every project. If someone is going to use this system for eight hours a day, five days a week, what does that actually feel like?
Not for the first ten minutes during a demo. Not for the stakeholder who sees it once at sign-off. For the person in the chair. The case worker processing applications. The coordinator managing schedules. The analyst pulling reports at 4pm on a Friday.
That person doesn't care about your design system. They care about finding what they need without clicking through four screens. They care about not making mistakes because the interface is confusing. They care about going home on time.
Good design isn't decoration. In enterprise, that gap is the difference between a successful rollout and an expensive shelf ornament.
Rainui Teihotua
Chief Creative Officer
Why Enterprise UX Is Usually Bad
It's not because nobody cares. It's because the people buying the software aren't the people using it. The procurement team evaluates features on a checklist. Does it do X? Yes. Does it do Y? Yes. Does it feel good to use for eight hours straight? That question never gets asked.
A 2014 study by the Nielsen Norman Group found that enterprise applications had an average task-completion rate 20% lower than consumer apps. Not because the tasks were harder. Because the interfaces were harder.
And then organisations wonder why adoption is low, why staff find workarounds, why the expensive new system runs alongside the spreadsheet it was supposed to replace.
What We Do Differently
At IDESIGN, design isn't a phase that happens after the build is scoped. Rainui is in the room from day one. That's deliberate.
We watch people work. Before we design anything, we sit with the people who'll use the system. Not the managers. The operators. We watch how they move through their current process. Where they hesitate. Where they swear under their breath. Where they switch to a different tool because the primary one can't do what they need.
We design for the common path. Most enterprise tools try to surface every feature at once. We figure out what people do 80% of the time and make that effortless. The other 20% is still there, but it's not cluttering the screen while someone processes their fiftieth application of the day.
We test with real users, not stakeholders. A design review with a project sponsor tells you if the brand colours are right. A usability session with an actual operator tells you if the thing works.
20%
lower task-completion rates in enterprise vs consumer applications
Source: Nielsen Norman Group, 2014
Design as Infrastructure
There's a tendency to treat design as surface-level. Colours, fonts, rounded corners. That stuff matters, but it's the smallest part of what we do.
The real design work is structural. How information is organised. What's visible and what's hidden. How many steps it takes to complete a task. What happens when something goes wrong. These decisions determine whether a system helps people or gets in their way.
I've watched talented, competent professionals struggle with software that a first-year design student could improve in an afternoon. Not because the developers didn't care, but because nobody with design training was involved when the decisions were made.
The Return on Design
Organisations don't always see design as an investment. They see it as a cost. Polish. Nice-to-have.
But when a system is easier to use, training time drops. Error rates drop. The help desk gets fewer calls. People actually use the features you built instead of working around them. Adoption goes up not because you mandated it, but because the tool is genuinely better than the alternative.
That's the argument I make on every project. Not "let me make it pretty." Rather: let me make it work for the person who has to live in it.