Sometimes, because we care deeply about our craft, all we see can be chunks of familiar-looking UI elements collated in component libraries. Buttons and cards, tables and inputs, typography and…whatever that is. Maybe this design system will be better than the last?

When we look straight at the visuals, maybe through an audit or onboarding to a new system, I feel like we miss a lot. For a start, the visuals are from a later stage in the process. At some point, a layout or user journey was worked on for a product that produced or needed this element. Why is it here? From our audits as we broke down the journeys and looked at these elements dispassionately, we spread out the work our users engage with daily to look for the familiar — patterns we could refine and componentise.

The Five Whys is always a favourite tool to dig into things a little deeper and it can work well for every part of our design systems too. We can have a huge range of colours made available in our foundations but…why? Maybe only a small number are actually in use…so why all the possible extra values? This one specific colour (could be any) — why is it in the system? What does it represent? What is the intent behind it?

I’ve been lucky to not just have my own experiences with design systems but to take on board those of so many in our community. Sometimes, I might come across a team that has spent months perfecting their colour ramps. All kinds of combinations possible, all well presented for the next layer of usage…but why? That’s not to say having everything in good order is at all bad or the wrong way to go about it, but often this work not only encodes the values used in the product today but many values that may never be used. Why?

Maybe we unlock some creativity that was somehow held back…or something. In asking why so often, it’s being clear on ensuring what we have in our systems is useful and has purpose today. If we do our jobs well with the set-up and processes we put in place, we should be able to add and amend the contents and artefacts within the system, so maybe we don’t need so much now.

Components aren’t just chunks of UI we stash in a bucket like Lego, they’re solutions to problems we’ve already come across. A card isn’t just a card — though I’m sure like me, you’ve seen loads of sites throw all kinds of content in similar-looking design patterns. What use cases do we have for our cards? Are these use cases different enough that they would benefit from a different design approach to better communicate that to our audience? Perhaps we now have two cards to solve two distinct problems.

By asking questions about what we put in our systems, we should be clear on their why, their purpose but also their use cases, and their intent. With our generic card, we could use that for all kinds of content…but why? It’s easy for us but maybe we create ‘card blindness’ as they’re used all over for all kinds of reasons. Difference in design systems isn’t a bad thing, they can just turn out that way if it’s not managed or done with a clear explanation. It’s not a bad thing to have 3, 4, or 17 different cards, so long as the designers and developers that consume the design system are clear which helps them meet their needs and communicate and engage their users.

These whys and hows give us purpose and intent so as consumers of the system we don’t need to ask ‘What is this? what is it for?’. Learning, adapting, and in some cases diverging are part of evolving our products and so essential to a design system. It’s no good being scalable, improving consistency and all of that good stuff is that just reproduces how things are at the moment. Change needs to happen and the system should not just allow for it but encourage it to happen.

So we dive deeper: Ahhh buttons…the core of all of our systems! A button isn’t just a button, it’s a microcosm of everything we go through with design systems: states, variants, sizes, typography, colour, accessibility, and so on… While often not a great example to really communicate about design systems, they do remind us of the huge amount that can go into something so small. They’re everywhere and often really key to what we’re creating. Why is this button in the system? Why does it need multiple variants? Have we captured all of the states? Have we done the typical thing of designing something to look like a button when it works like a link?

If our components are solutions to problems we’ve already encountered then higher-level components can be more specific in their naming and use cases. If we look at a simple newsletter subscription component, it’s not just a text input with a label and a button with some text around it, etc. These things put together form a composition that is a solution to a problem, in this case: ‘How do we get people to sign up for our newsletter?’. As a consumer, it’s pretty clear what it does! This ‘back box’ of a solution can be included through our design tools and code but still aims to meet that brief, so the intent and purpose still stand even in the design and implementation change.

Yes, on the surface we have a collection of interface bits and pieces. We don’t always need all of them. We should always ensure they’re solving our problems, just including what we need, not over-engineering for potential futures. Asking why, capturing everything’s purpose and intent gives us something solid to work from — and a useful comparison when it’s tempting to make an existing component do something extra to meet a new use case. You might have less in your component library but it’ll be really clear why every element is there and when it should be used…and opens the door to solving problems in interesting ways by encouraging challenges to the status quo.