Starting a Design System

From Pitching a Strategy to Launching 1.0 and Beyond


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

A design system doesn’t start with choosing a first color. Instead, ground a system in a strategy that discerns customer needs, sets objectives, explores and converges on a design direction, pitches a strategy, and obtain an organization’s commitment.

Diagram of a detailed gantt chart of a strategy phase

Discover Customer Needs

Like any product we design and develop, a design system must address the needs of adopting product teams within the current landscape of culture, tools, existing systems, and practices.

Discovery activities can include:

Engage Stakeholders in Inclusive Workshops

Discovery can lead to in-person presentations and working sessions to summarize progress and gather more input. We’ll convene large groups of designers, engineers, executives and others for sessions to:

Converge on a Conceptual Direction

More often than not, establishing a design system coincides with developing a new visual language from the ground up and applying that language to UI components that product teams agree to use. Your success depends on getting your organization on board with the direction you’re headed.

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.

Illustration of reference designs before and after at Marriott
Early-stage reference designs for the Marriott.com 2012–2014 responsive redesign period.

For more on preparing and presenting concepts, read Reference Designs for Systems: Page Concepts Comparing Before & After, with a System Twist.

Pitch a Strategy with a Clear Proposal

Ultimately, a strategy is nothing if the people that matter – both executives with funds and communities of products that adopt – don’t buy into it. So you must pitch a strategy. And that means creating a presentation deck.

Illustration of a Keynote presentation deck in light table view
A sample system pitch deck, from later 2016

Our typical strategy pitch presentation covers topics like:

Get a Commitment to Purpose and Team

Don’t be shy. You are asking to launch a new product at your organization, so you have to ask. What are you asking for?

  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.

Diagram of a gantt chart with a disruption of inactivity between a strategy and build phase

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

You’ve secured an organizational mandate and a squad of designers, engineers, leaders and others. Scope is clear. It’s time to design, build and document a system sprint by sprint to get to a first release.

Diagram of a gantt chart of a build phase broken into phases (like alpha and beta) and sprints

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

A first release cycles delivers something where there was nothing. As a system progresses, its customers, sponsors, and even the team itself must have an idea of what will done by when as well as comfort in the inexact timing of finishing each piece.

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.

Diagram of a gantt chart delivering features step=by-step across sprints

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:

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

From the outset of pursuing a design system, even as early as your interviews and workshops during Discovery, it is essential to communicate that a design system isn’t a project, it’s a product. It’ll be practiced, delivered, and maintained over time that doesn’t end with 1.0.

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.

Diagram of a gantt chart of a subsequent 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

This ongoing program requires a pivot from a formative to operational mindset. No longer limited to delivering core features, activities diversify to:

Diagram of a gantt chart spanning a first and subsequent release cycle
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

These periods maintain a growing library but must also must continue delivering demonstrable business value. Like a system’s own patterns, planning and delivering the program over increments builds a pattern of newsworthy progress, syncing with products, and roadmapping.

Diagram of a gantt chart spanning many quarterly cycles of delivery

For each quarter, you could deliver epics like:

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.

Need help with your system?

EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.