Workforce Intelligence: the full case study

Summary

The problem

In IT services, people are the product. Revenue depends on how many of them are billed to client work, and cost depends on how many are not. Three numbers decide the economics: utilization (the share of capacity that is billable), bench (people between projects), and the time it takes to staff a new client request.

In the BRD’s model, all three were drifting. Billable utilization was 82.6% against an 85% target. Bench cost ran at $1.8M a month. A new staffing request took 7–10 days to fill, often long enough for the client to look elsewhere. Resource planning lived in spreadsheets owned by individual business units, so no one could see the whole picture: who is free, who is half-free, and what demand is coming.

What the BRD gave me

The document set clear business targets and a vision of twelve modules. It was much thinner on users, workflows and edge cases. I mapped what I had before deciding how to spend ten days.

The gap shaped the brief I set myself. Rather than spreading thin across twelve modules, I would answer three questions properly. Who makes workforce decisions? Which of those decisions cost the most when they are slow? What is the smallest product that makes them faster?

Role, team and operating principles

I worked as UX AI Engineer and Product Manager. I owned problem framing, research, the design system, the prototype code and the backlog. An engineering architect reviewed architecture decisions and pull requests part-time. A delivery SME gave domain input, checked that the synthetic data behaved like a real services business, and opened doors to the managers I interviewed and tested with.

Constraints

• No real data. There was no access to HR or project systems, so everything ran on a synthetic dataset that had to be believable to people who manage workforces for a living.
• Ten working days, fixed. The point of the exercise was to show what AI-augmented discovery can do at that pace.
• A thin specification. Nine of twelve modules had one line each.

Operating principles

I set three rules on day one, because speed without rules produces confident nonsense.

1. AI drafts, a person decides. No AI output went into the product or the backlog without a named human checkpoint.
2. Stakes set autonomy. Before any AI feature reached wireframes, I ran it through my five questions: who benefits, what does a wrong answer cost, can the user understand it, can they override it, and how does it fail?
3. One source of truth. Tokens, components and data each lived in one place, so design and code could not drift apart silently. Section 13 is honest about where this rule slipped.

The 10 days

I followed my AI-augmented UX process in three phases: understand, explore and materialize. The chart compares it with a traditional discovery on the same scale.

Research and personas

I held six stakeholder conversations on day two, with portfolio, delivery and resource management leads introduced by the delivery SME. AI handled transcription and first-pass clustering. I kept a rule that every theme had to link back to at least two conversations before it counted as a finding.

What we learned

• Headcount was not the problem; visibility was. Leaders knew how many people they had. They could not see partial allocations, so a person at 40% on one project looked fully busy.
• Staffing is a negotiation, not a search. Finding candidates was quick for experienced managers. Convincing another business unit to release someone was slow, because no one could show the evidence.
• Bench age matters more than bench size. Someone on bench for a week is normal. Someone on bench for two months is a cost and a retention risk. Spreadsheets showed totals, not age.
• Forecasts were trusted only with ranges. A single demand number invited argument. A range with its drivers invited planning.
• Nobody wanted an AI that moves people. Every stakeholder welcomed suggestions. None wanted an automated reassignment.

The decision map

Before personas, I mapped decisions. For each recurring decision I asked who makes it, how often, and what a day of delay costs. This table set the priority order for the whole product.

Three decision roles

The AI’s first persona draft offered an “HR manager” and an “employee”. Neither matched the people actually making the decisions, so I rebuilt the personas around the decision each one owns.

The journey that mattered most

Filling a staffing request was the clearest example of slow decisions costing money. Mapping it showed that most of the 7–10 days was waiting, not work.

Information architecture

The AI proposed navigation in the BRD’s order, which mirrored how the document was written, not how people work. I regrouped the modules by the question each answers and ordered the sidebar by how often that question gets asked.

One filter bar for every module

Every screen shares the same global filters: business unit, practice, geography, allocation status and grade, plus a reporting period. A portfolio leader who narrows to one business unit on the overview stays narrowed when they jump to bench or forecast. This sounds small; in testing it was the difference between following a thread and starting over on every screen.

AI as a layer, not a destination

