Redesigning the tool hundreds of employees use every day.

Search was one-size-fits-all. Every session began with the same manual filter reconfiguration — before any real work could start. Operations Executives, Account Managers, and Team Leads each needed completely different result views, yet the tool served them identically. A repeating tax on every user, every day, before they could even begin their actual task.

Education verification required verifiers to juggle two completely separate contexts. The candidate's data — institution name, dates, degree title — lived on one screen. The supporting documents — scanned certificates, transcripts, mark sheets — lived on a different portal entirely. Verifiers had to open the verification details, navigate away to the document portal, memorise what they saw, return to ODIN, and manually compare from memory. This context-switching wasn't just slow — it increased verification errors. Working from memory while comparing details is a reliable way to miss discrepancies. On top of this, uploaded documents frequently arrived as rotated scans or poorly cropped images. Without any built-in document tools, verifiers downloaded files, opened them externally, and worked entirely outside ODIN to correct orientation before they could even begin verifying.

A high-stakes, irreversible confirm/reject decision was shown inside the full cluttered interface. Navigation, filters, and background list items competed for attention at the worst possible moment. Users had also normalized using Ctrl+F — the browser's native find tool — to search within the criminal case list. A broken workaround no one had flagged until we watched them work.

Verifying whether a candidate had provided required documents meant opening the request, navigating to a separate candidate portal, reviewing their uploads, then returning to ODIN to mark it sufficient or insufficient. 11 clicks across two portals — for a task performed dozens of times per day.

Every possible action for a request was displayed in each table row — maximum visibility, but extreme visual noise. Hard to scan, easy to misclick, and consuming disproportionate screen space. With hundreds of requests on screen, the cumulative cognitive load was significant.

The hamburger menu hid navigation by default. Every time a user needed to switch sections — a constant requirement in an operational tool — they had to open the menu first. A small tax per interaction that compounded across hundreds of daily navigations into a meaningful productivity drain.

Request states were displayed as plain text labels with no visual differentiation. In a workflow where operations staff handle hundreds of requests simultaneously, manually reading and interpreting every status label was slow and mentally exhausting. The lack of visual hierarchy also made it harder to identify what action was needed next — and which requests were blocked, pending, or complete.

Workflow status updates were communicated through frequent modal pop-ups triggered by almost every action — request creation, assignment, status updates, verifier responses. While informative, these interruptions demanded acknowledgment before work could continue. For an ops team performing dozens of actions per hour, the cumulative disruption to task flow was significant.

Three actions — Add Note, Data Suggestion, and Bug Reporting — were used repeatedly throughout every operational session. All three were buried inside secondary menus, requiring users to navigate away from their current task every time. Research revealed these weren't occasional utilities — they were core parts of the daily workflow, used multiple times per hour by every ops team member.