Overview
Boston Scientific needed a workforce planning system — but before any software could be designed, the organization needed to agree on what workforce planning actually was.
Different functions defined the work differently. Different leaders had different time horizons in mind. The data that existed didn't always map cleanly across business units or reporting structures. And no shared process had ever been formalized at scale.
My work here wasn't to design an interface. It was to create the foundation that an interface could eventually be built on.
The Context
Workforce planning happens across multiple time horizons — and they each require different thinking:
- Operational planning — near-term adjustments, execution, response
- Workforce planning — one- to two-year outlooks tied to annual cycles
- Strategic planning — longer-range views aligned with business direction
At Boston Scientific, these layers were often handled in isolation. Leaders in HR, Finance, and Operations were each doing versions of the same work — without a common language, shared data structure, or consistent process. The result was coordination happening through one-off conversations rather than shared systems.
My Role
I joined this initiative to support a pilot exploring how workforce planning could be formalized and eventually supported through shared tools. From the start, it was clear the real challenge was organizational, not technical.
I partnered with a senior business analyst who had deep domain knowledge and had already drafted an initial process model. We treated it as a starting point — something to pressure-test through research and then extend into shared artifacts the broader team could work from.
- Conduct research across functions to understand real planning behaviors
- Synthesize perspectives from HR, Finance, Operations, and Business Leadership
- Design artifacts that could support alignment before any tool decisions were made
- Facilitate workshops that brought cross-functional leaders into shared conversation
Research & Sensemaking
We conducted 30+ interviews with planning leads, people managers, and process owners across functions and regions — supported by an external consulting partner.
What emerged wasn't a single picture of how workforce planning worked. It was six distinct pictures, each reflecting a different planning context with its own rhythms, data needs, and decision-making patterns.
These personas weren't just a research artifact — they became a shared reference point that let stakeholders stop talking past each other. Before we had this, conversations about "the planner" assumed everyone meant the same person. They didn't.
One consistent pattern across all groups: coordination was happening through conversation, not tools. People were bridging gaps between planning layers manually — often through email chains and one-off meetings. That was the real design problem.
Beyond personas, we identified four distinct planning styles — each with its own data inputs, time horizons, and approval paths. Understanding which style applied to which business unit was essential for designing anything that could actually be used across the organization.
System Considerations
Early on, it became clear that the technical and data landscape would significantly shape what was possible. Role structures, reporting hierarchies, and financial attribution models varied across business units in ways that made simple aggregation difficult.
We made an explicit choice not to treat these as blockers. Instead, we documented them as design constraints to be addressed progressively — building a system that could handle complexity over time rather than trying to solve everything at once.
One key decision: we wanted the system to surface contextual intelligence based on who was using it, not force every planner into the same view.
Alignment Through Design
Before defining requirements or building anything, I designed and facilitated an in-person workshop with senior leaders from Finance, HR, and business operations.
The goal wasn't to generate ideas. It was to create the conditions for a real conversation — one where people with different definitions of success could find shared ground.
We used the persona work, journey maps, and a structured vision exercise to move from "here's what we each care about" to "here's what we're building toward." By the end, participants had co-created a direction rather than simply reviewed one.
This process map — developed collaboratively — gave us the first shared picture of how workforce planning actually moved through the organization. It became the anchor for every subsequent conversation about scope, sequencing, and tooling.
Design Strategy
A workforce planning system at this scale can't be built all at once. The dependencies are too complex, the stakeholder landscape too varied, and the data too inconsistent across business units to ship a comprehensive solution.
So we designed for increments — each one delivering real value on its own, while moving toward a coherent long-term architecture.
- Each phase is useful in isolation, not just as a step toward the next
- Assumptions are surfaced and documented rather than buried in the design
- The system is built to support adoption, not require it
Early wireframes focused on the highest-volume planning scenario — Direct Labor, Volume-Based — as a way to test assumptions about what planners actually needed to see and do in a given session. Form followed function: what's the job, and what does this person need to do it?
Current State
This work is ongoing. What's been built to date is mostly invisible in the traditional sense — no launched product, no public-facing feature. But the foundation it created is real:
- Validated current- and future-state process models
- Six personas grounded in actual planning behavior across the org
- A shared cross-functional vision developed through facilitated leadership alignment
- An MVP framing that translates strategic intent into actionable first steps
The dashboard above reflects where the product direction is heading — a system that gives planners visibility into what's in flight, what's at risk, and what needs a decision. Getting here required building the conceptual and organizational scaffolding first.
Part of the strategy work also included structured vendor evaluation — helping the organization make a well-informed build-vs-buy decision with clear criteria rather than relying on vendor presentations alone.
Reflection
This project is a good reminder of what UX is actually for. The most important design work here happened before any screen was drawn — in research synthesis, workshop facilitation, and the patient work of getting people to agree on definitions.
In complex organizations, the software problem is almost never the hardest one. The harder work is figuring out what you're actually trying to do and getting the right people aligned around that. Design can do that. That's the work I find most interesting.