Our design system is helping us build the next generation of digital products

At The Economist, we’re building a new generation of digital products. We’re investing in teams of designers, developers and researchers to create apps, websites, newsletters and more that better showcase our world-class journalism.

Our legacy products were designed and built by disparate teams over the course of many years, without a holistic view of the experience. Technological obsolescence complicated efforts to update and align our products. If they are to feel purposeful and connected, they need a consistent user experience, unified by a familiar visual language.

We’re creating a design system to establish this visual language. Here’s how we’re doing it, and what we’ve learned so far.

Documenting our visual language has historically been done with branding guidelines. These define our values and tone of voice; explain our use of colour and typography; demonstrate graphic devices and brand identity; and set out the rules of application.

Our guidelines are static documents, largely focused on the brand and its application in print. With any type of branding guidelines, there are challenges to distribution and adoption. It is difficult to maintain consistency across products and ensure changes are synchronised. This is especially pronounced in digital design where iterations are frequent and far-reaching.

Similarly, developing products independent of one another increases the likelihood that engineering approaches and quality of code will splinter. As teams may not have a way of sharing their code base, common components may be repeatedly rebuilt, without a guarantee of uniformity.

A design system is a living document in software and code. It is always up to date and new releases are immediately available to other products; a so-called “single source of truth”. As well as including all brand attributes and interface components, a design system contains the principles, standards and best practices to deliver a consistent user experience.

We talk about our design system as a singular product, but it is a sum of parts: a toolkit for designers to help craft the user interface; a component library for developers to utilise and contribute to; and a public-facing website where anyone can easily browse the system.

UI kit

To help designers achieve consistency across our products, we’ve created what is known as a UI kit: a graphic file containing user interface (UI) components and patterns. We use Sketch, an application for designers, to build the kit and synchronise a library of resources across computers. The UI kit defines our digital colour palette, typographic scales, grid layouts — and our design principles. These principles clarify our aims and guide our decision-making.

By working from a shared UI kit, designers and researchers can quickly mock up ideas and prototype features using established patterns. Having transparency on agreed solutions avoids reinventing the wheel every time, allows early input from developers and cuts down on variations in style. For quality-assurance teams, the kit is a reliable metric for testing.

Component library

Components are the basic building blocks of our design system. They are completely modular and independent of pages, groups or context until combined, when they begin to form patterns and a meaningful interface. For example: a button isn’t useful on its own, but join it with a text input, headline and description and you create a pattern for a signup form.

We’re building a centralised code repository for all our designed components. Each component in the library includes all of the necessary markup, styling, scripts and tests needed to use it in a product. A product team can import the components they need, and contribute their own components to the system. Our colour, grid and typography values are stored in a set of named variables called design tokens, accessible by all teams.

With a component library, it is simpler to maintain code consistency and avoid duplication of work. A library provides a practical way of naming and organising components that extends from the design files, and includes front-end guidelines and accessibility standards.

Website

While these are practical tools for designers and developers, it’s not as straightforward for someone who, for example, needs to refer to our brand identity, or quickly browse the library of components. We’ve set up interim solutions, but our long-term goal is a public-facing website that anyone can visit — whether that’s internal stakeholders, marketing, third-party vendors or simply someone interested in our work. Watch this space.

Over the past few years, design systems have come into their own and most organisations now recognise the need for one. Some of the best known examples have come from business (Google, IBM, Salesforce, Shopify, Atlassian) and from government departments in America and Britain.

These organisations, and others, have documented their successes and failures in books, articles and talks, building up a wealth of advice for others to follow. Although the process is unique to the structure, size and culture of your organisation, there are common recommendations for making it a success, and we’ve seen these reflected in our experience. Here are some lessons we’ve benefited from:

Get stakeholder buy-in

From the outset, it’s essential to get buy-in from the people who will create and use the design system: designers, developers, content and product owners. There is a trade-off with a design system. It requires a considerable amount of effort at the beginning, but that cost is outweighed by the long-term benefits. It is hard to quantify the success of a design system immediately, and having a store of good faith can keep it going as it inevitably competes for resources with consumer-facing products focused on revenue and engagement.

It’s also important to have an advocate for your design system. When ours was still just an idea, I spoke with teams across the organisation to explain why we needed a design system and the steps we’d need to take to realise it. In each meeting, I listened to the team’s needs and discussed how we could work together. Crucially, I was given the support I needed by management to plan the system architecture and build out the UI kit, which kept up momentum until we were in a position to start on the code repository.

Dedicate a team

Once I had stakeholder buy-in, our product leadership agreed to recognise the design system as a product in its own right: a product for products. This enabled us to set up a dedicated team with the expertise to understand who the product is for and how they’ll use it. Time is budgeted so that team members (who also have commitments on other products) are not overburdened with work.

A design system is as much an engineering project as design: our team is supported by a tech lead, a delivery lead, and a rotating cast of engineers. And as with our other products, the team follows an agile process, regularly refining priorities along a road map.

Find pilot projects

With both our UI kit and the component library, we found pilot projects where we could test patterns and behaviours early and often. This set up a feedback loop, enabling quick iteration and a method for validation.

Our first trials were with the account-management area of economist.com, followed by our customer store. Both helped us identify gaps in our library and allowed us to test emerging patterns, such as form elements and interactive controls. By putting components together in context, we discovered issues we couldn’t have anticipated when designing them independently.

As we started building the design system, some of our product teams were well into their design and development cycle, and weren’t able to immediately start using it. We’ve discussed ways to manage integration in respect of their road map, and encouraged each team to begin contributing directly to the design system.

Agree governance

A design system requires collaboration and contribution. In order to build out at scale and encourage adoption across products, a design system needs governance: a team with clearly defined roles and responsibilities, supported by documents that explain how to use the design system and contribute to it.

Our governance is centralised, in part because our product and design teams are small and cross-discipline, but also because our designers are together in one place, under the guidance of the art director. As we expand the design system, we will establish a working group to manage the new platforms and channels that join.

We found that getting a process in place of contributing to the design system took longer than we expected, and caused disruption for the first team trying to fully incorporate their product with the component library. That experience helped us to understand the complexities of integration and that a design system, as a product closely joined with other products, needs to anticipate and adapt to the sometimes unpredictable realities of product development.

We’ve created a system to unify our visual language and give readers an outstanding product experience. Within the organisation, we’ve had positive feedback and teams are genuinely eager to get involved.

We haven’t always been able to meet expectations. We’ve made great progress but it’s taken nearly a year to get to where we are, which delayed access to the component library.

However, we’re confident our work will mean a better result in the end for all of our products. And we’re beginning to see a return on our effort: the forthcoming release of economist.com, our iOS and Android apps, store and newsletters all use the design system. We’ve found that having something that others can start using, even if all of the finer details haven’t been worked out, is better than being held up by the particulars of a long-term strategy.

As more teams adopt the design system, they bring their own expertise and contributions, which helps us improve the product and scale it to meet organisational needs. From our flagship consumer products and sibling publications, to our corporate channels and third-party platforms, we’re starting to roll out a unified visual language.

Our next step is to launch the design system website, where anyone who is interested can delve deeper. We look forward to sharing our work and hearing our readers’ feedback.