When reaching customers through multiple channels it's important to present a consistent brand image and user experience. However, implementing and maintaining this across all digital products is no easy task. All of your applications, all run by separate teams, need to stay synchronized. We recently worked with The Economist to help create their design system, a central component library that would act as a single source of truth for reusable components.

Previously components were developed by separate teams as they were required in each product. Not only does this lead to inconsistencies, it results in duplication, meaning wasted engineering effort. By having a central repository keeping a consistent brand across the business is simplified and the speed of development is increased.

The new library consists of individual React components each with accompanying styles. Along with these are a set of guidelines on implementation. Just because all applications are using the same components does not mean you have a consistent design so it's important to focus on how components should be used alongside each other.

Adoption

One of the biggest challenges, particularly to begin with, is adoption from the various digital products across the business. There’s no point in making a library of reusable components if you have no consumers. It can be useful to start off with some smaller products within the business. These can act as a proof of concept while also identifying any teething problems. We were fortunate enough at the time that the flagship product, economist.com, was undergoing a rebuild. This gave us the perfect opportunity to begin integrating our components from the start. As an added bonus having such a large product within the company as one of our consumers made it a great deal easier to convince other teams to get on board.

economist.com homepage

The masthead, section headlines, links, and dividers are just a number of design system components used together to create the homepage. All the while following the style guidelines for page layouts.

The majority of products are not going to be in this position and will already be heavily reliant on their own existing components. As a general rule we say that all new products should begin by adopting the design system. We worked alongside the more mature products to find a path to begin adoption. This could be as simple as using a basic button component from the design system and then gradually integrating further. Alternatively you can approach this from a different angle. Sometimes an existing project would contain a component not yet available in the design system. If it’s something that would be beneficial to other teams then it makes since to migrate the component to the design system. At The Economist we did this on a number of occasions, tweaking the component where necessary to meet our agreed code standards and be fit for wider use across the organisation. This can be a useful tactic if you have limited engineering resources and are unable to build a required component immediately. Allow a team to develop a component locally in their own code base and then migrate it into the design system when you are able to do so.

Removing barriers to entry

If you’re trying to convince teams across the business to use the design system then it helps if integration is as simple as possible. We deliberately used technologies which were widely used across the organisation. These included React, Next.js, MDX, and CircleCI. This makes it easy for developers from other teams to understand and contribute to the code base. Good documentation is also incredibly important here and we put a lot of effort into keeping this up to date. If a team encountered issues we would then feed that back and update documentation and code examples to prevent similar issues in the future.

Along with the design system code repository we also built an accompanying website to document design guidelines and the existing components. This acts both as a tool for developers who are looking to implement components and for stakeholders who just want to browse through the library. Each component page consists of a live component preview and editor, a set of usage guidelines, and finally a list of all component properties.

Design system website

Communication

For the library to be successful in an organisation, clear communication between stakeholders is vital. Not just for onboarding during adoption but continued governance and upkeep of coding standards. The best way of doing this can differ greatly between organisations based on a wide variety of factors including company culture, employees working in different timezones, and the stage of the project you’re currently at. My advice here is to try as many approaches as possible and not force one particular method. We began with fortnightly demos. To begin with these worked well but as we got stuck into the churning out of components and more consumers were based in different locations, attendee numbers began to drop. We decided to scrap these and instead send out regular updates of work completed and rely more on ad hoc meetings as they were needed. For example we would organise one of these when a new team was looking to use the design system or there was a request for a new component. Like many organisations the technology teams at The Economist use Slack as their primary communication tool. We’ve set up a channel dedicated to the design system. This is usually the first place stakeholders will post queries. Additionally we use automated messages here to notify consumers every time a new version has been released.

Slack channel updates

Moving forward

At the beginning of the project it made sense for components to be created by a core team of engineers dedicated to the design system. This allowed for quick decision making and rapid development to get the project up on its feet. This was important as it allowed us to demonstrate to stakeholders that we had a viable product and the benefits that it could give. Moving forward we look to encourage engineering teams across the business to actively contribute more regularly. To some extent this happens naturally, the more teams consuming and invested in the design system the more they’ll be inclined to contribute, update and add additional components. Communication and collaboration are again vital to maintain overall quality. Regular governance meetings or workshops can help with a representative from each of the key stakeholders.

Key takeaways to get your design system off the ground

Assign a dedicated product owner

Someone who can focus on obtaining buy-in from the business and drive adoption from products within the organisation. Getting a flagship product onboard early will make this easier.

Agree on a set of standards and system of governance

Choose technologies that are already widely used. Involving developers from other products when setting out coding and contribution guidelines will help with integration further down the line.

Set up clear lines of communication

Assign a respresentative for each product and organise regualar events for showcasing work to stakeholders as well as allowing time for feedback. Using a tool like Slack to setup a dedicated channel allows you to quickly update consumers while giving them an easy way to submit queries.