Sometimes it starts with a pitch, or a neat deck, or even a borrowed stat. Inspired by a sense that everyone else has a design system, and maybe you should too. You make the case before talking to a single team. Before mapping the real problems. Before figuring out what kind of system the business actually needs.

Other times, it skips the pitch completely. Someone starts building behind the scenes. No conversations, no buy-in. Just a quiet prototype in a separate file or branch. The logic is simple: show the value by doing the work. But too often, that work is shaped by assumptions rather than alignment.

Either way, it doesn’t always land the way you hope. The system gets built, or half-built. Maybe it launches, but adoption is patchy. It doesn’t solve the right problems. And even when it does, it doesn’t reflect how teams actually work. Sometimes you get buy-in, but not really. The business nods along, but it still gets treated like a side project, or something a few people can chip away at between other priorities. It gets a sliver of a roadmap, or a quarter of someone’s time. It’s buy-in in name only and that’s not enough. So the system ends up reworked, replaced, or quietly resisted.

Because it was pitched before it was understood. Or built before it was aligned.

‘It started out with a pitch, how did it end up like this?’ Mr. Darkside by The Killjoys

The problem isn’t ambition, it’s sequence. When you lead with the solution, whether it’s a polished business case or a working prototype without first understanding the full picture, it rarely sticks.

Buy-in doesn’t come from a perfect pitch or a sneaky surprise system. It comes from shared understanding. When people see themselves in the process, when the problems are clear, and the solution feels like something that was shaped with them, not for them, that’s when buy-in happens.

This article guides you through avoiding the ‘build-now-ask-later’ trap, the ‘pitch-without-proof’ trap, and how to bring people into the process early through a workshop that actually fosters alignment. One that helps you make a business case that writes itself.

Why pitches fall flat

The standard design system pitch is familiar: it promises consistency, efficiency, and savings. Sometimes it’s focused on speed. Sometimes on cost. But often, it’s built in isolation, with a lot of assumptions and very little input.

Without team insights, the pitch becomes abstract. It starts to feel disconnected from how people actually work, which makes it easy to ignore. Other times, it leans too heavily on technical depth. You talk about token structures or component architecture, but forget to connect it back to the problems the business actually cares about.

And then there’s the overpromising. These pitches often sell the dream without a reality check. They talk about sweeping savings and improved delivery speed, but without clarity on when or how those results will show up. So when progress feels slow or your early metrics are vague or too abstract, “consistency improved” or “velocity increased” stakeholders lose confidence. The work gets sidelined. The system gets treated like a nice-to-have instead of a strategic tool.

That’s where most pitches fall down: they lead with the solution, not the problem. And if the problem isn’t shared or clearly understood, the solution won’t feel urgent or all that useful.

Being grounded in the reality of how your organisation works and what it actually needs from a system is what gives your case weight. It gives you the space to start small, show impact, and build towards long-term value without overextending. When people know what to expect, and why, they’re far more likely to stay with you on the journey.

The other trap: build first, explain later

When a pitch doesn’t land, the instinct is often to skip alignment altogether and just build. The logic is simple: if we build something useful, people will come around.

Sometimes that works. But more often, it leads to systems that don’t quite fit. You make choices based on what you know, not what teams need. You design components that are technically sound but don’t reflect how the product team works. You introduce logic that feels right in isolation but adds friction downstream.

Even with the best intentions, building without alignment often means missing context. And once that happens, the system ends up being reworked, replaced, or resisted.

Alignment is your shortcut to real buy-in

You don’t need a finished system to get buy-in. You need shared clarity. That means understanding what’s slowing teams down, where design and engineering are out of sync, what duplication looks like in practice, and what kind of system would actually help.

Before writing a business case or creating a roadmap, bring people into the process. That doesn’t mean asking for permission. It means co-creating the case for why a system exists in the first place.

The best way to do that is through a workshop. One that’s not about presenting a solution, but about surfacing the problems and framing the conversation around what’s needed now.

The Workshop

Who to include

The right people make the biggest difference. Try to bring together a mix of leadership and stakeholders from across disciplines including: product, design, engineering, brand, content. Ideally including those who are both skeptical and supportive of systems work. You don’t want a small group with a narrow lens. You want to break out of any potential echo chamber. That’s where stronger conversations happen.

Include leadership where possible. When they’re part of the conversation, they’re more likely to support the outcomes. Sometimes that even means approving direction on the spot. Don’t be afraid to invite them in. And if they can’t attend, make time to speak with them beforehand. Understand what they value, where they see friction, and what outcomes matter most to them. That context becomes essential when framing your business case later.

How to structure the workshop

The workshop isn’t about presenting a solution, it’s about surfacing the real problems and shaping clarity around what’s needed now.

The goal here isn’t to pitch. It’s to understand what’s already happening, what’s getting in the way, and what kind of system will actually help.

Here’s a structure that keeps the session grounded, collaborative and focused on what matters:

1. Share what you’ve found so far

What it is: Open the session by walking through what you uncovered in your pre-workshop audit. Include real examples of duplication, inconsistency, or workflow pain points from across the product, design and engineering teams.

Why it matters: This shows you’ve done your homework. It helps people see their reality reflected back, creating a shared starting point for the conversation. It also gives leadership and non-design stakeholders a clear sense of the challenges the system could help address.

2. Ask: What problems are we facing without a design system?

