The design system of systems: A scaled approach that works for enterprises
Reading time: 5 minutes
Fighting organizational complexity is a losing battle. For enterprise companies, their complexity is their strength — multiple product lines, international footprints (and even multiple subsidiary businesses), all work together to reduce risk across the breadth of the organization — and help the company span multi-decade or even multi-century changes to their markets.
However, the strength of the traditional enterprise is usually pitted against the agility of the new digital world. Enterprises are urged to “act like startups”, though they can no more do this than they could steer a ship like a sailboat.
This is especially true when an enterprise is building and attempting to scale a design system. The reality is that a single system is never going to work across all of a company’s digital product lines. In spite of this, over the past few years, enterprises have been coached to attempt to build one monolithic design system for all their product teams to use.
This is time- and money-wasting advice. Instead, enterprises need to embrace their complexity and build a design system of systems — one that can be tuned to each product or product line, while also maintaining brand integrity across the entire organization.
Building a system of systems
Recognizing the complexity and building a multi-level design system that accounts for the reality of enterprises might seem like a monumental task. However, in our experience working with multinational corporations, we’ve learned a few key lessons that we’re ready to share with organizations that may be struggling with their own design systems.
Lesson 1: Choose tooling that fits your complexity.
There are plenty of enterprise-level software systems that claim to have all the bells and whistles your teams will need. While the sales pitches are enticing, the reality of the teams who actually create your digital customer experiences must be considered. Ensure that as you choose tooling, it’s in consultation with the customer-facing teams. Conversely, some popular products on the market will lack all the functionality your teams will need to create the best customer experiences. It’s important to have a clear picture of what you want to achieve with your customer experiences, and the skills and abilities your teams possess, before you make any decisions about your enabling technologies, so that the tools really do enable your teams, instead of constraining them.
Choosing headless CMS platforms, for example, is often recommended when companies need: 1) the greatest level of flexibility; 2) to build highly customized applications and experiences for their customers; and 3) the integration of several systems and platforms across multiple environments.
Conversely, enterprise platforms can be a good choice for companies who have a smaller digital footprint, and whose websites are mainly informational, without ecommerce needs or integrations with other software.
Lesson 2: Start your governance planning on Day 1.
In a system of systems approach, a thorough governance model is essential to ensure that the adoption of the design system is both widespread and intentional. The governance model dictates the processes for decision-making and workflows, as well as who can contribute to the system (either at the main system level, or any of the product-level extensions), and how enhancements to the system will be built and communicated to the impacted stakeholders.
Ideally, in a system of systems scenario, there will be a design system core team that leads the project, encourages adoption and contribution, and manages the ongoing governance and communication to all product teams. Leaders in these organizations will have to consider whether these skills already exist, or need to be hired. Also, while this team will be responsible for communication and creating alignment, they will need champions at the executive level to ensure their own needs and those of the design system users are being met. This extends to when the design system is built and ready to roll out and scale. There may be new responsibilities for the design system team, and others they will have to give up. Careful guidance will ensure a smooth transition, not a culture shock.
In sum, it’s important to reiterate that the design system should be managed like a product, not a project. Especially with the design system of systems approach at a large, multinational or multi-location company, gaining that alignment and focus on the outcomes is essential.
Lesson 3: Thin-slice the rollout to avoid culture shock.
Thin-slicing, a technique we outline in our book The Better Way: Transformation Principles for the Real World, is used not only to narrow the scope of a project to an achievable outcome, but most of all to ensure that the outcome is both transformational and requires the organization to collaborate across multiple levels. It has serious benefits for learning, for speed and scale, and allows companies to invest smarter — making smaller, iterative bets on outcomes, rather than large, long-tail investments.
A design system is an elephant, and it’s got to be eaten one bite at a time. A design system of systems (if you’ll come along on this metaphor journey with me), is a whole herd of elephants. It’s essential therefore to look for ways to tackle the work that not only make it easy to understand and digest, make it executable and measurable, but most of all, make it in alignment with the company culture and not adverse to it.
A successful design system necessitates a culture shift at a company. The system of systems will cross geographic locations, product suites and lines of business, making it a huge determinant of culture. In this sense, it’s possible to use the design system to change the culture for the better. But strong resistance to change will ensure the design system of systems is never adopted properly, and will mean missed opportunities for return on the investment in building it.
Choosing where to begin
A design system is not the pet project of the design team, and it’s not a simple component library. It’s a powerful and transformational internal product that has business impacts across the organization. It’s essential to ensure that it’s tied to the executive vision, and is built in support of company-wide goals.
During the roll-out of the design system of systems, it’s also critical to tie its use to the business unit strategy and the value those units are trying to bring to market in service of the customer. As much as a design system is an internal product, its value is in saving time, money and effort expended to build customer-centric digital products so that internal teams can stay focused on customer problems and the solutions to those problems.
Most of all, the design system of systems should be built with the future state in mind. Where are you trying to go (or grow) as an organization? A design system of systems, as part of the roadmap of a digital transformation for large enterprises, is a tool that can help you get to that future state. Start small, dream big, and take the journey one step at a time.