Designing for Decisions, Not Screens

Most of what we teach about UX assumes the user is trying to get something done and then get out. Buy the thing. Book the flight. Submit the form. Find the answer. Under that assumption the design goal is clear enough: fewer steps, less friction, less time on task. Nearly every heuristic we reach for inherits that framing, and for most consumer software it holds up fine.

There is a large category of software where that framing quietly breaks. The user is a forecaster deciding whether to issue a warning. An emergency manager deciding whether to open a shelter. A pilot deciding whether to divert. A physician deciding whether the labs justify admission. An analyst deciding whether the exposure is worth carrying overnight. None of those people are trying to complete a task. They are trying to be right about something, under time pressure, with incomplete information, and with real consequences attached to being wrong.

I have spent a good part of the last few years designing tools in that category, mostly in weather and public safety, and it has changed how I think about the work. In decision support, the interface is not the product. The decision is the product. The interface is just the place where someone's reasoning happens.

Completion is not the goal

The clearest signal that you are in decision-support territory is that you cannot define success as finishing. There is no confirmation screen. There is no green checkmark. The user forms a judgment, acts on it, and finds out hours or days later whether the judgment was any good.

That breaks the usual measurement story. Time on task, clicks to completion, funnel drop-off: these tell you almost nothing when the user's real objective is confidence in an assessment. A forecaster who spends twelve minutes in a tool and gets the call right has used it well. A forecaster who spends ninety seconds and gets it wrong has not. If you optimize the metrics you are used to, you will happily ship a product that makes people faster at being wrong.

What replaces those metrics is harder to instrument and worth the trouble. Did the person notice the thing that mattered? Did they understand how confident they should be? Could they explain the reasoning behind their call afterward? Those are the questions the tool is actually accountable for.

Speed is the wrong default

The reflex in our field is to remove friction wherever we find it. In decision environments that reflex needs a governor on it, because not all friction is waste. Some of it is the deliberation the situation deserves.

The distinction I try to hold onto is between friction in the mechanics and friction in the thinking. Mechanical friction is always fair game. Nobody makes a better call because they had to remember a filename, re-enter a location, or click through four panels to compare two data sources. Strip all of that out and keep stripping. But friction in the reasoning is different. A confirmation step on an irreversible action, a required acknowledgment that a data source is stale, a layout that makes you look at the counterevidence before you commit: those are deliberate speed bumps, and they earn their cost.

The honest version of the goal is not "make this faster." It is "spend the user's time on the parts that deserve it." Sometimes that means the tool gets slower in exactly one place and much faster everywhere else.

Cognitive load is a budget you are spending on someone's behalf

Every expert working a live situation has a fixed amount of working memory, and it is already committed. They are holding the current state of the event, what changed in the last ten minutes, who they have already talked to, what they promised, and what they expect to happen next. Whatever your interface demands comes out of that same account.

This is why I have stopped treating cognitive load as a general virtue to gesture at and started treating it as an allocation question. Anything the software can carry, it should carry: unit conversions, timestamps in the user's own timezone, remembering the last configuration, keeping labels visible instead of making people recall what a color meant. Every one of those is load returned to the user for the part only they can do, which is interpreting the situation in front of them.

The failure mode here is sneaky, because it does not look like a usability problem. The screen looks fine. Nothing is broken. The user just has slightly less capacity for the judgment than they should, and under pressure that is exactly where a mistake comes from.

Hierarchy is an argument, not a layout

In most product work, information hierarchy is a matter of emphasis and scanability. In decision support it is closer to an editorial position. When you make one number large and put it at the top, you are telling an expert that this is the thing to look at first. If you are wrong about that, you have quietly steered a decision.

I have come to think of hierarchy in these tools as a claim I have to be able to defend. Why is this at the top? Is it there because it is genuinely the leading indicator for this kind of call, or because it fit nicely in the layout? That question has changed a lot of my designs, and it has occasionally sent me back to the subject matter experts to find out what they actually look at first, which is rarely what a designer would guess.

The corollary is that hierarchy should be able to change when the situation does. What matters most in a quiet period is not what matters most during an active event. Interfaces that hold a single fixed hierarchy across every condition are making one correct argument and several wrong ones.

Uncertainty is content, not a disclaimer

Almost every consequential decision is made on information that is incomplete, probabilistic, or aging. And almost every interface I see treats that fact as an inconvenience to be tucked into a footnote, a tooltip, or a gray line of small type under the number.

That instinct is understandable and it is backwards. Uncertainty is not a caveat on the information. In these domains it very often is the information. The difference between a forecast with tight agreement across models and one where the models disagree wildly is not a nuance to disclose, it is the entire basis for how strongly someone should act. A single confident-looking number hides the one thing the expert most needs to know.

