There's a belief that runs quietly through enterprise software: if the business is complicated, the software should look complicated too. A simple screen must be hiding something. A dense one must be powerful.
It's an understandable instinct. The work really is complex — regulated processes, exceptions, approvals, legacy integrations. But the complexity of a domain is not a reason to pass that complexity through to the person using it. That's just moving your problem onto them.
Where complexity actually goes
Every system has a fixed amount of irreducible complexity. Design doesn't remove it; design decides who absorbs it. When an interface looks simple, someone made a series of hard decisions to hold that complexity elsewhere — in defaults, in data modeling, in progressive disclosure, in a rule engine rather than a form field.
When an interface looks complex, usually nobody made those decisions. The screen is a mirror of the database, and the user is doing the translation work the software should have done.
A simple interface is not a smaller product. It's a product where someone did the work of deciding what matters first.
Four questions that cut a screen down
When we're reducing an over-loaded interface, four questions do most of the work:
- What decision is this screen for? Not what data does it hold — what will someone do differently after looking at it.
- What can the system already know? Every field a user fills that could have been derived, defaulted, or remembered is a design failure with a keyboard attached.
- What is the exception, and what is the norm? Interfaces bloat because the rare case is treated with the same prominence as the daily one. The exception needs a path, not a permanent seat.
- What happens if we remove it? Not 'could someone conceivably want this', but 'what breaks'. Most contested elements survive on the first question and fail the second.
Simple is not the same as sparse
This is where simplification goes wrong. Stripping a screen until it's beautiful and useless is not simplification — it's abdication. The people doing serious work in a serious tool need density where density earns its place: a dispatcher watching forty jobs, a reviewer comparing two records, an analyst scanning for the outlier.
The test isn't how much is on the screen. It's whether what's on the screen is what the moment requires. A dense view built around one clear task reads as calm. A sparse view that hides the thing you need reads as broken.
In the Design stage we prototype the busiest, ugliest real case first — the account with forty exceptions, not the clean demo record. If the design holds there, it holds everywhere. If we design for the demo, we ship a demo.
The organizational version
The same pattern shows up above the interface. Teams describe their process as complicated when what they mean is that it's undecided. Five approval paths exist because nobody chose one. Three tools overlap because nobody retired any. Software built on top of that indecision inherits it, and then the software gets blamed.
Which is why the useful question at the start of a project is rarely 'what should this screen look like'. It's 'what has this organization not decided yet, and can we decide it here'. Answer that, and the interface gets simpler on its own.
Working on something this touches? We're usually happy to talk it through before anyone commits to a project.
Start a conversation