Planning headcount where HR data lives

Background

Workday's acquisition of Adaptive Insights brought a strong financial planning product into the portfolio. Workforce planning was the natural next step: headcount is the largest line item in most budgets, and planning it well depends on HR data that already lived in Workday. The market was large, more than $7B and growing at roughly 18% a year, but the existing experience did not connect planning to that HR data.

Workforce planning is making sure an organization has the right people in the right place at the right time. It runs as a loop: create and approve a headcount plan, put it into action, then track progress and adjust the forecast to course-correct. The product had to support that whole cycle, not just the spreadsheet at the start of it.

I led design for a 0→1 product that brought bottom-up headcount planning into Workday, close to HCM, so planners could build a plan from real positions and costs instead of a disconnected spreadsheet model. The defining decision was where to build it: as an application inside Workday rather than a platform inside Adaptive. Most of what follows traces back to that bet.

My role and the team

I was the UX Lead and hands-on designer on the initiative. The core team was two designers and a researcher, three product managers, and two functional architects, alongside engineering and partner UX teams who brought existing HCM research. Because this was a 0→1 effort, I owned the end-to-end experience, from early flows and prototype to the shipped release. The concept phase, from discovery to the tested Figma prototype, ran in a tight six-to-eight week window. Iteration and delivery then continued with the product team through the 24R2 release.

Who we designed for

Discovery ran through design partner groups, 1:1 interviews, sessions with the product strategy and implementation teams, and a competitive review. It converged on three personas, framed with jobs to be done and user types. Each comes at a headcount plan from a different angle, and the product had to serve all three without defaulting to the financial-modeler experience Adaptive started from.

• HR business partners own headcount and advise people leaders. Their job is to answer workforce questions quickly and accurately and translate data into people strategy, so they needed guided, form-based entry rather than a modeling canvas.
• Senior business users, from functional managers up to the C-suite, drive the decisions a plan informs. They juggle many tasks during planning and are easily overwhelmed by too much data, so they needed clear summaries over raw detail.
• Financial analysts, the persona Adaptive already served, assess the financial impact of headcount changes and keep the underlying plans accurate.

The problem

Two problems sat underneath the opportunity:

Planning experience gaps. The existing flow was built for financial modelers, not for the HR business partners and functional managers who actually own headcount. They needed form-based entry and guided workflows, not a blank modeling canvas.

Weak HCM integration. Plans were built away from the HR system of record, so position and cost data had to be moved by hand. That made plans drift from reality and made every implementation slower.

In research, customers kept coming back to data quality:

[Our biggest pain point] is making sure we have correct data.

Data validation... we're seeing areas where users fail to fill out mandatory fields... probably our number one area.

It can be tough to get them [HRBPs] to correct or respond to all of the issues we identify... probably just fatigue, primarily, and a lot of those data points that we're testing... may not seem that important versus, like, getting an offer out... getting everyone's education filled out may not be their highest priority.

These gaps showed up in the business as lower satisfaction, churn risk, and long implementation timelines.

The bet: an application, not a platform

We evaluated two ways to build it. The first kept the solution inside Adaptive on a platform model, where admins configure the experience for end users. That was the path of least resistance; it is how Adaptive had always shipped. The second delivered it as an application inside Workday, closer to HCM.

Three criteria decided it, each tied to a problem above:

New personas. HR business partners and functional managers needed form-based entry and guided workflows. An application shapes that experience directly; a platform leaves it to each customer's admin to configure.

Data quality. Building inside Workday let plans source positions and cost straight from HCM and the financial plan, and reuse HCM validation rules and contextual security, so a plan stays tied to the system of record instead of drifting from it.

Flexible approvals. Workday's business process framework gave customers flexible approval routing without custom build-out for each customer, instead of building approval logic from scratch.

We built it as an application inside Workday. The trade-off was real: an application is more opinionated and less configurable than the platform Adaptive customers knew. I come back to that tension in the reflection.

Mapping the flow with architects and PMs

