Situational design: beyond predefined flows.

Designing the rules for when interfaces should adapt, and how users stay in control.

Many digital products still leave one important job to the user: figuring out where they need to go when something changes.

We interview a small group of users and subject-matter experts, identify patterns that repeat, and use those patterns to design experiences for a much larger group. This works well for recurring behavior. But those patterns don’t always tell us what matters most right now, for this person, in this moment.

Traditional UX already has tools for surfacing something important: notifications, alerts, banners, badges, personalization. Often, these tools add a signal to the existing hierarchy. They can change what gets attention, but a team still needs rules for when that change is justified.

“Adaptive UI” and “generative UI” raise questions about the mechanism: how a system decides what to change. This piece is about something upstream of that: how a team decides when it’s allowed to change anything at all, and what happens when it’s wrong.

Consider an insurance app. Under normal circumstances, a customer sees:

Coverage · Payments · Documents · Claims

Now imagine that same customer just reported an accident. The app could instead lead with:

What to do now · Start your claim · Roadside assistance

Coverage and payments haven’t disappeared. They’ve become less prominent because they’re less important right now. The user didn’t enter a different product. The existing claims and assistance flows can stay intact. What changed was the priority.

Situational Design, defined

Situational Design uses what the system already knows, plus what’s happening right now, to decide what the interface should emphasize. Instead of giving everyone the same hierarchy and asking them to sort it out, the system brings the most relevant information forward and keeps the familiar routes to everything else available.

For an existing user, that might mean role, account status, recent activity, behavioral history. For a new user, it’s mostly explicit input and sensible defaults. Past behavior gives context. The current situation sets priority. The goal is to change what deserves attention, and leave the rest alone.

The Priority Problem

As enterprise products grow, they accumulate functionality. New workflows, roles, exceptions, reports, alerts, settings, integrations, all landing in the same product.

The result can be an interface that makes everything available while leaving users unsure what to look at first

The Mega-Dashboard Fallacy

When products can’t establish clear priority, they often respond by showing more: more navigation, more cards, more alerts, more options. The result is the familiar mega-dashboard: everything a user might need, and the user still responsible for finding it.

Before anyone can act, they have to do another job first. They have to translate a real-world situation into the system’s internal structure. Where do I go? Which option applies to me? What do I do first? The functionality exists. The interpretation is still theirs.

I call this Interpretation Cost: the effort required to translate a real-world situation into a product’s internal structure.

A well-organized interface can reduce navigation friction and still leave that interpretation entirely to the user. A flow can guide someone through a task. Mapping that flow alone doesn’t tell you when the task deserves attention.

Situational Design shifts some of that translation work from the user to the system, using known conditions and business rules to set priority before the user has to.

Context Is Not Priority

We call intelligent products “context-aware,” but context alone doesn’t tell a system what matters. A system can know your location, the time, your device, your transaction history, and still have no basis for deciding what to prioritize. Data isn’t interpretation.

Take the insurance example again. The system might have an accident report from twenty minutes ago, a recent location update the customer has agreed to share, and a record that they just opened the app. The report is explicit. Whether they still need roadside help is an inference. The design question is what those signals mean and whether the system is confident enough to act on them.

Real products already use signals to change how an experience responds. Revolut describes declining suspected scam payments and introducing a verification flow, and reported a 30% reduction in resulting fraud losses. Lemonade describes checking submitted claims, paying about 40% of them instantly, with the fastest settled in three seconds.

Those are operational decisions. In our insurance example, bringing roadside assistance forward is an interface decision. Dispatching a tow truck would be an operational one. Bringing an action forward and taking that action on someone’s behalf require different permissions. The company examples illustrate that broader distinction. They don’t validate the interface approach proposed here.

The broader idea of technology responding to changing circumstances isn’t new. In 2014, Mads Buch Stage used “Situational Design” to describe prioritizing content around a user’s circumstances. Microsoft’s 2019 guidelines for human–AI interaction address contextual relevance, uncertainty, correction, and cautious adaptation. This piece focuses on the decision rules: what evidence justifies changing interface priority, what may change, and when the change should end.

AI gives teams more ways to interpret signals together, including incomplete information expressed in ordinary language. That can expand the situations a product attempts to recognize. That capability alone says nothing about whether the interpretation is correct. A reported accident may need only a clear business rule. An inferred need for help requires more judgment.

But greater capability doesn’t solve the design problem. It makes it more urgent. The more a system can infer, the more important it becomes to define what it’s allowed to do with those inferences.

Situational Design brings these concerns together around a specific decision: when a situation justifies changing interface priority. That means designing the rules and boundaries of the change: what the system knows, what it’s inferring, how confident it is, what it’s allowed to change, and how the user stays in control.

When the System Gets It Wrong

The real test of Situational Design is what happens when the system gets the situation wrong.

