Case 01 · FYNDNA · Product Design

Manual document verification has never been easier

A fraud & document-risk module with an 8-step decision flow inherited from an unrelated feature, and the case for collapsing it into one.

Work overview

Team & Timeline

  • Lead Designer (solo IC)
  • Mar 2026 – Apr 2026

Disciplines

  • Product Design
  • Interaction Design
  • Design Systems
  • Cross-team Facilitation

Responsibilities

  • End-to-end Flow Design
  • Stakeholder Alignment Across Teams
  • Fraud & Risk Decision Flows
  • Working Within an Inherited Design System

My impact

I led the product from an open-ended UX brief to a production-ready experience, aligning product, engineering, and leadership.

Iterative Decision-making Design System Integration Stakeholder Alignment Interaction Simplification Scalable UX Reduced Task Completion Time by 12% 10% Better Risk Identification

Understanding the brief

Context

You apply for a loan at a bank. Your creditworthiness is measured by a third-party Credit Information Company. This module is where their agents work. Every document in an application carries risks, and an agent decides, document by document, whether the application can move forward.

Some risks could look like:

Decisions they take can look like:

Who are the users?

Third-party agency verifiers External agencies who specifically verify a customer's Credit Information Company (CIC/CIBIL) records on the bank's behalf.
Loan Underwriters & Credit Officers The primary users pulling CIC/CIBIL data, matching it against the bank's risk policies to decide loan eligibility and interest rates.
Fraud Risk Analysts & Managers A specialised risk team monitoring credit reports to catch application fraud, identity theft and compromised profiles before credit is extended.
Relationship Managers & Branch Staff Front-line staff who pull a preliminary credit report, with consent, to surface pre-approved offers during a branch visit.

Here's what I was told

"There's an existing flow similar to this, just finish it off."

This was my response

That flow is built for flexibility: comparing a document against a dashboard, another module, any section. That's valuable when comparison is optional and open-ended. It's not when the task is fixed and repeated hundreds of times a day.

Here's the "existing" flow

Eight steps to close one risk

I walked the inherited flow end to end, step by step, to see exactly where it broke down.

Walkthrough of the inherited flow, step by step

1

Click flag to see risks

  • Tough entry point, low familiarity: users have to be trained just to get started.
2

Risk categories in overlay

  • A list of risk codes and descriptions demands high recall: every risk has to be read to understand the task.
3

Risks shown, no document visible

  • The risk list is for a document the user can't see, so it has to be opened separately, side by side.
4

Open document to compare

  • Viewing the document is a second, undiscoverable click. Comparison only becomes possible after.
5

Take action

  • Only now can the actual decision, cure or not, happen. Four steps of setup before any real work.
6

Comments in overlay

  • An overlay covers the data just as evidence is needed. The train of thought breaks.
7

Submit, resolve next risk

  • Comments end up written from memory, not from the source.
8

That was exhausting

  • Eight steps to resolve a single risk. Multiply by 3–4 risks, across 9–10 documents, a day.

1

risk resolved, after all eight steps

9–10

documents handled by one agent, per day

3–4

risks to resolve, per document

At that scale, the cost wasn't just frustration: slower turnaround meant compliance risk on time-bound applications, and repetitive, exhausting work drove exactly the kind of agent attrition the team was trying to avoid.

I still had many questions

What I needed answered before designing

Is cure / not cure a primary action they take? If these users have a high learning curve, they can make mistakes: how is that identified? Are they the final decision makers? Does the loan application end here? Will these users get tutorials before using the 8-step flow? There are different types of documents: does the backend track that? How are the types of risks added? Do users know what each one is for? How important is the risk code? What are the first five things this user is looking for?

+439,847 (very long meetings, indeed)

...And made my version in parallel

Design dilemmas

Here's how I evaluated each iteration and the trade-offs that led to the final direction.

Dilemma 1

Overlay, or a separate page?

Risk Panel as a slide-out overlay on top of the Risk Decisioning dashboard V/S Risk Decisioning as its own dedicated page with document viewer and risks panel
  • Idea: I was told to replicate the overlay flow already used in another module, to keep things consistent.
  • Why the overlay failed:
    • The overlay was built for open-ended comparison, not a fixed, repeated decision.
    • It turned resolving one risk into eight exhausting steps, for agents handling many documents a day.
    • This platform is for users who have to make the correct call on paperwork, since that decision feeds into a longer process with many decisions after it.
  • Learning: Consistency is important, but not at the cost of the user's experience on the platform.

Dilemma 2

Cured vs. no action taken, as states

Board of card layout variants exploring visual hierarchy across risk types and states
  • Idea: Played with different visual hierarchies and alignments while coordinating with other teams, to understand which information mattered the most.
  • Design constraints:
    • I spoke to all the teams, and they agreed that Cure, Cannot Cure and Verify all carry equal priority.
    • The user can take whichever action fits, depending on what the risk or document states.

    The card that won: It led with the key information first and revealed actions progressively on hover, so the user wasn't overwhelmed by repetitive buttons on every card and could gauge the risk before deciding what to do.

  • Learning: Iteration only pays off with regular feedback: it's what let me prioritize the right changes, understand what the user needed contextually, and build a better sense of both the user and the system.

Dilemma 3

Document type, or risk type, on the dashboard?

Dashboard risk widgets segregated by document type, data, and cross-validation, plus a Document Verification table entry point
  • Idea: Give the user enough on the dashboard, through widgets, to understand what they were walking into before opening a specific risk. That meant deciding whether to segregate by document type or by risk type, and prioritizing that with input from other teams.
  • What worked:
    • The final version shows different filters on top, the risks under each document, and a status indicating whether a risk is cured or pending.
    • This design supports accessible navigation while making it easier for users to locate and refine filter selections with minimal cognitive effort.
    Final Risk Analysis design with filters on top, risks grouped under each document, and a status pill showing cured or pending

Closing thoughts

Building the wrong version first was deliberate. When the flawed flow is on screen, you don't have to argue against it: it argues against itself.

Eight steps didn't become one because the interface got cleaner. They collapsed because the problem got reframed.

That reframe, aligning three teams with conflicting inputs behind a single direction, was the actual work. It's the part I'm proudest of, even though it doesn't screenshot well.