Working with functional architects and product managers, we mapped the MVP end to end: which persona owns each step across the full lifecycle, from budget and configuration through planning, approval, execution, and monitoring, and the actions each step needs. The journey map kept the cross-functional team aligned on one shared flow and set the scope for the concept that followed.

Alongside it we mapped the system: how a finalized financial budget hands targets down to a headcount plan, how the plan links to and imports from HCM, how approvals run through the workflow, and how an approved plan drives execution and plan-versus-actual reporting.

The first concept

I built an early Figma prototype of the end-to-end flow to get stakeholder buy-in and to run internal usability testing with HR business partners, financial analysts, and senior business users. The concept designed the whole planning loop, from building a plan to putting it into action.

Building the plan. Cost of workforce was sourced from the financial plan and the personnel list imported from HCM, with form-based entry, required fields, validation, and bulk actions to keep data clean.

Working with the plan. Planners could switch between an org view for high-level modeling, a detailed table for individual and bulk edits, and a summary view for quick review.

Governing and executing. An audit trail recorded every change to the plan, and a plan-execution view tracked the actions needed to put it into effect.

What testing told us

Testing the prototype with internal users and the Design Partner Group gave a clear read on what to keep and what to change:

• Form-based data entry held up. Users found it fast and clear, which validated the core entry model.
• Org view was well received for its clarity, but users saw little value in it without broader org modeling.
• Planners judge a plan by more than cost, so a single cost-of-workforce target was not enough. They wanted FTE and headcount too.
• Commenting on individual positions mattered more than we had assumed, so it moved up in priority.
• Users wanted control over the personnel table, and asked for display options to choose visible columns and filter rows.

How the design changed

The feedback turned into concrete changes between the first concept and the shipped design.

KPIs that match how planners judge a plan

The concept tracked a single cost-of-workforce target. Because planners weigh headcount and FTE alongside cost, the iteration promoted all three to KPI cards that recalculate as the plan changes. The same pass surfaced comments on individual positions inline, which testing had pushed up the priority list.

Display options for the personnel table

Users wanted control over the personnel table, so the iteration added display options to choose which columns show and which rows to filter.

Org modeling in org view

Org view was first conceived as a read-only chart. Testing liked it for its clarity but found limited value in a view you could not act on, so we built org modeling into it. Planners can now move workers, change jobs and org assignments, and freeze positions directly in the chart, with workforce cost, headcount, and FTE rolling up as the structure changes.

What we shipped

The bottom-up headcount planning solution shipped in the 24R2 release in September 2024, under the Early Adopter Program.

Bottom-up headcount plan

The shipped plan carries the iteration into the product. KPI cards for cost of workforce, headcount, and FTE stay visible and recalculate as planners edit, and the personnel list stays linked to HCM and the financial plan so the numbers track reality.

Linkage and approvals

A guided experience bootstraps a plan by auto-populating data and metadata from the connected systems, which cuts setup work. Approvals run on Workday's business process framework, so customers get flexible, streamlined approval routing without a custom build.

Impact

• Bottom-up headcount planning shipped in the 24R2 release (September 2024) in the Early Adopter Program, with strong early feedback, especially for the experience.
• Based on the implementation team's early assessment, the new setup experience reduced implementation time by an estimated 40%, by auto-populating plans from connected HCM and reusing Workday's business process framework.
• Early enthusiasm led the company to invest more in expanding the product to new use cases, including skills planning.

Reflection

Platform versus application is a real trade-off

Adaptive had always shipped a platform-centric experience, where admins configure workflows for end users. Here we chose an application-style approach, a simpler guided experience that cut implementation time. The open question for what comes next is whether a more closed, application-like experience can still flex to the diverse, complex cases workforce planning throws at it.

New personas need new research

Designing for HR business partners and functional managers introduced needs the financial-modeler experience never had, like form-based entry and streamlined workflows. Partnering with UX teams who already had research on these personas sped up discovery and let us validate decisions early.

A 0→1 product depends on early cross-functional work

Because this was a 0→1 initiative, getting cross-functional stakeholders involved early was what made it work. Understanding the technical and business constraints from the start cut rework and kept the team aligned on the same goals.