A system can misread a signal, work from incomplete information, apply the wrong rule, or overweight one pattern in someone’s history. Open an insurance app to accident support when you haven’t had an accident, and at best it feels irrelevant. At worst, it feels intrusive.

The stakes rise sharply when a system infers something sensitive: a health concern, financial strain, a personal crisis. Being able to detect a pattern doesn’t mean a product is entitled to surface it, or to act on it.

Three principles hold this together.

Visible. The user can understand what changed and, when it matters, why. The system doesn’t need to explain its entire reasoning, but a meaningful change shouldn’t leave anyone wondering what happened.

Proportional. The strength of the intervention should reflect the evidence, the cost of acting incorrectly, and the cost of doing nothing. A weak signal may justify a question or no change at all. Stronger evidence may justify bringing an action forward. Automatically taking that action requires its own policy and safeguards. Confidence alone isn’t permission.

Reversible. The user can dismiss an inferred priority, correct the situation, and get back to the familiar structure without a fight. Dismissing an assistance suggestion should restore the usual priorities. It should not silently cancel a service the customer has already requested. Reversing an interface change and undoing an operational action need separate controls.

How to Design for a Situation

You don’t need to rebuild the whole product. Start with one situation where users repeatedly can’t tell what deserves attention.

Return to the insurance customer. They’ve reported an accident, but the system doesn’t yet know whether they need roadside help. What follows is a proposed design, not a report of a deployed product or a completed user study.

1. Define the situation and the evidence. The accident report tells the system what happened. On its own, it says nothing about what the customer needs next. An explicit request for assistance is stronger evidence than simply opening the app again. Decide which signals are strong enough to justify a question, which justify a full priority change, and which shouldn’t move anything at all.

2. Identify what becomes primary, and what stays off-limits. After the report, the app can bring assistance and claims actions forward. If the customer says they need roadside help, assistance becomes primary. That still doesn’t authorize the app to order a service on its own. The customer confirms that action separately.

3. Decide what stays stable. Navigation, coverage, payments, documents, the usual destinations, none of it needs to move. Someone who opens the app to find a policy document should still be able to do that, even while the system thinks assistance matters more.

4. Make the smallest useful change, and give it an end point. Show the relevant action with a short explanation: “You reported an accident. Do you need roadside assistance?” Offer “View assistance options” and “I don’t need assistance.” The second response clears the suggestion. If assistance has already been requested, show its status instead of asking again, and once it’s resolved, stop giving it priority.

The same situation can produce different responses depending on what the system actually has to go on:

It helps to write this down as a situation specification the team can review alongside its flows.

The expiry rule above is a starting hypothesis, not a settled answer.
It trades the risk of missing a later need against the cost of interrupting someone repeatedly, and assistance stays available either way. Writing the specification down is what makes that tradeoff visible before it turns into product behavior.

Test the priority, and the mistake

Compare two prototypes with the same content and available actions: one with the usual hierarchy, one with situational priority. Give participants the same circumstance and goal, without naming the button they should choose.

Test both the useful case and the mistaken one. Start with someone who needs roadside help, and watch whether they find the right action sooner. Then try someone who already arranged help elsewhere, and watch whether they can dismiss the suggestion and still find a policy document. On a return visit, watch whether an old situation keeps taking over when it shouldn’t. Vary which version participants see first, and track time, wrong turns, recovery, and what they believed the system had already done.

A faster assistance task alone wouldn’t be enough to call this a success. If unrelated tasks become harder, or people misunderstand what the system has done, the rules need work. These are proposed checks, not measured results.

Define What Stays Stable

Across those situations, teams need a consistent boundary for what’s allowed to change.

Keep the core stable and constrain what is allowed to adapt.

The stable core is what users should be able to rely on: navigation, identity, essential controls, the underlying information architecture. The adaptive surface is the approved set of things that can respond to a situation: priority actions, recommendations, warnings, support paths, temporary shortcuts.

Think of it as a box of parts that have already been designed, tested, and approved. The intelligence lies in choosing which existing parts come forward, when, and for how long.

That gives generative UI a boundary. It doesn’t get to redesign the experience on its own terms. It operates inside a defined system of components and rules: controlled adaptation inside stable boundaries.

The Situation as a Unit of Design

Flows are a familiar unit of UX design. We map journeys, connect screens, remove friction between steps. That work still matters.

The situation deserves equally explicit attention. A situation carries signals, uncertainty, urgency, and consequences when the system gets it wrong. That expands the designer’s job beyond screens and flows to deciding which situations matter, what signals represent them, how confidently they can be read, what the system is allowed to change, and how someone recovers when it changes the wrong thing.

Situational Design means writing the rules for when a shift is justified. An interface in constant motion is what happens when those rules are missing.

The flow tells you where a user can go. The situation tells you what deserves attention once they get there.

Situational design: beyond predefined flows. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.