Enterprise HRMS · Searce8 min read · 10 chapters

Fixing hiring workflows at scale.

A B2B HRMS for mid-to-large organisations. I designed the systems behind hiring operations and org-wide decision visibility.

ROLE
Lead UX Designer, Searce
USED BY
Employees, recruiters, managers, HR leadership
WHAT I DID
Research, IA, flows, interaction design, design system, usability testing
TIMELINE
2024–25
Play the problem
Role-adaptive HR dashboard: hiring KPIs, recruitment funnel, applicants by source and department, a critical alert and pending tasks

  • 50–70%

    fewer duplicate candidates

  • 60–70%

    faster shortlisting

  • 10+ hrs

    saved per hiring cycle on coordination

  • ~40%

    faster task completion

Shipped alongside a backend re-architecture and recruiter training. Design was one lever, not the only one.

The case in 30 seconds

PROBLEM

Candidates came in from six sources, and nobody owned the record.

  • 6 sources
  • 0 owners

INSIGHT

It wasn’t a sourcing problem. It was data ownership.

  • Sourcing ✗
  • Ownership ✓

WHAT I BUILT

One Resume Bank, a tracked lifecycle, then role-adaptive dashboards.

  • Resume Bank
  • Lifecycle
  • Dashboards

IMPACT

Fewer duplicates, faster shortlisting, hours back every hiring cycle.

  • −50–70% dupes
  • +60–70% speed

Hiring workflows were breaking at scale.

Candidate data was scattered across systems, with no ownership or continuity.

WHAT THE CLIENT SAID

“Hiring workflows feel inefficient and hard to manage.”

“We’re handling candidates from multiple sources but losing track of them.”

“There’s too much confusion across teams.”

WHAT WE OBSERVED

Fragmented flows from multiple entry points: IJP, agencies, portals, walk-ins.

Candidates appearing across systems with no unified view.

No clarity on who owns what, at which stage.

No single source of truth for candidate data.

MAIN CHALLENGES

Multi-role complexity

Employees, recruiters, managers and HR leads, each with different data needs and workflows.

Fragmented workflows at scale

Disconnected systems turned small inefficiencies into operational delays across the org.

Visibility gap

Hiring decisions were slow and inconsistent without structured data ownership.

01 · Problem

What the system was doing to people, and what they actually needed.

Wrong assumption
  • The problem is sourcing. We need more candidates.
  • The UI is too complex. Simplify the screens.
  • Recruiters need better tools to find candidates.
Shift in thinking
  • The problem is data ownership and lifecycle clarity.
  • Candidates need one persistent identity across all sources.
  • Recruiters need visibility, not more features.

the brief said “sourcing”. the data said “ownership”.

02 · Research & insights

Centralise all candidates into a unified Resume Bank.

One candidate = one persistent profile, regardless of source. One decision that changed how we thought about the entire problem.

6 sourcesduplicates everywhere
Resume Bankone place for everyone
1 profileper candidate, for life
Resume Bank: one row per candidate with department, source, applied position, candidate name, received date, email and contact number

every source lands here. one row per person ↑

WHAT THIS MEANS

Unified profile

Every candidate from every source mapped to one record. No more duplicates.

JD match insights

Each resume compared against the job description automatically. Shortlisting gets faster.

Lifecycle tracking

Applied → Shortlisted → Interview → Hired. One shared status everyone sees.

Requisition ownership

Every candidate tied to a requisition, every requisition tied to a recruiter.

03 · Design direction

A significant engineering effort.

Backend data was fragmented across multiple tables. Centralising candidate data meant re-architecting how records were stored and linked.

TRADE-OFF

The constraint shaped the design, not blocked it.

Three decisions made it work:

  • Designed the front end first

    Built a unified candidate view as a presentation layer, without waiting for a backend rewrite.

  • Enforced ownership through UI actions

    Recruiters claimed candidates through interactions, not system-level assignments.

  • Designed for the seams

    Built explicit merge and conflict states so recruiters could resolve duplicates themselves.

the backend said no. we designed around it anyway.

04 · Constraints

How the system actually works.

What we built, why we built it that way, and what it replaced.

Resume comparison + match insights

Candidates scored against the JD. Recruiters see match %, skill gaps and a side-by-side comparison without manual effort.

match % does the first pass

Three candidates compared side by side: Leslie Alexander 96%, Savannah Nguyen 82%, Guy Hawkins 78% match, with a Select Candidate button each

Hiring lifecycle, Applied → Hired

A shared status timeline, so every team member sees the same candidate stage.

Requisitions list with a red deviation banner and a Status column showing Waiting Activation and Pending Emp Details

Stepper for tracking

A visual, step-by-step progress indicator. Each stage has an owner. Nothing moves on without a named person accountable.

every step has a name on it

Initiate Requisition form under a seven-step stepper, Initiate to Confirm Joining, with Update Details as the current step

Requisition-based ownership

Candidates are tied to an open requisition. Each requisition has a recruiter. Accountability is structural.

