Working with design systems

Design systems as a field have matured over the past few years. Now you can find hundreds of examples of them, as well as fantastic resources, communities & new tools. I have been working as Design System Lead at Ruter for a few years now, and I’m proud of how our design system has become a truly collaborative cross team effort. I thought it was about time that I shared a few tips, tools and essentials to help others getting started.

Whilst there is no one size fits all solution, there are some elements I consider to be essential to a well functioning system. I really believe that a design system should start with company values, guiding how we approach our work as well as directing how our system should be structured. Secondly, clearly defined design principles will help create resources, and enable those using the system to work confidently and autonomously straight away. I also believe that a design systems governance and contribution model should be in place from the beginning which explains how the team is organised, and invites feedback and collaboration.

A culture of collaboration

I believe design systems should be about empowerment rather than enforcement. A centralised system might seem inviting as decisions can be made quickly and without compromise. Components could be built that one might assume essential, and they could look impressive, but they might not fit with the product or the way the team work. This can lead to a design system which is removed from the product teams and customer needs. A system should have some degree of rigidness to it, but a product focused design system works when it is a reflection of the whole team.

““If you want to go fast, go alone, if you want to go far, go together”.”

I believe that design system teams should have a small core team doing most of the work, simultaneously facilitating others to contribute when needed and appropriate. I think this hybrid model reduces the bottle neck from the central team with work coming into the design system from other teams, and is the key to creating a design system that is actually used.

Instead of working autonomously, design system teams spend a lot of time working with all the product teams. This can be a challenge, but if collaboration is baked into company culture through sharing expertise, insights, alignment of goals, and processes, it can be a lot easier and very rewarding.

Working with the design team at Ruter on our icon library

In my role as design system lead at Ruter I feel as though I help the design team work much more collaboratively. For example, we have a design review meeting each week in which we look at different parts of the design system and discuss changes, new additions and give feedback. Designers often comment that they looked forward to our weekly sessions, and come away from them feeling inspired and informed. As well as this I organise design sprints, workshops, conduct research and invite other non designers into our space to work with us too.

Collaborative touch points

Make sure that there are multiple channels to give feedback and collaborate. As well as regular design reviews, it’s good to have a dedicated #designsystem slack channel, and really get the most of using Figma features such as comments and branching. Try to encourage designers and developers to work openly on shared team files rather than alone in private spaces.

Recently Figma has introduced branching. Branches are exploratory spaces that enable designers to safely try new ideas without making changes to the main, or existing, file. Rather than auto-saving to the main file, changes from branches are merged into the main file when you're ready.

Contribution model

Contributions to the design system should be useful and unique. A suggested component or pattern should be useful for many teams or services and it should not replicate something already in the Design System. It’s a good idea to explain this contribution model in your docs and slack channel so that users understand how and when to contribute.

Being a design system lead can sometimes mean saying no, but not without a discussion around that decision and an explanation why. Sometimes a new component is suggested, but there are a few alternative components already in the system that would work for that use case. Sometimes more research is needed to support changes in the system, and sometimes the answer is not ‘no’, but ‘not now’ as it doesn’t align with the current goals.

If you have a lot of stakeholders and users, it could be a good idea to use a feature request tracking tool such as Frill, Savio or Prodcamp to help prioritise, collaborate with users and share what is being worked on.

Measuring success

How is success measured in design systems? The first thing designers usually point to here is figma analytics, but just having and presenting data about component inserts isn’t enough. The trick is to figure out how to interpret and analyse that data according to the design system goals alongside other more qualitative insights. It’s important to share how the design system is performing, and present any analysis of metrics in a simple and easy to understand way.

Design system goals should be aligned with other team and organisation goals. Including the goals in the design system docs helps users understand the team and the system.

Start with documentation

The first thing to do is start documenting decisions, and making a plan for organising what you have so far. There’s no wrong place to start doing this, whether it’s Google docs, notion or directly in Figma, sharing design decisions from the beginning builds trust and understanding across the company. Instead of aiming for perfection, aim for appropriateness of needs. 

In-line docs

Most design systems start as a small component library in Figma. This is a simple starting point for documenting design decisions and will give design system users enough context to feel confident using the system.

Dedicated docs file

When libraries get bigger, it could be time to move towards a dedicated docs file, this is easier to organise and will help lessen the bloat of the main asset library. It’s still easy to link to the right docs from each component. There has recently been a lot of updates and plugins made available which allow for clearer and better documentation, internationalisation of design systems, accessibility checks and automation, making Figma quite a good option for most design system documentation.

CMS

When working in an organisation with many teams and products it could make sense to eventually move towards having an open CMS that can be indexed. It’s needed when a design system is widely used not just by digital designers, but also by product managers, developers, marketing teams and other key stakeholders.

Most CMS systems have their own Figma plugins that sync with libraries and documentation. This helps automate processes and syncs tools seamlessly. Storybook is a fantastic open source tool for building UI components and pages in isolation. It streamlines UI development, testing, and documentation. Storybook code snippets can be integrated into CMS solutions, bringing design and development even closer together.

Custom

Fully custom solutions are high effort, and not really appropriate until a design system has more of an ecosystem around it. Stripe is a good example of this, as they have 3rd party developers creating stuff from their design system. It is a complex solution, and often not needed but important to consider as a product develops.

Describing components

Documentation should always start with foundational style guidance around colour, typography and other patterns that flow through the whole design, detailing also how the values and design principles work with the profile. These core elements of the design system (or atoms if you are familiar with the concept of atomic design) can be used to create design tokens which are then used to develop components. The design system should have a defined naming structure to guide the way every component is built up. Naming is a notoriously difficult thing to do and is debated passionately in the design system community, but alignment on how elements are described increases understanding and breaks down silos.

Examples and variations should be incorporated into component usage guidelines. I find that do’s and dont’s are helpful in quickly exemplifying component use, as well as referring back to the foundational style guidance and patterns. Accessibility features or considerations such as what happens with keyboard navigation, tab orders, or how the components work with screen readers should be incorporated into examples and documentation for components rather than in a separate accessibility section. This keeps accessibility top of mind instead of an afterthought.

Resources

There are so many great examples of design systems. Some of my favourite public ones are Atlassian, Polaris (Shopify), Carbon (IBM), Adobe spectrum, Orbit, Workday Canvas System, and Stripe Docs. You can watch a video of me talking more about Ruters design system here, and designsystems.com is a fantastic resource for articles and templates.