What it is: Give everyone time to reflect and write down the challenges they’re experiencing due to the lack of a system. You’re not asking what features the system should have, you’re asking what’s hard right now, and what’s holding them back.

Then, as a group, cluster and group the responses into themes: consistency, handover, scalability, onboarding, velocity, etc.

Why it matters: This surfaces shared frustrations across different roles, and gives you a clear signal of what the system actually needs to solve. These themes will form the foundation of your business case and help ensure it’s grounded in real team pain, not abstract system benefits.

3. Prioritise what needs solving first

What it is: Once the themes are grouped, map them out using a Now / Next / Future timeline. The goal isn’t to solve them on the spot, just to align on which ones are urgent, and which ones can wait.

Why it matters: This keeps the conversation realistic. It shows you’re not trying to fix everything at once and gives your future system a focused purpose. This prioritisation also helps shape phased business case goals and timelines that are easier to align with leadership.

4. Connect challenges to outcomes

What it is: Lead a discussion around how a design system might address the challenges identified. For example, if teams are struggling with inconsistent handover, how might shared tokens or components help?

Why it matters: This is your bridge from pain points to system value without slipping into solutioning too early. It also helps participants start connecting the dots between their own work and what the system will enable. This is especially helpful when writing the outcomes and impact section of your business case later.

5. Map the bright future and dark future

What it is: Ask the group to imagine both what success could look like if the system is implemented well, and what failure might look like if nothing changes or if the system is done poorly.

Why it matters: This helps highlight risks and opportunities beyond just tooling. Like team perception, maintenance overhead, or cultural resistance. It also opens up more honest conversations about past attempts or fears, which makes future decisions stronger.

6. Spot the risks, assumptions and dependencies

What it is: Use a lightweight RAID (Risks, Assumptions, Issues, Dependencies) format to gather what might get in the way. This includes things like unclear ownership, integration complexity, or dependencies on hiring or tooling.

Why it matters: Capturing these early helps you build a more honest business case. Instead of promising smooth delivery, you can show that you’ve thought through the realities. This builds trust, especially with stakeholders who’ve seen failed initiatives before.

7. Understand your audience

What it is: Step back and think about who your business case is for. Is it leadership who care about timelines and risk? Delivery leads who need to see practical benefits? Or product stakeholders who need confidence in the roadmap?

Why it matters: Different stakeholders care about different things. If you write one generic case, it might not land with any of them. Use insights from the workshop to understand what each group values, and shape your messaging accordingly.

What it is: After the session, take a moment to map the top system outcomes to broader company goals, whether that’s speeding up delivery, improving accessibility, strengthening brand presence, or enabling scale.

Why it matters: A system that’s positioned as “just a design problem” will struggle to get traction. But if you can connect the system’s potential to company-wide priorities, it starts to feel like a strategic enabler rather than a nice-to-have.

9. Pre-empt the objections

What it is: Based on what surfaced in the session, take note of any common concerns or fears around delivery timelines, worries about quality, questions around resourcing or adoption.

Why it matters: You can now proactively address these in your business case instead of waiting for pushback. This not only strengthens your proposal, it shows leadership you’ve thought through what’s hard and how you’ll handle it.

After the workshop

Define what kind of system you need

Now that you’ve clarified the problems, take time to consider how best to solve them. Don’t assume a custom-built, fully bespoke design system is the right answer. Sometimes the best setup is simpler than you think.

There are a few different approaches you can take:

  • Reskinned UI kitBuilt on top of an existing foundation, with your visual language applied. Good for moving quickly and building maturity over time.
  • Custom buildTailored to your organisation’s exact needs. More flexible but more resource-intensive.
  • Hybrid modelStart with something standard, then extend or adapt it as your needs grow. Often, the best balance of speed and flexibility.

What you choose should reflect your team’s maturity, available resourcing, and the complexity of the problems you’re solving. Just make sure the decision is intentional.

Choose a team model that reflects how you work

Once you’ve figured out what to build, decide who’s going to run it. Your team structure will shape how the system grows, how contributions are managed, and how decisions get made over time.

Here are a few common models:

  • SolitaryOne or two people juggling the system alongside their main role. Often, how systems start.
  • CentralisedA dedicated team with ownership and direction. Good for consistency and scale.
  • FederatedContributors from across teams feed into the system, supported by lightweight governance.
  • CyclicalA core team collaborates with delivery teams in cycles. Helps with adoption and shared ownership.
  • DistributedOwnership spread across teams, aligned through shared standards and tooling.

Most orgs land somewhere between these models. Choose what fits your org today and revisit it later when things shift.

Now you can write your business case

At this point, you’ve got everything you need. You understand the problem space, you’ve involved the right people, and you’ve defined what a good solution could look like. Now your business case becomes a reflection of that process, not just a pitch.

What to include:

  • A vision statement that links the system to company goals
  • The problems it will solve and when
  • Your proposed team model and structure
  • Measurable goals and outcomes
  • The system setup you’ve chosen and why
  • A realistic timeline for now, next and future

When you’ve done the alignment work first, this document becomes a formality, not a hard sell.

Final thought

Design systems aren’t just about consistency and components. They’re about creating a shared understanding of how your organisation builds and grows. And if you want that to stick, you can’t start in isolation. Not with a deck, and not with a prototype.

Start with the conversation. Everything else will follow.