Implementing interconnected design systems at scale

Overview

Large enterprises and other complex organizations often have diverse needs for their design system across business units, sub-brands, or product lines. In order to create a strategy and implementation plan that addresses these wide-ranging needs while still delivering efficiency and enabling consistency at scale, we need to determine how many design systems the business will need and how they relate and connect to each other. Allocating time for initial planning will help ensure longevity and scalability of your design system, and avoid the fractures many teams experience when trying to do too much with one system or creating unnecessary separation from the start.

There are many models for how this tiering can play out at scale, and no one right answer for every team. This guide will help your team work through the important considerations to determine a model that works best for your organization.

The Opportunity

Typically, creating efficiencies and improving experience consistency are two of the high priority goals teams are looking to address when implementing or revitalizing a system practice. To add a little more detail to these concepts:

• Efficiency stems from reducing unnecessary and duplicative work throughout the digital production workflow and helps teams optimize their time and effort
  
• Consistency stems from working within well-planned constraints during the production process that result in common elements across user experiences - from brand styles and interface elements to functionality and user flows - and helps our users be more successful and create better outcomes when interacting with our business

Both efficiency and consistency are realized at scale through intelligent reuse of existing solutions: reusable styles, components, and even tooling.

The good news - and the challenge - for large enterprises is that there’s no one way to implement a system (or multiple systems) to achieve these goals. We can learn from teams like IBM that have been down this path and seen first-hand that just having a well-built system doesn’t necessarily get us the results we want. With a bit of planning up front, we can ensure that the system we roll out and the infrastructure that supports it are designed to serve the global needs of the business and the individual needs of different groups without sacrificing either priority.

Things to Consider

Below we go into detail on two factors to consider when planning a system effort for a complex organization: how elements relate to each other, and how your internal system users and stakeholders interact with the system(s).

Connections between visual and technical elements of each system

This is all about determining how the elements of the system (visual styles, UI components, underlying tooling) relate to each other both visually (how an end user might experience them in a product) and technically (how they’re actually built and implemented). It’s important to note that common elements don’t always need to look the same. For example, a core button component can be used in multiple experiences but styled completely differently for two different sub-brands, as shown below.

Key Questions to Ask

• What experience elements might be shared? (components, styles, etc.)
• What technical elements are shared? (frameworks, technologies, approaches, tools)
• What technical blockers might exist for sharing assets? (e.g. different tech stacks)
• Are there common elements that shouldn’t be actually shared across BUs?
• For each case, why not?

How users and stakeholders interact with the system

This is all about the information architecture and design of how teams will experience and leverage the system. This may also have a branding element to it - are we saying this is one big system that covers all use cases? Or do we have multiple systems within the organization? There’s no single right answer here, and indeed there is a fair amount of preference involved. For some businesses, it’s valuable to have ‘walled gardens’ where teams only see system elements and resources most relevant to their line of business. For others, it’s more appealing to have full transparency and access for all teams to all elements and resources.

Key Questions to Ask

• How distinct are the brands supported by the different systems?
• How much or little overlap is there across system elements and resources?
• Is visibility into elements not relevant to an internal user’s line of work valuable or distracting?
• How do open or closed approaches align to established company values, policies, or programs?
• How will the systems be managed? Does governance necessitate separation of access? Or can administrators and maintainers work across lines of business in a single workspace or access point?

Planning Your Approach

To determine the best approach for your team, start by getting together key stakeholders and users to talk through the questions in this document. Here’s a sample meeting agenda to help guide your discussion:

Meeting Agenda: Design System Hierarchy Planning

• Introductions
• Meeting Purpose
• Review existing alignment / hierarchy (e.g. brand framework)
• Discussion: opportunities we’re not taking advantage of today
• Discussion: where wouldn’t we want alignment/shared elements? why?
• Discussion: what challenges will impact our success? (e.g. internal politics, technical blockers)
• Questions to be answered / followed up on

Final Thoughts

It’s worth highlighting that there is a lot of flexibility when it comes to how decisions on these factors translate to an implementation plan. Systems can have a high degree of interconnectedness but appear to internal users to be wholly distinct properties. Alternatively, multiple systems and brands can be housed in one reference site, providing global visibility and access from a single reference site or point of access.

It can seem overwhelming at first to know where to start - determining your priorities and developing a common perspective, especially if this is your organization's first attempt at organizing a design system this way. The team members at Knapsack have assisted with hundreds of complex design systems and can help you determine the best approach and avoid pitfalls based on our experience. Don't hesitate to reach out to our team at hello@knapsack.cloud for a conversation about your design system goals.