In banking and other regulated environments, many fraud or compliance decisions ultimately pass through a screen. How we design that interface can make the difference between an effective human review and just another procedural step in the process.
A decision interface is a screen where a person receives information that a system has already prioritized, interpreted, or summarized and, based on that information, has to decide what to do.
In 2026, this is already part of our day-to-day work when designing products related to digital identity, fraud, or financial environments. AI can detect anomalies, prioritize cases, and suggest an action, but simply adding a person at the end of the process does not guarantee meaningful 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 the difference between AI that works as a copilot and AI that ends up functioning as an autopilot can come down to just a few design decisions.
What Is a Decision Interface?
A dashboard provides information. A decision interface is a screen from which a consequential decision is made, and that completely changes what we need to design.
If I’m looking at a dashboard, I can explore the information and keep navigating. But if I’m looking at a case 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 needs to be clear who made the final decision.
In banking and financial services projects, this balance comes up all the time. An analyst reviewing an alert about a potential mule account, or deciding whether to escalate an identity impersonation case, faces exactly this situation. Security and user experience are not two separate problems. From a human-centered design perspective, our job is to identify what evidence someone needs to make the right decision and present it with the appropriate hierarchy.
In practice, this translates into different views for each stage of the decision: a summary view for quick prioritization and a detailed view with the full evidence before approving, rejecting, or escalating a case. When that information is available at the right moment, the fraud or compliance team can make more informed decisions in less time. That’s where a good interface turns into an operational workflow that is faster and easier to defend in an audit.
Copilot and Autopilot: Two Ways to Design the Decision
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 make the decision for you.
With an autopilot, something different happens: the system makes the decision and the person, at best, validates it afterward.
The difference doesn’t depend solely on the technology. The same model can create completely different experiences depending on how we design the interaction. That’s where we determine whether human oversight is truly effective—not in the system’s technical specifications.
That’s why I approach these interfaces with four questions: What is the person deciding? What do they need to see? Where is it worth maintaining some friction? And what will we need to be able to reconstruct afterward?
For me, this is one of the important shifts in our methodology in 2026. We’re no longer designing just for the easiest path. We’re also designing for how much someone needs to think at certain moments and what they need to make a sound, informed decision.
Five Design Patterns That Shape Decisions Without Us Realizing It
| Pattern | What it triggers | What ends up happening |
|---|---|---|
| Showing the output without showing what it’s based on | The recommendation reads as a closed conclusion | Reviewing turns into rubber-stamping |
| Making acceptance always easier than review | The easy path matches what the system proposes | We end up designing automation without calling it that |
| Sorting by default without explaining why | The top position is read as the most important | Prioritization shapes the decision |
| Repeating the same alert until it stops being read | Alerts lose weight with repeated use | People stop noticing what’s actually exceptional |
| Removing all friction, even where it was needed | Sensitive decisions happen too fast | The risk of acting without review increases |
Showing the Outcome Without Showing What It’s Based On
Showing “high risk” is convenient, but it can also remove human judgment.
If a person doesn’t know which signals led the system to that conclusion, they have no basis to challenge it. They can accept or reject it, but that doesn’t mean they are making an informed decision.
That’s why advanced analytics needs to help people understand what is happening, rather than simply displaying a final score. From a UX perspective, explaining doesn’t mean filling the screen with data. It means selecting the relevant evidence and creating a hierarchy that allows people to move from a quick overview to the details when needed.
The Risk of Accepting Without Reviewing
This pattern concerns me especially.
If accepting a recommendation takes one click, while reviewing it means opening another view, checking several tabs, and going back, then technically there is human oversight. In practice, we’ve designed the path to encourage the person to accept.
Information architecture, button placement, the number of steps, and even the language we use can all influence a decision.
If we want people to be able to challenge the system, reviewing needs to be a real possibility—not just a technical one.
Sorting by Default Without Explaining It
Prioritizing is also a form of decision-making.
When a system places certain cases at the top of a list, it already influences where attention is focused. In systems that automatically prioritize cases, this can be essential when working with large volumes, but we need to make that prioritization visible.
Is that case at the top because it is more urgent, carries a higher risk, shows an anomaly, or is simply more recent?
If we don’t explain the criteria, people may interpret the order suggested by the system as objective.
When the Alert Keeps Repeating Until We Stop Reading It
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 again.
If someone encounters the same indicator dozens of times a day, there comes a point when it loses its impact. Adding more red, more icons, or more warnings rarely solves the problem.
In UX, we also design for attention: we group repetitive elements together and reserve certain visual cues for what genuinely needs to break the usual pattern.
Removing All Friction, Even Where It Was Necessary
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 decision or one that is difficult to reverse, an extra step can serve a purpose. Asking someone to review the evidence, requiring a reason before rejecting a case, or separating two actions with very different consequences can all be conscious design decisions.
For 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 Does a Person Need 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 through design, not through the model itself.
For the answer to be yes, they typically need to see:
- The recommendation, presented as a recommendation rather than as a definitive truth.
- The main signals or pieces of evidence that explain it.
- An understandable way to assess confidence or uncertainty.
- Enough context to relate it to the case history or to real-world cases of identity fraud.
- Clear actions to accept, reject, escalate, or continue investigating.
We don’t need to explain how the model works under the hood. We need to give people the arguments they need to make a decision.
There’s an important difference between showing more information and showing the information that enables someone to build sound judgment.
Volume, Repetition, and Cognitive Load
This is one of the points I find most interesting from a UX perspective, because we’re not designing just for the first decision. We also have to think about what happens on decision number one hundred of the day.
It’s not exactly our context, but it illustrates the problem well: as volume increases, attention becomes a design resource.
Repetition creates automatic responses. Familiar patterns are read more quickly, and small differences can easily go unnoticed.
That’s where AI can add a lot of value: summarizing, grouping, detecting anomalies, and reducing noise. But the interface still needs to protect what we don’t want to become invisible.
It’s not enough to ask ourselves whether a screen is clear. We also have to ask whether it will remain clear after several hours of use.
Designing the Decision Record, 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 review, and what alternatives they had.
That’s why traceability is also part of UX.
We design so that someone can make a decision today, but also so that subsequent reviews can understand tomorrow the context in which that decision was made.
Checklist for Reviewing a Decision Interface
When reviewing one of these interfaces, here are some of the questions I find useful to ask ourselves:
- ☐ 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 carry a reasonable cost compared to accepting?
- ☐ Does the person understand why those cases, fraud alerts, and KYC reviews appear in that order?
- ☐ Do we clearly distinguish what’s urgent, what’s anomalous, and what’s recent?
- ☐ Did we keep deliberate friction in the decisions that actually need it?
- ☐ Can the person add context when they disagree?
- ☐ Do we evaluate the interface with repeated use in mind too?
- ☐ Can we later reconstruct what the person saw and what options they had?
For me, incorporating AI in 2026 isn’t just about asking what we can automate. The more interesting question from a design perspective is this: what can we delegate to the system to reduce the workload without also delegating human judgment?
A good copilot helps you get to what matters faster. It reduces noise, organizes information, and alerts you when it detects something unusual. But it leaves something fundamental in your hands: reviewing the evidence, understanding it, and making the decision.
The moment 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 environments, seeking the right balance between security, friction, and human judgment.
Es la pantalla donde una persona recibe lo que un sistema priorizó y elige qué hacer. A diferencia de un panel, no solo informa: sostiene una acción con consecuencias y deja constancia de quién la tomó.
El copiloto ordena, resume y propone, y la persona resuelve. El autopiloto resuelve y notifica. La diferencia no está en el modelo, sino en qué información pone la interfaz delante de quien toma la decisión.
Que la persona pueda entender la propuesta, contrastarla con la evidencia y tomar una decisión distinta si considera que corresponde. Si la persona no puede hacer alguna de estas cosas, hay alguien haciendo clic, pero no necesariamente supervisando.
Porque muchas veces la interfaz hace que aceptar sea más fácil que cualquier alternativa. Volumen alto, información insuficiente y una ruta de aceptación más corta que la de revisión pueden generar automatismo aunque, en teoría, exista supervisión.
Cuando el costo de equivocarse es alto o la acción es difícil de revertir. Un paso más no necesariamente es un problema de usabilidad: puede ser la forma de darle a una decisión sensible la atención que necesita.
Guardando qué se mostró, en qué orden y con qué opciones, no solo qué se eligió. Una revisión posterior necesita poder reconstruir el contexto que tenía delante quien tomó la decisión.
