A decision interface is a screen where a person receives information that a system has already prioritized, interpreted, or summarized, and then has to decide what to do.
In 2026, this is already part of our everyday work when we design products connected to digital identity, fraud, or financial services. AI can detect anomalies, rank cases, and suggest an action, but adding a person at the end of the process doesn’t guarantee real oversight. The difference lies in something much more concrete: how we design the interface in front of them.
That’s where UX comes in. Because between an AI that works as a copilot and one that ends up working as an autopilot, there may be just a handful of design decisions.
What is a decision interface
A dashboard informs. A decision interface is a screen from which a decision with consequences gets made, and that changes everything we need to design.
If I’m looking at a panel, I can explore the information and keep browsing. But if I have a case in front of me that I need to approve, reject, or escalate, I need to understand what’s happening, which evidence is relevant, and why the system is suggesting a particular action.
And it also has to be clear who made the final decision.
In banking and financial services projects, this balance comes up constantly. Security and user experience aren’t two separate problems. From a person-centered design approach, our job is to identify what evidence someone needs to decide well and present it with the right hierarchy.
Copilot and autopilot are two different design decisions
I find it useful to think of AI as a copilot.
A good copilot organizes, summarizes, detects patterns, and flags when something deserves attention. It helps you get to what matters faster, but it doesn’t decide for you.
With an autopilot, something different happens: the system decides, and the person, at best, validates it afterward.
The difference doesn’t depend only on the technology. The same model can produce completely different experiences depending on how we design the interaction. That’s where it’s determined whether human oversight is actually effective, not in the system’s technical spec sheet.
That’s why I work through these interfaces with four questions: what is the person deciding, what do they need to see, where does it make sense to keep some friction, and what will we need to be able to reconstruct later.
To me, this is one of the important shifts in our methodology in 2026. We no longer design just the easiest path. We also design how much someone needs to think at certain moments, and what they need in order to do it with judgment.
Five design patterns that shape the decision without anyone noticing
| Pattern | What it causes | What ends up happening |
|---|---|---|
| Showing the result without showing what it’s based on | The recommendation looks like a closed conclusion | Reviewing turns into confirming |
| Making accepting always cheaper than reviewing | The easy path matches what the system proposes | We design an automatism without calling it that |
| Sorting by default and not explaining it | The first position is read as the most important | Prioritization shapes the decision |
| Repeating uncertainty until it stops being read | Alerts lose weight with use | The person stops noticing the exception |
| Removing all friction, even where it was needed | Sensitive decisions become too fast | It increases the chance of acting without reviewing |
Showing the result without showing what it’s based on
Showing “high risk” is convenient, but it can also remove human judgment from the equation.
If a person doesn’t know which signals led the system to that conclusion, they have no grounds to argue with it. They can accept or reject, but that doesn’t mean they’re deciding with real judgment.
That’s why advanced analytics needs to help people understand what’s happening, not just display a final score. From a UX standpoint, explaining isn’t about filling the screen with data. It’s about choosing the relevant evidence and building a hierarchy that lets someone move from a quick read to the details when needed.
Making accepting always cheaper than reviewing
This pattern worries me in particular.
If accepting a recommendation costs one click, and reviewing it means opening another view, checking several tabs, and coming back, there’s technically human oversight. In practice, we’ve designed the path so the person accepts.
Information architecture, button placement, the number of steps, and even the language we use also shape a decision.
If we want a person to be able to challenge the system, reviewing has to be a real possibility, not just a technical one.
Sorting by default and not explaining it
Prioritizing is also deciding.
When a system places certain cases at the top of a list, it’s already influencing where attention goes. In automatically prioritized systems, this can be essential when working with large volumes, but we need to make that prioritization visible.
Is that case first because it’s more urgent, carries higher risk, shows an anomaly, or is simply more recent?
If we don’t explain the criteria, the person may read the system’s order as if it were objective.
Repeating uncertainty until it stops being read
An alert can be well designed and still stop working.
Because we’re not designing for a screenshot. We’re designing for people who will see that interface over and over.
If someone encounters the same indicator dozens of times a day, at some point it loses its force. Adding more red, more icons, or more warnings rarely solves the problem.
In UX, we also design attention: we group what’s repetitive and reserve certain visual resources for whatever truly needs to break the usual pattern.
Removing all friction, even where it was needed
For years we’ve talked about reducing friction almost as a universal UX principle. And it makes sense. In many user onboarding flows, every unnecessary step can increase drop-off.
But friction isn’t always bad.
In a sensitive or hard-to-reverse decision, an extra step can serve a purpose. Asking someone to review a piece of evidence, requesting a reason before rejecting, or separating two actions with very different consequences can be a deliberate design decision.
To me, that’s deliberate friction.
A good experience isn’t always the one with the fewest steps. It’s the one that introduces the right amount of effort at the right moment.
What a person needs in order to evaluate a recommendation
When I design these screens, I ask myself a simple question: if the person disagrees with the AI, do they have enough information to explain why?
This is explainability by design, not by model.
For the answer to be yes, they typically need to see:
- The recommendation, presented as a recommendation and not as a closed truth.
- The main signals or evidence behind it.
- An understandable way to grasp confidence or uncertainty.
- Enough context to connect it to the case history or to real identity fraud cases.
- Clear actions to accept, reject, escalate, or keep investigating.
We don’t need to explain how the model works internally. We need to give them arguments.
There’s an important difference between showing more information and showing the information that lets someone build judgment.
Volume, repetition, and cognitive load
This is one of the points that interests me most from a UX standpoint, because we don’t design only for the first decision. We also have to think about what happens with the hundredth decision of the day.
It’s not our exact context, but it illustrates the problem well: as volume grows, attention becomes a design resource.
Repetition breeds automatism. Familiar patterns get read faster, and small differences can go unnoticed.
AI can contribute a lot here: summarizing, grouping, detecting anomalies, and reducing noise. But the interface still has to protect whatever we don’t want to become invisible.
It’s not enough to ask whether a screen is clear. We have to ask whether it will still be clear after several hours of use.
Designing the record of the decision, not just the decision
There’s another part of design that happens after the click.
If months later someone needs to understand why a particular decision was made, knowing that a case was “approved” or “rejected” isn’t always enough.
If we need to review that decision later, we also need to be able to reconstruct what information the person had in front of them, what recommendation they received, what evidence they could consult, and what alternatives they had.
We design so that someone can decide today, but also so that later reviews can understand tomorrow the context in which that decision was made.
Checklist for reviewing a decision interface
When we review one of these interfaces, here are some of the questions I find useful to ask:
- Can the person see what the suggestion is based on before accepting it?
- Is the difference between the system’s recommendation and the final decision clear?
- Do we show uncertainty in an understandable way?
- Does disagreeing or reviewing come at a reasonable cost compared to accepting?
- Does the person understand why cases appear in that order?
- Do we clearly distinguish what’s urgent, anomalous, and recent?
- Did we keep deliberate friction in the decisions that truly need it?
- Can the person add context when they disagree?
- Do we evaluate the interface with repeated use in mind too?
- Can we reconstruct later what the person saw and what options they had?
For me, adopting AI in 2026 isn’t just about asking what to automate. The more interesting design question is different: what can we delegate to the system to reduce workload without also delegating judgment.
A good copilot gets you to what matters faster. It reduces noise, organizes information, and flags when something looks off. But it leaves one fundamental thing in your hands: looking at the evidence, understanding it, and deciding.
The day no one is looking at that screen anymore and the system acts on its own, we’re no longer talking about a decision interface.
These are the same questions we bring to our work at Facephi when we design experiences for regulated industries, aiming for that balance between security, friction, and human judgment.
Frequently asked questions
It’s the screen where a person receives what a system has prioritized and chooses what to do. Unlike a panel, it doesn’t just inform: it supports an action with consequences and leaves a record of who made it.
The copilot organizes, summarizes, and proposes, and the person resolves it. The autopilot resolves and notifies. The difference isn’t in the model, but in what information the interface puts in front of whoever makes the decision.
That the person can understand the proposal, weigh it against the evidence, and make a different decision if they think it’s warranted. If the person can’t do any of these things, someone is clicking, but not necessarily supervising.
Because the interface often makes accepting easier than any alternative. High volume, insufficient information, and an acceptance path shorter than the review path can produce automatism even when, in theory, oversight exists.
When the cost of getting it wrong is high or the action is hard to reverse. One more step isn’t necessarily a usability problem: it can be a way to give a sensitive decision the attention it needs.
By saving what was shown, in what order, and with what options, not just what was chosen. A later review needs to be able to reconstruct the context the person had in front of them when they made the decision.
