In last week’s issue, I talked about the cold start problem of design systems—the challenge of getting them off the ground in environments resistant to change. Today, I want to share an allegory about a team that faced this exact struggle. It’s the story of a design system born not from top-down mandates but from the determination of a few who refused to give up.

Introduction

Once upon a time, within the sprawling tech company Lumina Corp, teams were tirelessly building features for their flagship product, Lumina Workspace, a suite of collaboration tools.

As the product grew, cracks began to show: designs were inconsistent, development timelines stretched, and users were frustrated by the patchwork interfaces.

Despite the challenges, leadership showed little interest in addressing the root cause. To them, a unified design system seemed like an unnecessary distraction from feature delivery. But within the ranks of designers, engineers, and product managers, a group began to see the truth: without a cohesive foundation, Lumina Workspace would never achieve its full potential.

Initial hurdles and challenges

Dubbing themselves the Lumina Crew, this group decided to create a design system—not because they were told to, but because they believed it was necessary to bring order to chaos. They met casually at first, squeezing brainstorming sessions into lunch breaks, after hours, and the occasional quiet Friday afternoon. They knew they had to start small to make progress while juggling their primary responsibilities.

While the theory was sound, the practicality of it contained many hurdles and challenges. Crew members had to balance their full-time responsibilities with this side project. Deadlines loomed, and leadership offered no dedicated resources for their efforts. Meetings were often interrupted by urgent work, and progress was slow.

As they started to share their ideas around the company, colleagues were skeptical about the potential design system’s value, viewing it as "nice to have" rather than essential. Product managers worried it would slow feature delivery, and engineers questioned the upfront investment of time to learn a new product.

Even alignment within the Lumina Crew was fraught. The team itself sometimes struggled to agree on priorities. Should they focus on the UI library, documentation, or tools to streamline handoffs? Without clear leadership, decisions sometimes stalled.

Strategy: work it out

Despite the challenges, the Lumina Crew made steady progress by deciding to work their way through even without all the answers. Their first task was to identify the most pressing pain points in the current product. They chose a small, manageable goal: standardize the core components for the task management feature within Lumina Workspace. It was a high-traffic area that would demonstrate immediate value if improved.

But the task management team, a high-profile group within Lumina Workspace, was skeptical. Why should they risk integrating unproven components when their current system, though messy, worked well enough?

The Lumina Crew knew they couldn’t convince the task management team with promises alone. They needed to show, not tell, how the design system could solve the team’s problems without disrupting their workflow. They devised a three-step plan:

1. Understand the real pain points

Before pitching anything, the Crew took the time to listen. They met with the task management team during lunch breaks and one-on-one conversations to learn about their challenges.

• For Designers: “It’s exhausting to manually recreate components for every new feature,” one designer lamented.

• For Engineers: “We’re reinventing the wheel every time we code a button or a modal,” an engineer said.

• For Product Managers: “Inconsistent interfaces are a top complaint in user feedback,” admitted the PM.

The Crew framed their pitch around these pain points, ensuring their message was relatable and grounded in the team’s reality.

2. Build a small, relevant prototype

Instead of asking the team to adopt the entire design system, the Crew created a small pilot solution tailored to one specific feature: the task creation flow.

What they built

• A type scale with 6-8 levels of hierarchy

• A color palette with 12-16 colors split among core colors, semantic colors, and neutral colors

• Primary, secondary, and disabled buttons, each with hover and focus states

• A 12-column grid system that works across screen sizes

• Text inputs, dropdowns, checkboxes, and radio buttons, all with validation states

With those 5 pieces, they put together:

• A new task card component with consistent typography, spacing, and hover states.

• A reusable modal component for task creation, complete with validation states and accessibility compliance.

How they built it

• The Crew used their own time to develop and test these components.

• They ensured the code was easy to integrate into the team’s existing systems, requiring minimal refactoring.

3. Make it risk-free to try

The Crew approached the task management team with a simple offer: "Let us handle the heavy lifting."

• They promised to embed one of their engineers and one designer into the team for a sprint.

• They guaranteed the team could revert to their old components with minimal effort if the new ones didn’t work.

• They committed to responding immediately to feedback and making adjustments as needed.

Overcoming Resistance

At first, the team’s response was cautious. Engineers worried about integrating new code. Designers feared losing creative control. Product managers questioned whether the effort would delay feature releases.

But the Crew countered these concerns with practical answers:

• For Engineers: “We’ll embed one of our engineers to handle integration. You won’t need to change your workflow.”

• For Designers: “These components are flexible. You’ll have full control over how they’re styled and used.”

• For Product Managers: “This will actually save time in future sprints by eliminating redundant work.”

The First Sprint with the Design System

Reluctantly, the task management team agreed to try the components for a single sprint. The results spoke for themselves:

• The task creation flow was completed two days ahead of schedule.

• Usability testing showed a 15% increase in task creation success rates due to the simplified interface.

• Engineers were excited to reuse the same components for other features.

Momentum Builds

The success of the first sprint made the task management team believers. They began requesting more components, and other teams took notice. As word spread, other teams started to ask about the design system. “Can we use those buttons?” one developer asked. “How do we get the typography styles in our project?” a designer inquired.

The Lumina Crew’s design system, once a side project, was now a key part of Lumina Workspace’s future.