Starting a Design System

From Pitching a Strategy to Launching 1.0 and Beyond

Nathan Curtis
Aug 7, 2017 · 8 min read

Starting a design system to serve a product portfolio isn’t a typical project. Sure, the effort produces recognizable outputs like a visual language and UI components. Making it should feel familiar, cycling through iterations of design, development, and documentation.

However, the system’s promise isn’t a delivered library. The system’s promise is enabling a consistent experience spread across products and sustained with a dependable, predictable practice. System enthusiasts must become entrepreneurs, pitching and selling ideas that get a possibly resistant organization to commit. Over time, a system achieves meaningful outcomes by coordinating and collaborating across organizational boundaries and pesky culture. It’s a process.

This arc to start a system — set a strategy, launch a first release, and operate regularly to foster adoption and community — has proven effective in the five systems I’ve led since early 2016. All were made, adopted, and continue to operate today with activities and timelines described here. May the approach inspire as you start a journey towards a system that endures.

Commit to a System Strategy

Discover Customer Needs

Discovery activities can include:

  • Interviews of key (potential) contributors, influencers and leaders to assess perspective, attitudes, culture, and existing practices.
  • Surveying a broader organization of stakeholders attitudes and posture towards a system, priorities/needs, aspirations, and threats.
  • Requirements gathering via task analysis, tech planning, and convention setting (using tools like Brad Frost’s Front End Questionnaire).
  • Product tours to immerse in as-is products and in-flight designs to which the system will apply, taking screenshots and notes.
  • System(s) reviews assessing as-is design assets, code libraries, standards documentation depth and quality, and governance models.

Engage Stakeholders in Inclusive Workshops

Converge on a Conceptual Direction

Therefore, it’s critical to demonstrate conceptually your new visual direction with pictures of your product experience before and after a system applies. This process must include and even employ members of your community every step of the way.

Early-stage reference designs for the 2012–2014 responsive redesign period.

Pitch a Strategy with a Clear Proposal

A sample system pitch deck, from later 2016

Our typical strategy pitch presentation covers topics like:

  • Defining what a design system is and why it’s important.
  • Stories expressing value, such as pairing the universal And You Thought Buttons Were Easy with other challenges relevant to an organization.
  • Proposed scope, timing, products and processes included in 1.0 release, subsequent product adoption and support, and system development and maintenance that follows (the how and when).
  • Recommended multi-disciplinary system team composition and how they’ll engage contributors and decision-makers (the who).

Get a Commitment to Purpose and Team

  1. Capacity of staff to make & maintain a system, now and after it launches.
  2. Products – often, many many products – to anticipate responsibility for making significant changes sometime in the future.
  3. A community and organization to evolve how it operates, shares work, makes decisions, and more. Organizational change is hard.

We’ll often leave a pitch with direct or tacit approval to get on with it. I’m buoyed even more when a CEO walks up to my in-house peers and I huddling afterwards and says:

What you shared is very compelling and valuable. Great job. Let me know whatever you need to make this happen.

Yet verbal approvals don’t mean starting tomorrow. Sometimes, things stall.

Many factors can slow momentum. Maybe your first pitch triggered a followup pitch to operations and HR to shift staff. Perhaps you have to wait for the next round in an enterprise’s quarterly operating budget process. Or there’s simply a transition period as the system team shifts from product team commitments. Stay the course! Stay persistent! You’ll get there.

With approval, at some point, you’ll officially start making a system.

Launch a 1.0 Release

As essential parts emerge, an alpha 0.1 provides early adopters a sneak peek. As the component library grows, early adoption can commence using beta releases like 0.3 and beyond.

Yet, while sprints can yield incremental releases to solidify your process, your eye is on the prize of the release after which all teams adopt. Simpler libraries can take 2–3 months while robust component catalogs — flexible theming, sophisticated tooling, robust documentation — may take a couple months longer. By the cycle’s end, the 1.0 represents the “big launch” you publicize is generally available to product squads at the ready.

Delivering Scope Incrementally

During that time, a newly formed team will acclimate to a development process to deliver each part, here depicted as design/build in orange and document/publish in dark gray.

For high-level planning, detailed workflows per item aren’t important. Neither is the order or names of specific components in the example above (although, frankly, that’s a pretty common scope and order of delivery). Instead, I focus on how our team is:

  • Delivering parts progressively over sprints.
  • Delivering more parts per sprint later as productivity increases.

What must everyone trust? That the system team will deliver an initial library — dare I say “MVP?” — that can be adopted by a predictable time. That’s why I’ll reinforce repeatedly that we’re on course to launch a 1.0 that delivers a strong visual foundation and 12 to 16 UI components.

Operate Beyond the 1.0 Release

As a result, I’ll be working with leadership to arrange capacity and processes for what’s next as the team is amid an intense first release cycle.

The second development cycle also settles into a regular cadence of planning and delivery, such as quarters of six or seven sprints. The objective isn’t launch an unexpected 2.0, which would be premature and tumultuous. Instead, in contrast with an intense push to 1.0, the team must start to perform with discipline and be perceived as “business as usual.”

Shift from Formation to Operations

  • Extending, optimizing, and fixing defects to maintain what’s there.
  • Delivering new features important to the business.
  • Coordinating and supporting product adoption with training, paired integration, help, monitoring, and reporting.
  • Cultivating community of influence and contribution across designers and engineers.
Emphasizing an adoption plan brings focus to the relationship between a system and products it serves

In particular, helping a product organization adopt a design system requires deliberate, focused, and effortful collaboration. Be equipped with a concise presentation deck and demo, and ready to present it over and over and over. Emphasizing adoption in a high-level plan creates a useful focus on your most important relationships: a system and all its adopting products.

Invest the Program in Regular Time Increments

For each quarter, you could deliver epics like:

  • In Q3, navigation components, patterns, and responsive layouts.
  • In Q4, diverse alert components with editorial guidance, plus motion!
  • In Q1 next year, data visualization, charts, and robust illustrations.
  • In Q2 next year, a broad sub-catalog of hero and content components.

Elongating the time scale even more, mature system programs grow into establishing objectives or themes reconsidered annually and tracked just like any other product, portfolio and program across an enterprise.

This may seem far off or even scary as you get a system off the ground. But even as you deliver essentials first , you can use concepts of regular planning cadence, epics and themes to illustrate where your system journey may go.

About to embark on a design system, or need to dive deeper to discuss products and players? EightShapes conducts systems planning workshops and coaches clients on design systems. Let’s talk!


A collection of stories, studies, and deep thinking from…

Nathan Curtis

Written by

Founded UX firm @eightshapes, contributing to the design systems field through consulting and workshops. VT & @uchicago grad.


A collection of stories, studies, and deep thinking from EightShapes

Nathan Curtis

Written by

Founded UX firm @eightshapes, contributing to the design systems field through consulting and workshops. VT & @uchicago grad.


A collection of stories, studies, and deep thinking from EightShapes

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store