Shortlist Candidate screen with a requisition summary, a not-enough-resumes alert, and Suggested and Attached Resumes tables

05 · Solutioning

What worked, what didn’t, and what we learned the hard way.

First iteration

Centralisation + structure

Still slow to decide
First iteration: Resume Bank, a filterable table of candidates by department, source and position, 25 of 150 records

Why we started here

Remove duplication across sources.

Improve tracking across teams.

What didn’t work

Decision-making was still slow. Recruiters had the data but couldn’t act on it fast enough. Shortlisting still felt manual.

Second iteration

Added a decision-support layer

Faster, data-led decisions
Second iteration: three candidates compared side by side with match scores of 96%, 82% and 78% and a Select Candidate button each

Improvement

Resume comparison: two candidates side by side against the same JD.

Match insights: automated scoring right inside the shortlisting flow.

Result

Recruiter speed improved. Less back-and-forth. Decisions anchored in data, not gut feel.

06 · Iterations

Solving the data problem revealed the next one.

The data was finally centralised. The lifecycle was structured. Recruiters had clarity. But nobody could see any of it.

Dashboards were static and ineffective.

one dashboard ≠ four different jobs

The same dashboard was being shown to employees, recruiters, managers and HR heads.

Each role needed completely different signals from the same data.

  • Employee
  • Recruiter
  • Manager
  • HR head
1 static dashboard
same view for all ✗

07 · New problem

The solution came from one conversation.

One layout can’t serve everyone when every role logs in with a different intention. That realisation led to one adaptive system instead of four separate products.

Comment thread · Dashboard review

  1. Client

    The dashboard needs to be more actionable. People should see their pending tasks the moment they log in.

  2. Ankit

    That makes sense. But different people log in with completely different intentions: some to act, some to track, some to review data. One fixed layout won’t serve all of them.

  3. Client

    Fair point. Maybe we just build separate dashboards for each role then?

  4. Ankit

    We could. But that means building and maintaining four different products. What if we build one dashboard that adapts to the role, and lets each user decide what sits on it?

  5. Client

    How would that work?

  6. Ankit

    Each role gets a sensible default. Users can add or remove widgets, create multiple views to switch between, and resize widgets based on what data matters most to them.

  7. Client

    Okay, that actually solves both problems. Let’s go with that.

Second decision

Move to role-adaptive dashboards.

User-controlled views instead of fixed dashboards.

  • Recruiters see pipeline and follow-up tasks.

  • Managers see shortlists and interview schedules.

  • HR heads see org-wide hiring health and metrics.

  • Employees see their own application status.

Flexibility without fragmentation.

Dashboard Calendar view for Nov 2024 beside Critical Alerts and a My Pending Tasks panel, with a Default View menu and Add New Widget button
Multiple views per user. Switch between views without switching accounts.
Dashboard with Total Hired KPI cards and Recruitment Funnel charts (bar, donut, stacked bar, line) beside Critical Alerts and Pending Tasks
Same data, different formats. KPI cards, charts and tables, depending on the role.
Default dashboard layout showing the Calendar, Critical Alerts and My Pending Tasks panel, with a Default View menu
Role-based access. Each role gets a default that makes sense for them.

08 · Final solution

We made hiring faster, clearer and predictable at scale.

What changed for the recruiters, the managers and the org.

  • 50–70%

    fewer duplicate candidates, through a centralised Resume Bank

  • 10+ hrs

    saved per hiring cycle on recruiter coordination, by removing manual tracking and follow-ups

  • 60–70%

    faster candidate shortlisting, using comparison and match-based insights

These shipped alongside a backend re-architecture and recruiter training, so they’re not design-only numbers. All module work landed within the same 2–3 months.

What the client told us

Single source of truth

Candidate ownership became clear across every team. No more duplicate records or conflicting data.

Structured hiring workflow

Manual coordination replaced by a system-driven process. Every step tracked, every handoff accountable.

Role-based decision making

Each role gets the signals it needs. Employees, recruiters and HR heads, all served from one product.

09 · Impact

What I’m taking with me.

Centralise before you scale

Fragmented data creates fragmented workflows. Structure the foundation before adding more on top.

Constraints drive consistency

Too much flexibility breaks at org scale. The right boundaries keep every team aligned.

Find the real problem first

The obvious problem is rarely the right one. Designing the solution too early locks you in.

Ownership over features

Clear data ownership unlocks everything else. In enterprise systems, structure beats capability.

10 · Takeaways

Thanks for reading.

Want the longer version, or to talk through the trade-offs? I’m happy to walk through it.

next one: 27 screens → ~10

Next · Fundu

LENDING · SOLE DESIGNER · 2019–22

Fundu Home screen with the cash balance and things to doFundu Offers screen: you’re pre-approved, with partner loan offersFundu Games screen: spin the wheel and play a game to win points

27 screens to 10.

A consumer lending app built from zero as the only designer. Onboarding asked for everything upfront, one question per screen.

27 → ~10onboarding screens

74%application completion

Read case study