Nathan discusses the first part of his well-tested methodology for creating Design Systems, dealing with starting a new system through 3 steps: setting a strategy, launching a first release and then operating regularly to foster adoption and community (within the organization).
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.
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:
- 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
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:
- Present discovery and survey findings and recommendations.
- Define system and products scope via exercises like Parts, Products & People and Component Cut Up inventories of existing products.
- Discuss models and candidates for system teams and leaders, community participation, and contributions.
- Gather engineers and tech managers to confirm assumptions, choose framework(s), and identify dev environment and hosting needs.
- Roadmap upcoming system activity including reference design concepts, first release cycle process, and how we’ll measure success.
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.
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.
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.0release, 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
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?
- Capacity of staff to make & maintain a system, now and after it launches.
- Products – often, many many products – to anticipate responsibility for making significant changes sometime in the future.
- 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
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.
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.
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
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
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
This ongoing program requires a pivot from a formative to operational mindset. No longer limited to delivering core features, activities diversify to:
- 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.
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.
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.
Reprinted by permission. Originally posted on Medium