The AI Advisor has its own page, but it is also one click away in the header on every screen. AI recommendations appear inside the module where the decision is made, such as Talent Finder ranking or Planning actions, rather than only in a chat window.

Module deep dives

Seven modules carry the core decisions. For each, here is the job it does, the choices that shaped it and the trade-off I accepted.

Overview, for portfolio leaders

Lead with recoverable capacity

The BRD opened with total headcount. Research said leaders already knew it. The overview keeps the headline KPIs but pairs them with a hidden capacity panel: 6,420 partially allocated people, worth about 3,180 recoverable FTE, with projected utilization gain and bench reduction, and two actions, optimize or explore. Below it, workforce intelligence cards sort signals into critical, opportunity, utilization and AI recommendation, each with one next step.

Trade-off: a less familiar first screen, in exchange for a direct path to the decision that moves bench cost.

Talent Finder, for resource managers

Search the way managers talk

Managers describe needs in sentences: “five senior Java developers with AWS, at least 40% available within 30 days.” Talent Finder accepts that sentence, offers suggested queries for common requests, and returns a ranked list with allocation, availability date, location and a match score. The score uses a published weighting: skills 40%, availability 30%, relevant experience 20%, team fit 10%. Scores are colour-banded, and the band is always paired with the number, never colour alone.

Trade-off: publishing the scoring logic invites managers to argue with it. That is the point. A shortlist someone can challenge is one they can defend in a release negotiation.

Bench Management, for resource managers

Show age, not just size

Bench is broken into four age bands, 0–15, 16–30, 31–60 and 60+ days, each with a count and share. A business unit table shows the same bands with estimated monthly cost and the number of AI-suggested matches. The 92 people past 60 days get their own alert and a prioritize action, because that group carries the highest cost and retention risk. The employee list is sorted by days on bench, so the longest waits are always at the top.

Trade-off: leading with age makes some units look worse than a simple total would. Stakeholders agreed it was the honest view.

Demand Forecast, for delivery heads

Ranges, drivers and where it breaks

The forecast shows supply against committed and forecast demand over six months, with a confidence band around the forecast line. Four callouts name the moments that need action: excess capacity, demand surge, projected shortage and peak demand. A drivers row breaks demand into new projects, extensions, roll-offs, account growth and seasonal demand, so a delivery head can see why the number moves, not just that it moves.

Trade-off: a confidence band makes the forecast look less certain. Research showed that was exactly what made people trust it.

Workforce Planning, for delivery heads

Scenarios before recommendations

Planning opens with three scenarios side by side, base, growth and conservative, each with required headcount and gap. The base case gap is broken down by quarter into hire, upskill and redeploy. Recommended actions follow, each tagged by type and labelled as AI-generated from the selected scenario, with a combined impact on utilization, bench, demand coverage and cost.

Trade-off: showing three scenarios adds reading time. It stops the AI recommendation from being mistaken for the only option.

AI Workforce Advisor, for everyone

Recommends, never acts

The Advisor answers questions about capacity, skills, staffing gaps and utilization. Nine suggested questions teach new users what it is good at before they type. Two status chips show that it runs on live data and how many employee records it can see, so users know what an answer rests on. When it proposes an action, the action opens the relevant module for a person to confirm.

Trade-off: one extra step for every action, in exchange for trust from the people accountable for staffing.

AI features and guardrails

The portal has five AI touchpoints. I gave each an autonomy level based on what a wrong answer would cost. The rule: the higher the cost of being wrong, the more the person confirms.

Two choices were deliberate absences. No AI feature reassigns people, and none edits the underlying workforce data. Both were proposed by AI during prototyping, and both were removed. Section 12 explains why.

Design system

With ten days, a design system was not a nice-to-have. It was the only way for AI-generated code to stay consistent across eleven screens. I built it token-first in Figma, documented every component, and used the same tokens in the codebase.

Layered tokens

Primitives hold raw colour ramps, type sizes, spacing, radius and effects. Semantic tokens map those to roles: background, surface, text, border, brand, status and chart colours. Components only consume semantic tokens, which is what made the light theme possible on day nine without redrawing a single screen. A usage map documents which components consume which tokens, so anyone adding a token can see its blast radius.

