Workforce Intelligence: from a thin BRD to a live product in 10 days
An AI-augmented product discovery for Coforge. The depth of a 6–8 week discovery, delivered in two working weeks, ending in a deployed portal instead of a slide deck.
- Client
- Coforge (internal initiative)
- My role
- UX AI Engineer and Product Manager
- Team
- Me, an engineering architect, a delivery SME
- Timeline
- 10 working days
- Stack
- Figma, Claude, VS Code, GitHub, Vercel, Railway, Supabase
- Data
- Synthetic, modelled on a 48,620-person IT services workforce
Day 1 ingest, day 2 understand, day 3 define, days 4–5 design, days 6–8 prototype, day 9 validate, day 10 handoff.
The brief
Coforge’s design team handed over a basic business requirements document. It named twelve modules, specified three of them, and set one goal: replace spreadsheet-based resource planning with a single view of capacity, utilization and demand across business units.
The stakes, in the brief’s own model, were large. Bench cost ran at $1.8M a month. Staffing a new project request took 7–10 days. Billable utilization sat at 82.6% against an 85% target. Every one of those numbers traced back to the same cause: nobody could see available people, partial allocations and upcoming demand in one place.
A BRD like this usually starts a 6–8 week discovery. I was asked to answer three questions in two weeks instead. Who makes workforce decisions? Which decisions cost the most when they are slow? What is the smallest product that makes those decisions faster?
My role and constraints
I worked as UX AI Engineer and Product Manager. I owned the problem framing, research, design system, prototype code and backlog. An engineering architect reviewed architecture and pull requests part-time, and a delivery SME from Coforge gave domain input and opened doors to users.
Three constraints shaped the work. No access to real HR or project systems, so all data had to be synthetic but believable. A fixed window of 10 working days. And a BRD where nine of twelve modules were a single line each, so I chose depth over coverage: three modules designed end to end, the other nine designed to a consistent pattern.
The process: AI accelerates, I stay accountable
I ran my AI-augmented UX process across three phases: understand, explore and materialize. In every stage, AI produced the first draft and I made the call. The table shows what that split looked like day by day.
| Days | Stage | What AI accelerated | What I decided |
|---|---|---|---|
| 1 | IngestUnderstand | Parsed the BRD into requirements and open questions. Scanned common workforce-planning patterns. | Scoped depth to three modules after finding nine had no specification. |
| 2 | UnderstandUnderstand | Drafted the interview guide. Transcribed and clustered six stakeholder conversations. | Named the three decision-makers and the one decision each makes every week. |
| 3 | DefineUnderstand | Generated personas, journeys, how-might-we statements and draft user stories. | Rewrote personas around decisions and cut stories that only served reporting. |
| 4–5 | DesignExplore | Produced IA options, flow variants, wireframes and token suggestions. | Ordered navigation by decision frequency. Built tokens and an atomic library to WCAG 2.1 AA. |
| 6–8 | PrototypeMaterialize | Claude generated React components from Figma context, API endpoints and a synthetic dataset. | Reviewed every pull request, made the data reconcile, and set what the in-product AI may and may not do. |
| 9 | ValidateMaterialize | Wrote task scripts, transcribed sessions and ranked issues by severity. | Moderated five sessions with delivery and resource managers and chose what to fix first. |
| 10 | HandoffMaterialize | Drafted Jira stories with acceptance criteria, handoff specs and accessibility notes. | Prioritised the MVP: 23 stories, 192 points, 10 epics. |
Three decisions that shaped the product
Lead with recoverable capacity, not headcount
The BRD opened the dashboard with total FTE. Interviews showed portfolio leaders already knew their headcount. What they could not see was capacity hiding in partial allocations. The overview now leads with the gap: 6,420 partially allocated people, worth about 3,180 recoverable FTE, with one action to explore it.
Trade-off: a less familiar first screen for HR users, in exchange for a direct path to the decision that moves bench cost.
Natural language search, with the ranking out in the open
Resource managers search the way they talk: “five senior Java developers with AWS, 40% free within 30 days.” Talent Finder accepts that sentence, turns it into visible filters and returns a ranked list. Every match score uses a published weighting (skills 40%, availability 30%, relevant experience 20%, team fit 10%), so a manager can challenge it rather than trust it blindly.
Trade-off: showing the scoring logic invites argument. That was the point. A staffing decision someone cannot explain will not be made.
An advisor that recommends, never acts
Moving people between projects affects careers and client commitments, so the cost of a wrong AI action is high. The AI Workforce Advisor answers questions and proposes actions, but every action routes to the relevant module for a person to confirm. Status chips show that it runs on live data and how many employee records it can see, so users know what its answers rest on.
Trade-off: one extra step per action, in exchange for trust from the people accountable for staffing.
Where I overrode the AI
Speed only counts if the output is right. These were the moments where the fastest answer was the wrong one.
Generic personas
AI proposed: an “HR manager” and an “employee” persona.
I rebuilt them around three decision roles: portfolio leader, resource manager and delivery head. Each persona now carries the weekly decision it owns.
Numbers that did not add up
AI proposed: different sample data on every screen.
I replaced it with one seeded dataset in Supabase, so headline totals reconcile to the same 48,620 people across modules. Stakeholders stopped checking maths and started discussing decisions.
One-click bulk reassignment
AI proposed: automatic moves when a match passes 90%.
I changed it to suggest and confirm. High stakes call for human confirmation, whatever the score says.
Dark-only interface
AI proposed: a dark analytics theme throughout.
Validation showed the portal is projected in review meetings and exported to reports. Light became the default, with dark kept as a toggle, both driven by the same tokens.
From prototype to production
The discovery did not end in a clickable mock-up. The same design tokens drove Figma and code, so the prototype became the first release.
Impact
Discovery results are measured. Business results are projections from the brief and stay labelled that way until the portal runs on real data.
Measured in discovery
What this project delivered.
Projected by the business case
Targets from the BRD. Not yet measured.
Limitations and what comes next
- Synthetic data proves the experience, not the outcome. The next step is a pilot on one business unit’s real allocation data.
- Five sessions is a signal, not a study. Validation needs a wider round once real data is in.
- Match reasons belong in the results list. Today they sit in the employee profile. Managers asked to see why a person ranks highly without opening each record.
- Forecasting is rules-based for now. Phase 2 replaces it with trained models and shows confidence ranges users can act on.
The lesson I took away: AI removed the waiting between stages, not the thinking within them. The ten days were fast because every AI draft met a clear decision about what to keep, what to change and what to throw away.