Practically, this means designing uncertainty as a first-class element with the same care given to the primary value. Ranges instead of points where ranges are the truth. Visible model spread. Timestamps that make staleness obvious at a glance rather than on hover. Language that separates what is observed from what is projected. Experts are already comfortable reasoning about probability. It is our interfaces, not our users, that keep pretending the world is deterministic.

An alert is a claim on someone's attention

There is a real difference between information and an alert, and most systems blur it. Information is available when the user goes looking. An alert interrupts. Interruption is expensive in a way that is easy to underestimate, because the cost is not the two seconds of reading. It is the loss of whatever the person was holding in their head at the time.

Anyone who has worked in an operations environment has watched what happens when that budget gets overdrawn. Alerts that fire too often stop being signals and become background noise, and then the one that mattered arrives and lands in a room that has learned to ignore that sound. Alarm fatigue is a design failure, not a user failure.

The bar I try to hold is simple to state and uncomfortable to apply: an alert should be reserved for something the user must act on now and would not otherwise see in time. Everything else is information, and information belongs in the interface where it can be found deliberately. Most of the alerts I have reviewed in my career, including some I designed, do not clear that bar.

Progressive disclosure for people who know more than you do

Progressive disclosure usually gets framed as a way to protect novices from complexity. With expert users the purpose inverts. You are not hiding depth because they cannot handle it. You are staging it so they can get to the level they need without wading through the levels they do not.

Experts move fluidly between altitudes. A forecaster wants the summary view when scanning, and thirty seconds later wants the raw model output because something in the summary looked off. Both of those are the same person in the same minute. A tool that only offers the summary is condescending, and a tool that only offers the raw data is exhausting. The design work is in the transitions: making it fast to descend into detail, obvious how the detail rolls up into the summary, and effortless to come back out.

The rule I keep coming back to is that you can hide complexity but you must never hide the path to it. The moment an expert suspects the system is holding something back, you have lost them, and they are right to leave.

Trust is the actual deliverable

Every decision-support tool is asking a professional to fold its output into a judgment they are personally accountable for. That is a significant thing to ask. Trust is not a nice-to-have layer on top of the product. It is the mechanism by which the product does anything at all.

The failure mode people worry about is under-trust: the expert who ignores the tool and works from their own experience instead. That does happen, and it usually means the tool has been wrong in a way it never acknowledged. But over-trust is the more dangerous outcome and gets far less attention. A system that always looks equally authoritative teaches people to defer to it, including in the situations where it has the least to offer. Confident presentation of a weak signal is not a visual design choice. It is a safety problem.

What builds appropriate trust is fairly consistent across domains. Show provenance, because experts want to know where a number came from. Show your work, or at least enough of it that a specialist can sanity-check the conclusion. Degrade honestly, so that when data is missing or stale the interface says so plainly rather than rendering a slightly wrong picture with full confidence. And be consistent, because a tool that behaves the same way every time can be learned, and a learned tool is one people can rely on when they are too busy to think about the tool at all.

The part that is humbling

Designing for experts requires giving up a role we are used to occupying. In most product work, the designer can develop a reasonable model of the user through research and empathy. With domain experts you cannot. A forecaster has years of pattern recognition you will never acquire from a handful of interviews, and a meaningful part of their expertise is tacit, which means they often cannot articulate it either. Asking them what they need produces incomplete answers, not because anyone is being unhelpful, but because the knowledge does not live in a form that survives being asked about directly.

What works better is watching them work, especially during real events, and paying attention to what they do rather than what they say. The workarounds are the most valuable thing you will see. When someone keeps a spreadsheet alongside your application, or screenshots one panel to paste into a chat, they are showing you a requirement that never made it into any document.

It also means accepting a different relationship to the work. You are not the authority on what is right here. You are the person responsible for making sure the authority can see clearly, think clearly, and act in time. That is a supporting role, and I have come to find it more interesting than the alternative.

Wrapping Up

The premise underneath most UX practice is that we are helping people do things. In decision support we are helping people know things, and then live with what they decide. Those call for different instincts. The metrics change, the role of friction changes, uncertainty moves from the footnotes to the foreground, and the measure of a good interface becomes whether the person using it made a better call than they would have without it.

This is not a niche concern anymore. As more software gets pointed at judgment-heavy work, including the growing pile of tools that surface model output and expect a human to decide what to do about it, more of us are going to find ourselves designing for decisions whether we planned on it or not. It is worth knowing when you have crossed that line, because the playbook that got you here will not carry you across it.