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.
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.
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:
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:
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.
For more on preparing and presenting concepts, read Reference Designs for Systems: Page Concepts Comparing Before & After, with a System Twist.
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.
Our typical strategy pitch presentation covers topics like:
1.0 release, subsequent product adoption and support, and system development and maintenance that follows (the how and when).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?
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:
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.
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.
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.
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.
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.
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.
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.”
This ongoing program requires a pivot from a formative to operational mindset. No longer limited to delivering core features, activities diversify to:
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.
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.
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.
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.