Documentation for every component

Each component page covers anatomy and sizes, variants and states, usage rules with do and don’t examples, and an accessibility block with role, keyboard behaviour, focus and contrast. The button, for example, has six intents across three sizes, six states, and a rule of one primary button per view.

Accessibility built in

I wrote the accessibility guidelines before the components, not after. They set WCAG 2.1 AA as a release requirement and cover:

• Contrast, measured. Primary text on the dark background is 15.32:1 and secondary text 7.07:1. Muted text is 3.95:1, so it is documented as decorative only, never for body text.
• No colour-only meaning. Badges carry text, trends carry arrows, chart series carry labels.
• Keyboard and focus. A 2px focus ring with offset, a defined tab order, focus trapping in modals and focus restoration when they close.
• Targets and reflow. 44px minimum targets, and layouts that reflow at 200% zoom.
• ARIA patterns for every component category, from badges as live regions to data tables with sortable headers.
• A testing checklist requiring zero axe-core violations at WCAG AA, plus keyboard-only, screen reader and reduced-motion checks.

Engineering and architecture

The discovery’s promise was a working product, so engineering was part of the design process, not a phase after it.

The stack

• Frontend on Vercel: React with TypeScript and Tailwind, styled from the same tokens as Figma.
• API on Railway: a Node service that serves module data and applies filters server-side, so every screen gets the same answer to the same question.
• Data on Supabase: Postgres for the workforce, project and allocation tables, with authentication and storage.

How I worked with AI on code

Each component started as a prompt with three inputs: the Figma design context, the component’s documentation page and the data contract it would receive. Claude produced a first version; I reviewed the diff in VS Code, fixed what was wrong and opened a pull request. The engineering architect reviewed anything touching the API or data model. Nothing reached main without a human review, and every merge deployed automatically, so stakeholders always saw the latest version on the live link.

A typical component prompt

Generic prompts produced generic components. What worked was giving Claude constraints in the same shape every time: “Build the KPI card from this design context. Use only these semantic tokens. The value uses the display style; the label uses the secondary text token. Accept this data shape. Include the aria-label pattern from the documentation, and render a loading and an empty state.” Naming the states and tokens up front cut review time, because the first draft already respected the system. When a draft invented a value, such as a new radius or colour, I rejected it rather than fixing it, so the habit would not spread. Section 13 shows where that discipline slipped.

Synthetic data with rules

The first AI-generated data was different on every screen. I replaced it with one seeded generator and reconciliation rules: allocation bands must add up to total headcount, bench age bands must add up to total bench, and business unit rows must add up to their totals. On the overview, the six allocation states sum exactly to 48,620, and bench by age and by business unit both sum to 1,126. Section 13 covers where the rules did not yet reach.

Validation

On day nine I ran five moderated sessions of 45 minutes with delivery and resource managers, on the live portal. AI wrote the scripts, transcribed the sessions and ranked issues by severity. I moderated, and I kept what people did separate from what they said.

What changed before handoff

• Light theme by default. The portal is projected in review meetings and exported to reports, where the dark theme performed poorly.
• Sort by cost on the bench table, added to the backlog as a quick win.
• Inline match reasons, added to the backlog as the top Talent Finder story.
• A “how this was calculated” link on planning recommendations, added to the backlog.

Five sessions is a signal, not a study. It was enough to find the issues that would have cost the most to discover after build.

Where I overrode the AI

Speed only counts if the output is right. These are the moments where the fastest answer was the wrong one.

Known debt

Moving at this speed leaves debt. I would rather name it than have a reviewer find it. I audited my own Figma file after handoff, and these are the issues it surfaced, each traceable to AI output that I accepted too quickly.

The pattern is the real lesson. AI was reliable at producing consistent-looking artefacts and unreliable at keeping meaning consistent between them. My reconciliation rules caught it at the level of totals, but not yet for derived numbers and individual records. That is now the first check I run on any AI-built prototype.

Impact

Discovery results are measured. Business results are projections from the brief and stay labelled that way until the portal runs on real data.

Where the time went

Effort estimate assumes three people at about $6K a month each: 1.5–2 months traditionally, half a month here.