Flagship case study

SecureID

An identity-verification platform, built from a professional UX practice brief, that has to work for two very different people on the same flow: an everyday user who just wants to prove who they are, and an internal analyst who has to review the edge cases fast.

Role: Solo UX Designer
Team: Solo project
Scope: Practice brief
Tools: Figma, FigJam, Claude

This case study is built from a self-directed UX practice brief, not a client engagement — the design problem and research are structured the same way client work would be, but "SecureID" is a practice product, not a company.

Two users, one flow

SecureID verifies identity through document capture, biometric checks, and manual case review — the step where most products break down. I treated it as two connected problems: a verification flow that had to feel calm and trustworthy, and an analyst dashboard that had to feel fast and unambiguous, both built on one shared design system.

From insight to decision

Two decisions mattered most — here's the reasoning behind each.

We learned Users dropped their guard the moment they hit a screen that felt uncertain — unclear what step they were on, or what would happen with their documents. Anxiety about making a mistake during verification was the dominant emotion in early research conversations.

So I changed I rebuilt onboarding around a persistent step indicator and plain-language status copy at every stage ("Reviewing your document now" instead of a spinner), and separated document capture from biometric confirmation into distinct, single-purpose screens instead of one dense form.

Evaluated via Usability walkthroughs of the hi-fi prototype against the original wireframes, checking specifically whether participants could state what step they were on and what happened next without being told.

"I'm afraid to make a mistake." — Riley, representative user persona developed from the practice brief

We learned Analysts don't review cases in the order they arrive — they triage by risk and age first, and a simple top-to-bottom list made that harder, not easier.

So I changed I redesigned the dashboard navigation around filterable, sortable case queues with status and priority surfaced at a glance, instead of a flat case list — and mapped a dedicated settings area (notifications, password, email preferences) so account controls stopped competing with the review workspace.

Evaluated via A self-review against the IA and the color-mapped status system (button and badge color tied one-to-one to case status) to confirm an analyst could read a queue's priority without opening a single case.

Four personas, kept honest

Four representative perspectives kept the verification flow and analyst workspace grounded: Riley needs calm, predictable guidance. Jordan values speed across devices. Casey needs fast access to the details that affect a decision. Morgan needs a clear hierarchy so nothing important gets buried.

One system, two interfaces

Instead of designing the user flow and analyst dashboard as separate products, I built both on one shared token system — a neutral base plus accent, success, and error colors in five tints each — so the same visual language reads as calm to a verifying user and fast to a scanning analyst.

Five-stop color ramps (100 → 900) for accent, positive, and negative feedback
Status color mapped consistently to meaning across every button, badge, and banner
One shared type and spacing scale across both interfaces

Outcome & impact

As a solo practice project, the goal was a defensible process end to end — not a shipped metric. What I can point to concretely:

interfaces unified on one token system

case-study sections, wireframe → hi-fi

1:1

status color mapped to meaning, zero ambiguity

The lesson I've carried into my internship work since: designing for two audiences on one flow means deciding, explicitly, which parts of the system flex per audience and which never do.