Budgeting for a Team That Doesn't Exist Yet: The Future of Design System Teams

Design leaders are being asked to do something almost contradictory right now: hire for the gap they have today, while knowing that gap will look different in a year. Fill the role you’re short on now, and you might be staffing for a team structure that’s already shifting underneath you. Wait for clarity, and you fall further behind. There’s no clean way through this, just better and worse ways of making the call with imperfect information.

This is the conversation we’re now having with almost every client, whether they’re two years into a mature design system or just starting discovery with us. The traditional pairing of UX designer and UI designer, handing off to engineering, is giving way to something more fluid and more technical. If you’re planning a design system team for the next 18 months, that shift affects who you hire and how you budget for them.

The data backs up what you’re feeling

Designer Fund and Foundation Capital’s AI in Design 2026 report, based on surveys of 900+ designers and 25+ leader interviews, puts numbers to a shift most of us are feeling anecdotally.

Sixty-five percent of designers say they’re now doing more of what used to be PM, engineering, or design-engineering work: coding, prototyping, research, validation. Forty percent say the reverse is happening too: PMs and engineers are doing more design work.

When design leaders were asked to name the ideal roles on a product team today, “product designer” was the most-selected, but only 71% chose it. Among leaders who didn’t select it, 72% chose “design engineer” instead. In other words, nearly a third of design leaders left the traditional product designer off their ideal team.

But this isn’t a story about shrinking design teams. Sixty percent of leaders expect to keep or grow design headcount. What’s changing is who does the design work and what they’re called.

The roles replacing the UX/UI pairing

In our client conversations, a pattern keeps surfacing that maps closely to what the report calls the collapse of the “T-shaped designer” in favor of something more block-shaped: strong across several disciplines at once, rather than deep in one and broad everywhere else.

At the design system level, we’re seeing three new roles take shape, plus one that isn’t a new role at all:

The context engineer. Someone who owns what the AI actually reads (the tokens, the documented rationale, the component contracts) and keeps it from silently drifting.

The design engineer. A designer comfortable enough in code to deliver work that’s close to handoff-ready. They work alongside engineers, closing the gap between a polished comp and a mergeable pull request.

The design technologist. Usually sitting closer to engineering, this is the partner who receives that handoff and merges it into the codebase. The front-end counterpart who makes the design engineer’s output real.

The AI-native version of every role. This is the most common version of the shift and the easiest to miss, because nothing changes on the org chart. It’s a product designer, an engineer, or a PM doing the job they’ve always had, except now AI fluency is part of doing it well, and the people who don’t build it fall behind. If you’re mapping your 2027 team and only counting new titles, you’ll miss most of the change.

None of this requires wholesale replacement of your current team. One client told us the best design system contributors they’ve found came from inside their own product design team. People with empathy for both the design and engineering sides, who reduce the “just say no” reflex that governance roles can fall into. The shift is often reassignment, not rehiring: a UX designer with strong systems instincts becomes a context engineer; a product designer who’s been quietly writing components becomes a design engineer.

The report’s hiring data shows where the emphasis is moving. Half of design leaders say they’re now placing more emphasis on AI fluency when hiring, and 48% on systems thinking, but craft hasn’t gotten less important. Only 5% of leaders say they’re placing less emphasis on execution quality. As Elizabeth Lin, Design Program Manager at Ramp, put it, “Craft is more important than ever. If your portfolio doesn’t have high-quality work, using AI tools won’t get you far.”

This is the same shift TJ wrote about at the individual level in The Rise of the Alicorn (the unicorn designer, plus AI fluency). What’s happening at the team level is really that pattern multiplied: organizations trying to figure out how many alicorns they need, in which shapes, and whether to grow them or hire them.

Budgeting for 2027 without full clarity

Back to that headcount conversation. With clients in that bind, we’ve landed on four things:

Hire for today’s gap, but structure the role to flex. Whatever role is your bottleneck right now, fill it, but write the job description and level it in a way that can absorb context-engineering or design-engineering responsibilities as your system matures. Build the carve-out into the plan explicitly, the way you’d build contingency into any other budget line.

Look inward before you look outward. Before adding headcount, map who on your current team already has the instincts (systems thinking, curiosity about AI tooling, comfort with ambiguity), even if they don’t have the title yet. In the report’s interviews, leaders repeatedly pointed to adaptability and curiosity. That’s the thing you can’t train quickly; the tools you can.

Consider the three flows your design system actually needs to support, and staff against each rather than one undifferentiated “design system team” line: the team building the system itself, the product teams consuming it, and the product teams contributing back into it. Each of those needs its own contribution model and review cadence, and clarifying that early saves you from over- or under-hiring against the wrong flow.

Revisit the plan after discovery, not before. Most of the clients we work with lock in a headcount plan before an initial system audit or discovery work has even happened, then treat it as fixed. Build in a formal checkpoint instead: a point after discovery where the plan gets revisited with real data from the action plan. It’s a small structural change.

The non-negotiables

For all the role-shuffling, the leaders in the report name the same non-negotiables: creative vision, strategic direction, and deep craft. AI can generate infinite variations of a component. It cannot yet tell you which variation reflects where your product needs to go next, or hold the kind of taste that keeps a design system coherent as five product teams pull it in five directions.

So when you’re the one writing the budget, plan for where that judgment will sit on your team, whatever the role ends up being called.