Design system foundations

We like design systems. They’re indispensable for any reasonably-sized organisation. But we’ve also learned to temper our excitement with a healthy dose of pragmatism.

Sometimes we feel like the grizzled veteran who has to recount our earlier experiences to a wide-eyed newcomer to the design system trenches.

People get very excited about design systems. That’s fair. They can be transformative. But the problem is that people get excited about a theoretical design system that doesn’t exist yet, but will somehow magically solve all the organisation’s problems.

Before getting too excited about this potential design system, it’s worth taking a step back and establishing some foundations.

First off, everyone needs to agree on what this design system is going to be. Some people might be imagining a library of code for components. Others might be thinking of a shared Figma file. Or maybe it’ll be a central repository of documentation.

My favourite definition of a design system is simply “the way things are done around here.” I think it was Jina who came up with that.

That leads into the first hard truth: you already have a design system.

You may not have a component library, or a repo of documents, but if you’re producing designed outputs, you’ve got a design system. You may not like the system, but the first step to having a better design system is accepting that you already have one.

This changes the nature of the work. You’re not going from zero to everything. Instead you’re going to incrementally improve on what’s already there.

And you know what? That’s actually a much more manageable and realistic task.

When we work with clients who are starting out on their design system journey, we begin by talking to people in every department to find out what their frustrations are. But we also found out how much common ground there is across departments. It can be surprising how much tacit knowledge is already there about what “feels right” when it comes to producing outputs.

So the next step is to take that implicit shared understanding and make it explicit. You don’t need to cover every possible interface element. Start with solid foundational ingredients like colour and typography. That’s probably where you’ve already got the most shared understanding.

Now you’ve got a very simple starting point. Everyone in the organisation has a little bit of guidance that still allows them plenty of flexibility. Guardrails, not straitjackets.

Crucially, this guidance isn’t handed down from on high. It’s distilled from everyone’s existing practices. If you try to change people’s behaviour, you’re going to have a hard time. But if you work with people to agree on what documenting existing behaviours, you’re much less likely to face objections.

By getting these foundations right, you’re setting out on the long campaign of building up your design system step by step. It’s not a sprint. It’s not even a marathon; a marathon has an ending. Building up your design system is hard continuous work. But now it’s realistic and achievable.

Like I said, we’ve been doing design systems work for a long time. Check out the very first episode of the Clearleft podcast for more thoughts and opinions.