Designing interfaces around the decisions people make
Most screens exist so that someone can decide something. When the design starts from that decision, rather than from the data or the features, the interface tends to become clearer and quieter.
What does it mean to design around a decision?
It means starting from what a person needs to decide when they use an interface, and designing everything else to support that choice. Instead of asking “what should this screen show?”, we ask “what is this person trying to decide here, and what do they need to decide it well?”
Behind almost every screen sits a decision: approve or return a request, choose which order to handle first, pick a plan, decide whether a number needs attention. Features, data and layout are means to that end. When an interface is organized around what the system contains, people have to do the work of finding what matters. When it is organized around the decision, the system does more of that work for them.
Why do interfaces drift away from decisions?
Interfaces are usually built from what is available. The database has these fields, so the form shows them. The product has these features, so the menu lists them. The report can calculate these figures, so the dashboard displays them. Each addition is reasonable on its own. Together, they produce screens where everything has equal weight and nothing tells you where to look.
There is also a quieter cause: the people designing the interface are rarely the people making the decisions with it. Without seeing the work, it is easy to design for an imagined user who reads every field, rather than for a real person who has a queue, a deadline and a phone ringing.
How do you find the decisions that matter?
We start in Define & Explore, and we try to go and see. Sitting with the people who use a system, watching a task from start to finish, shows which moments carry weight and which are routine.
A few questions help us map them:
- What is being decided, and by whom? Name the decision in plain words. “Is this application complete enough to process?” is more useful than “application review screen”.
- How often, and under what pressure? A choice made hundreds of times a day needs a different design from one made once a quarter.
- What information changes the answer? Most screens show far more than the few pieces of information that actually tip a decision one way or the other.
- What comparison makes it meaningful? A value on its own rarely helps. Against last week, a target or a similar case, it starts to say something.
- What happens next? A decision leads to an action. If the action lives somewhere else, the interface should make that step short.
- What does a mistake cost? Some choices are easy to reverse; others are not. The design should reflect the difference.
An interface is not a container for data. It is a place where someone decides what to do next.
Efabrika
What changes in the design?
Once the decisions are clear, many design choices follow from them.
Hierarchy follows importance
The information that tips the decision comes first and is easy to see. Supporting detail is available, but it doesn’t compete. This often means showing less by default, not more.
The next action sits next to the information
If someone reads a status and then has to navigate elsewhere to act on it, the interface has split one decision into two tasks. Placing the action where the decision is made reduces both effort and error.
Exceptions stand out from the routine
When most cases are routine, the design should make routine cases quick and make exceptions impossible to miss. Treating every item the same hides the few that need attention.
Language matches how people think
Labels should use the words people use when they talk about the decision, not the names of database fields or internal teams.
Reversible choices feel light, irreversible ones deliberate
Easy-to-undo actions can be quick. Choices that are hard to reverse deserve a moment of confirmation and a clear summary of what will happen.
How do you know it is working?
You watch the decisions being made. In Design & Develop we prototype and test with the people who will use the interface, asking them to make real choices with realistic information. Then, in Optimize, we look at how the interface is used over time: where people hesitate, where they go elsewhere to check something, where they reverse a choice. Those observations lead back to Define & Explore and the next round of refinement.
Decisions change as a business changes. New products, new rules and new responsibilities shift what people need to know. Designing around decisions is less a single exercise than a habit of returning to the same question: what is this person trying to decide now?
If you are designing or rethinking a product, platform or internal tool, read more about Digital Products & Platforms, see how we work in our approach, or start a conversation.