Recruitment Dashboard · Darwinbox · Prashanth Samudrala

Context

Data everywhere. Clarity nowhere.

Darwinbox captures every touchpoint in the hiring journey — applications, interviews, offers, onboarding. That data existed. The problem was what happened to it after capture. Hiring managers exported to spreadsheets. Talent leads built weekly reports by hand. Leaders asked "how is hiring going?" and nobody had a confident answer.

Insight

The data infrastructure was solid. What was broken was the layer between raw data and human decision-making. This was a design problem disguised as a reporting problem.

Discovery

Same data. Three different time lenses.

Before designing anything, I spent time with three distinct user types — each using the same underlying data for completely different decisions, on completely different timescales. That single insight reshaped the entire information architecture.

Talent Acquisition Lead

Needs pipeline health at a glance

Weekly view

Manages multiple open roles simultaneously. Primary pain: doesn't know where each role is stuck without drilling into individual records. Needs to act before candidates drop off — not after.

HR Business Partner

Needs to report upward on headcount

Monthly view

Works against a headcount plan. Primary pain: manually compiling data from multiple sources before every leadership review. Needs trend over time, not just today's snapshot.

Hiring Manager

Needs a status update on their role

Ad-hoc view

Visits occasionally, not daily. Primary pain: has to ask HR for updates rather than self-serving the information. Needs a narrow, role-specific slice — not the full org view.

Key Insight

The design problem wasn't what to show. It was building a system flexible enough that each user could find their answer without needing to understand the other users' workflows. The filter state determines the story the dashboard tells.

The Specific Problems

Four things that made hiring data hard to act on

01

No funnel-level view

Users could see individual stage counts but had no way to see the full funnel — from application through joining — in one place. Bottlenecks were invisible until candidates had already dropped out.

02

No time-in-stage data

A candidate stuck in "Interview Scheduled" for three weeks looked identical to one who moved through in two days. Without time-in-stage visibility, users couldn't distinguish an active pipeline from a stalled one.

03

No cross-department comparison

Each department's hiring was siloed. HR Business Partners couldn't compare Engineering's funnel conversion against Sales' without exporting multiple reports and manually consolidating — making cross-team benchmarking effectively impossible.

04

Metrics without context

Is a 40% application-to-screening rate good or bad? Without trend lines and baselines, raw numbers couldn't drive decisions. The data told you where you were — but nothing about whether you were getting better or worse.

Key Design Decisions

What I chose to show, what I chose to hide, and why

Every dashboard decision is a prioritisation decision. Adding a metric competes with every other metric for limited attention. Each choice below came from a specific user need — and a deliberate rejection of the alternatives.

01

Progressive disclosure — summary first, detail on demand

Show less. Surface the right layer first.

The dashboard leads with headline numbers: total active roles, total candidates, overall conversion rate, average time-to-hire. Everything else lives one click deeper. Dashboard users make better decisions when they start from a summary and drill in — not when greeted with every metric simultaneously. The density of a Power BI-style layout works against comprehension if it's not layered correctly.

02

Colour-coded stage health, not just stage counts

Turn a data display into an alert system.

Showing 210 candidates in "First Interview" is a count. Showing that stage in amber because average time-in-stage has exceeded 8 days this week is an insight. I introduced a traffic-light system per stage — green (on target), amber (slowing), red (stalled) — based on configurable time-in-stage thresholds. Problems surface before they become drop-offs.

03

Filter as primary navigation — one dashboard, three views

Serve all three user types without building three products.

Each user type needed a different slice of the same data. Rather than three separate views, I made filtering the primary navigation layer. The TA lead sets "All departments, last 7 days." The HR Business Partner sets "Engineering, this quarter." The Hiring Manager sets "My roles only." The filter state determines the story the dashboard tells — and this reduced engineering scope significantly while fully meeting all user needs.

04

Trend sparklines alongside snapshot numbers

Answer the question users always asked next.

A conversion rate of 40% at the screening stage means nothing without knowing whether it's up or down from last month. I added small trend sparklines alongside every key metric — not to add visual noise, but to answer the natural follow-up: "Is this getting better or worse?" A single number answers "where are we." A sparkline answers "where are we going."

05

Source-of-hire conversion, not just application volume

Show where to invest next — not just where candidates came from.

Hiring managers knew which job boards they posted to, but had no visibility into which sources actually produced candidates who reached later funnel stages. I added a source-of-hire panel showing not just application volume by source, but funnel conversion by source. LinkedIn converting at 8% versus Naukri at 2% — that data directly informs where to invest the next hiring budget cycle.

Before & After

What the experience looked like — and what changed

Before

~3 hrs

weekly report prep

6+

screens per pipeline check

Navigate 6+ screens to assemble a pipeline picture
Export to Excel, manually combine data, build chart
No way to see where specific candidates are stuck
No source-of-hire attribution beyond application count
Report manually prepared for each leadership review
No trend visibility — only today's snapshot

After

~20 min

weekly report prep

1

view for full picture

Full funnel visible on load — no navigation required
Filter by role, department, or time period in one click
Stage health colour-coding surfaces stalled candidates
Source-of-hire conversion tracked through all funnel stages
Dashboard shareable as a live link for leadership reviews
Sparkline trends alongside every key metric

User Feedback

What changed for the people using it

"Before this, I used to dread the Monday morning hiring check-in. I'd spend Sunday night pulling numbers. Now I just open the dashboard five minutes before the call."

Talent Acquisition Lead, mid-size tech company on Darwinbox

"The stage health colours are the thing I use most. I can see in ten seconds that Engineering's first-interview stage is in amber and act on it before it becomes a problem."

HR Business Partner, enterprise client

Impact

What the dashboard made possible

Impact across three lanes

User Impact

~3 hrs → ~20 min weekly report prep for TA leads
Hiring managers self-serve status without HR involvement
Leadership reviews use live dashboard, not static decks

Product Impact

First end-to-end funnel view in Darwinbox recruitment module
Source-of-hire attribution through full funnel — new capability
Dashboard became a key differentiator in enterprise sales demos

Design System

Data visualisation patterns reused across product
Filter system adopted as standard by 3 other Darwinbox modules
Figma component library extended with chart and KPI card components

Reflection

What designing this taught me about data-heavy interfaces

The hardest design problem in a data-heavy dashboard isn't adding features — it's deciding what not to show. At every review session, stakeholders would suggest another metric to add. All valid questions. But each addition competes with every other addition for a user's limited attention.

The framing that changed every conversation

"Yes — let's first understand which user needs that, how often, and whether it belongs in the primary view or in a drill-down." That question shifted every conversation from feature addition to prioritisation — which is the right conversation to be having.

The other thing I'd do differently: involve engineering earlier in the filter architecture. The flexible multi-dimensional filtering I designed required a non-trivial backend query structure that we discovered mid-development. Building that conversation in at the design stage would have prevented two weeks of rework.

What this case study is really about

Designing for data isn't about making charts beautiful. It's about understanding the decisions your users need to make, and then building the shortest possible path between the data and those decisions. A TA lead asking "where is my pipeline stuck?" shouldn't have to think about query logic or report configuration to get the answer. That cognitive work is the designer's job — done once, in the system — so it doesn't have to be repeated by every user, every Monday morning.