Making 100+ fraud and compliance tests findable

Two founders with 20 to 30 years each in law and finance built a platform that audits business transactions automatically. Every transaction passes through more than 100 tests: compliance checks, audit checks, fraud checks, and cross-references of suppliers and vendors against directories of flagged parties. Engineers and finance professionals built the first version. It was powerful and it had almost no UX.

The founders came to us with a complaint: users were not finding half of the tests, and half of the features were going unused. Our audit showed why.

• Four layers of navigation. A horizontal menu, a vertical menu, tabs inside each of those, and dropdowns inside each tab.

• Dashboards inside dashboards. A single transaction had several dashboards, and each had its own sub-dashboards.

• Results hidden in many places. Seeing the test results for one transaction meant going through transaction history or through many other routes.

• No self-serve onboarding. Staff onboarded every user by hand, with a one to two hour walkthrough. That could not scale.

The users were accountants, finance professionals and forensic analysts from large advisory firms: strong domain experts, not technical people.

Business goal, set in workshops with the founders: onboard more customers, and make the product understandable to non-technical finance users without a walkthrough.

I took the first call with the founders and ran the objective-setting workshops. I led the audit, the research plan and the information architecture direction, and I presented the brand directions. The team had a UX designer, a UX researcher, a UI designer and a brand designer.

• A live product with long-standing customers, so it could not be rebuilt from scratch.

• 100+ tests that all had to remain reachable.

• Data-dense screens used by people reading numbers all day.

• Users with deep domain knowledge and low tolerance for technical tools.

• Audit. One month going through the whole application and mapping every navigation layer.

• Interviews. 30+ across subject-matter experts (forensic analysts, accountants, fraud analysts), the client's employees, the founders and customers who had used the platform for years.

1. 1

   Experts knew how to find fraud, but not where the platform kept the test. Half of the people we spoke to could explain their process in detail and still could not locate the matching test.

2. 2

   Support was answering the same question again and again. Employees reported many calls from users who could not find features that already existed, buried in the master navigation.

3. 3

   The founders' real risk was the value proposition. A platform that turns four months of work into four hours loses that value if users cannot see the features that do it.

The hardest call was the entry point. Four candidates: start from a transaction, a profile, a test, or alerts. With this many tests, every choice moved a lot of weight somewhere else.

• I chose company, then department, then transaction, with tests grouped by type (fraud, vendor and so on) inside each transaction.

• Why. Analysts review every transaction for each company, then dive into the tests when something looks suspicious. The structure follows how they already work.

• Rejected, test-first. It would group transactions under each test and repeat the same transaction many times.

• Rejected, profile-first. One profile can span several companies, which adds extra steps.

• Rejected, alerts-first. Analysts need to review all transactions, not only the flagged ones.

• The disagreement. The founders wanted alerts first. I pushed back because alerts can miss fraudulent transactions and can raise false flags, so relying on them as the entry point was risky. We kept alerts on the dashboard instead, as a shortcut and not the starting point.

• The trade-off. Some tests and flags were still buried deep. But the structure now matched the analysts' own process.

The new home is a snapshot of the financial health of the whole company. It shows only what matters first: suspicious and fraudulent transactions, recent transactions, top vendors and total transaction value. Alerts live on the dashboard itself instead of three levels down. Detail sits one level below.

The product had no identity, so we explored several directions around precision, accuracy, ease of use and time saved. One was Orion, one used arrows, one used a compass. The product's name suggested pointing precisely at fraud. Orion was rejected, and the founders chose the compass. I defined colours, typography, iconography, visual language and tone of voice. The type is deliberately thin and highly legible so dense data stays readable.

We ran remote sessions with users and with the client's employees who acted as our points of contact. Participants found the new navigation easier, and they could see alerts on the dashboard without searching.

We spent too long trying to satisfy every user role, and that pushed the project past its timeline. Later we learned that the primary users were forensic analysts. I should have asked the founders to name the primary user before design began, instead of following the full list they gave us.