All work

Enterprise tool · 2024—2025

An internal tool 200+ people actually want to open

End-to-end design of Whatfix's quality-control and activity-tracking dashboard — plus the full component library that keeps every new screen consistent.

Role

Product Designer — end-to-end, incl. design system

Timeline

2024–2025 · ongoing

Team

1 designer · internal engineering · ops stakeholders

Platform

Internal web app

Tools

FigmaFigma variablesFigJamJira
Visit live ↗

200+

Daily employees on the tool

1

Component library powering every screen

Live

In production at Whatfix

01 · Overview

Whatfix's delivery assurance team tracks quality-control checks and team activity across hundreds of engagements. Before DAC, that meant spreadsheets: manual roll-ups, stale numbers, and managers spending review meetings reconstructing reality instead of acting on it.

I designed the dashboard end to end — information architecture, every workflow, the visual system — and built the component library alongside it so the tool could grow without me becoming its bottleneck.

02 · The Problem

What we were trying to solve

Quality data existed but couldn't be acted on: scattered across sheets, aggregated by hand, and outdated by the time it reached a review meeting. Internal tools were also built screen-by-screen with no shared system — every addition drifted further from the last.

Pain point 01

Insight arrived too late

Manual roll-ups meant QC trends surfaced weeks after the fact — managers audited history instead of steering work.

Pain point 02

Every team saw a different truth

Parallel spreadsheets produced conflicting numbers, and meetings burned time reconciling them instead of deciding.

Pain point 03

No system underneath

Internal tools accreted inconsistent patterns — each new screen was designed from scratch and looked like it.

03 · Research

What the users taught us

I shadowed QC reviewers and team managers through their weekly routines, mapped the data lifecycle from check to report, and inventoried the inconsistencies across existing internal screens.

Insight 01

Three altitudes, one tool

Reviewers work item-by-item, leads scan team health, managers need trends — the IA had to serve all three without three separate products.

Insight 02

Data entry is the adoption gate

If logging a check took longer than the spreadsheet, nothing else mattered — capture had to be faster than the status quo.

Insight 03

Consistency is a speed feature

Familiar patterns across screens meant zero retraining per release — the design system wasn't polish, it was adoption insurance.

04 · Design Process

From tangled problem to shipped solution

  1. Stage 1Problem Identified

    The spreadsheet was the symptom

    Shadowing showed the real cost wasn't the sheets themselves but the latency they created — decisions made on stale data, meetings spent reconciling numbers. The problem was framed as time-to-insight, not tooling.

  2. Stage 2Problem Scoping

    Dashboard and design system, scoped together

    I deliberately scoped the component library into v1 rather than 'after launch' — every screen designed once, componentised immediately, so consistency was structural instead of aspirational.

    • Three user altitudes prioritised: reviewer, lead, manager
    • Token and component foundations agreed with engineering upfront
  3. Stage 3Solution Shaping

    From data model to screens

    IA and wireframes were built around the QC data lifecycle: fast capture for reviewers, live team views for leads, trend dashboards for managers. Components — tables, filters, status chips, metric cards — were designed as variants from day one.

  4. Stage 4Impact Testing

    Piloted inside the real routine

    A pilot group ran their actual weekly QC cycle on the tool. Capture flows were trimmed until logging beat the spreadsheet on time; dashboard views were reworked around the questions managers actually asked in reviews.

    • Capture speed benchmarked against the spreadsheet
    • Dashboard views iterated on live review meetings
  5. Stage 5Solution Deployed

    Production, and a system that keeps shipping

    DAC went live for 200+ daily users, and the component library became the shared language between design and engineering — new features now ship consistent by default.

05 · The Solution

The decisions that shaped it

DAC gives every altitude its view of the same live truth — reviewers capture fast, leads see team health at a glance, managers watch trends move — all built from one component library.

Decision 01

Capture faster than the spreadsheet

Logging a QC check is a focused, keyboard-friendly flow with smart defaults — beating the old workflow on speed is what made 200+ people switch and stay.

Decision 02

Role-based views on live data

Item queues for reviewers, team-health boards for leads, trend dashboards for managers — the same data at three altitudes, so review meetings act on numbers instead of reconciling them.

Decision 03

A full component library

Tokens, tables, filters, chips, metric cards and empty states as documented Figma variants mapped to build — every new screen assembles from parts instead of starting over.

Decision 04

Status you can read across a room

A strict colour and chip system for QC states means a wall of items scans in seconds — the visual language does the triage.

06 · Impact

What changed

DAC is live in production at Whatfix — one of the projects behind a Spot Award given to 10 people out of 900+.

200+

Employees using it daily

Live

In production, actively extended

1 of 10

Spot Award from 900+ employees

  • Replaced the spreadsheet workflow: QC data is captured at the source and readable live, ending manual roll-ups.
  • Review meetings shifted from reconciling numbers to acting on them.
  • The component library keeps every new feature consistent without per-screen design involvement.
  • Recognised with a Whatfix Spot Award — 1 of 10 across 900+ employees.

07 · Learnings

What I'm taking with me

  1. 01

    Internal users are the harshest adoption test — with no marketing to lean on, the tool wins only by beating the old workflow on speed.

  2. 02

    Shipping the design system with v1, not after it, is what kept a fast-growing tool coherent.

  3. 03

    Dashboards succeed when they're designed around the questions people ask in meetings, not the data that happens to exist.