Helping fleet managers identify suspicious transactions earlier

Introduction

Fleet managers were responsible for reviewing large volumes of card transactions while also handling routine operational work. Potentially suspicious activity could be difficult to distinguish from expected exceptions, particularly when users managed several accounts.

I led the experience design for a more focused alert and investigation workflow. My role covered problem framing, workflow design, interface decisions and collaboration with the engineers responsible for implementation.

This example contains illustrative wording. Replace it with verified project facts before publication.

The challenge

The existing transaction view was designed primarily for record keeping. It showed what had happened, but did not always help a fleet manager decide what required immediate attention.

Users needed to answer three questions quickly:

1. Is this transaction genuinely unusual?
2. What context do I need before taking action?
3. What is the safest appropriate next step?

Simply adding another warning icon would not solve the underlying problem. The workflow needed to prioritise risk without making ordinary exceptions feel alarming.

Context and constraints

The work sat inside an established platform used across multiple business accounts. Any solution had to account for:

• large, data-heavy transaction tables;
• users with access to more than one account;
• different permission levels;
• incomplete or delayed transaction information;
• existing frontend components;
• security and fraud-prevention requirements.

The interface also had to remain useful when no alert data was available or when a user lacked permission to take a particular action.

Understanding the problem

I mapped the path from an unusual transaction being detected to a fleet manager deciding whether to investigate, dismiss or escalate it.

The mapping exposed a distinction between scanning a list to decide where attention was needed and investigating one transaction in enough detail to act confidently. Trying to support both activities in the same dense table would have increased visual noise, so I treated prioritisation and investigation as connected but separate stages.

Before publication, document the real evidence used here: research, analytics, support themes, domain-specialist input or technical discovery.

Decisions and iterations

Prioritise risk without turning the table into an alert wall

One direction applied strong warning colours across entire rows. It made alerts visible, but overwhelmed the surrounding transaction information and gave several risk levels equal visual weight.

The selected direction used a restrained status treatment in the list and reserved stronger emphasis for the investigation view. This allowed the table to remain scannable while making the next action discoverable.

Keep supporting evidence close to the decision

Opening several pages to understand one transaction increased the chance that users would lose their account or filter context. The investigation view therefore brought together the transaction, card and vehicle details, merchant information, alert reason, related activity and available actions.

Design permission-limited states explicitly

Not every user could block a card or change account controls. Hiding the action made the workflow difficult to understand, while presenting an active control created false expectations. The restricted state instead explained why the action was unavailable and identified the appropriate next step.

The solution

The resulting workflow had three layers:

1. A scannable transaction list with restrained risk indicators.
2. A focused investigation view containing the evidence needed for a decision.
3. Contextual actions based on risk level and user permissions.

The design also accounted for loading, empty, resolved and restricted states, making the workflow more resilient than a design based only on its ideal state.

Collaboration and implementation

I worked with product and fraud specialists to clarify the decision the interface needed to support. Engineering collaboration helped identify which signals were reliable enough to display and which would arrive asynchronously.

Existing design-system components were reused where appropriate. New status and investigation patterns were designed so they could be adopted by related areas rather than remaining specific to one feature.

Outcomes

The intended outcome was a clearer separation between identifying possible risk and investigating it. Replace this paragraph with verified measures, usability evidence, operational feedback or an accurate qualitative account of what shipped. Do not manufacture a percentage where evidence is unavailable.

Reflection

The work reinforced that risk interfaces need carefully controlled emphasis. Making every warning visually loud can make the whole system harder to scan.

With additional evidence, I would investigate how well users understood different alert reasons and whether the workflow should adapt to repeated false positives. I would also evaluate whether resolved alerts provided enough context for later auditing.