Most interfaces that feel wrong were not badly drawn. They were built around the wrong thing. Somewhere between the database schema and the screen, the question quietly changed from “how will someone use this?” to “how do we get all of this onto a page?”
That is the difference between an interface that serves a purpose and one that serves a utility.
Purpose Over Utility
A utility-driven interface is shaped by what is convenient to build. The API returns twenty-four fields, so the page shows twenty-four fields. The table has eleven columns because the entity has eleven columns. Every option the backend supports gets a control, every state gets a badge, and the result is technically complete and practically exhausting.
A purpose-driven interface is shaped by what someone is trying to accomplish. It starts from the operation, not the payload: this person opened this screen to approve a request, find one order, or change one setting. Everything that helps them finish that is prominent. Everything else moves out of the way, or out of the screen entirely.
Both versions “work” in the sense that all the functionality is reachable. Only one of them is usable without a training session.
Start With the Operation, Not the Data
Before any layout exists, we try to answer one question in a single sentence: what will the user actually do here?
Not what the feature contains. What they do. “Reschedule an appointment.” “See whether yesterday’s import failed.” “Send this invoice.” A sentence like that immediately tells you what belongs on the screen and what does not, and it does so before you have invested a week in building the wrong thing.
The interesting part is how often this sentence contradicts the data model. The model has customers, appointments, providers, and services as separate things, because that is correct for storage. The user has one intention: move this booking to Thursday. When the interface mirrors the model instead of the intention, the user has to do the translation work in their head, every single time.
Start Embarrassingly Simple
Here is the part that is hard to accept: the first version should feel too simple.
One clear action. The three or four fields that are genuinely required. No configuration for cases nobody has asked for yet, no secondary panel, no bulk operations, no filters for a list that currently has eleven rows. If you are unsure whether something belongs in the first version, it does not.
This is not about shipping less for its own sake. A simple first version is the only version you can honestly evaluate. When a screen has one purpose and four elements, and it still feels awkward, you know exactly what to fix. When it launches with thirty elements, the awkwardness has thirty possible causes and you will guess wrong about which one matters.
Then Use It Yourself
The simple version is not the deliverable. It is the instrument you use to find out what the interface actually needs.
So we use it. Not a click-through of the happy path, but the real thing with real data: the record with an absurdly long name, the empty state on day one, the list after it has grown to four hundred rows, the form filled in on a phone with one hand. Ten minutes of genuine use surfaces more than an hour of reviewing a mockup, because friction is something you feel rather than something you see.
What comes back from that is specific and unarguable. The confirmation step is one click too many. The most-used action is the one buried in the dropdown. The status column everyone squints at should be a color, and the three columns nobody reads should be gone. None of this was visible on paper. All of it is obvious after using the thing for a week.
Improve in Small Passes
Then it becomes a loop, and the loop is where good interfaces actually come from.
Each pass changes one thing and gets used again. Notably, most passes remove or reshape rather than add: a field becomes a sensible default, two steps collapse into one, a rarely used option moves behind a link, a label finally says what the button does. Additions happen too, but they are earned by a real need somebody hit, not anticipated by a meeting.
There is an enormous body of thinking on what makes interfaces good, and it is worth reading: visual hierarchy, affordances, feedback, accessibility, consistency. That is not what this post is about, and it is also not where you should start. Those principles help you understand why the version in front of you is not working. They cannot tell you what to build first, and they will not save an interface built around the wrong sentence.
Why the Incremental Approach Wins
Nobody designs a great interface in one pass. The teams who appear to have done it simply did the passes before you saw the product.
The incremental approach is more honest about that. It gets something real in front of a real user quickly, keeps the surface small enough to reason about, and lets the interface be corrected by use rather than by opinion. It also tends to be cheaper: the features you never built because nobody missed them are the least expensive features you will ever ship.
The trade-off is that you must actually run the loop. A simple first version that is never revisited is not a minimal interface, it is an unfinished one. The value comes from the fact that it keeps improving while people use it.
This is how we build interfaces in our own products and in client work: define the one thing the screen is for, ship the smallest version that does it, use it in anger, then improve it in small, deliberate passes. It is slower to feel finished and much faster to be good.
If you have a feature that works but nobody enjoys using, we would be happy to take a look at it with you.