Just do it

We all see the large, mature, shiny design systems out there but we don’t really see what went into creating them. If you feel creating a design system is right for your organization or that task has been given to you, seeing systems that are mature and reading a lot of blog posts that tell you how you can do things at scale, it’s often hard to see the wood for the trees.

What’s your problem?

While it’s great to take influence from other systems and there is so much good stuff to digest out in the blogosphere, before diving into creating anything or using any as a model for how you’ll proceed, it’s word pausing: what are your problems that you feel a design system will help address?

There’s a huge amount of variability in the scenarios that people find themselves in when making design systems from small agencies working with clients to huge multinationals; from being well backed and supported to flying by the seat of your pants with what little time you can get side-of-desk. Being clear first of all on the problem space gives something tangible for everyone around the project to engage with.

A lot of where design systems struggle is really people problems; more around how people communicate and collaborate. That manifests in how decisions are made between designers and developers but also with buy-in from product teams. This isn’t the kind of thing that can be solved overnight but right from the beginning, it’s this design of people systems that helps us to arrive at a viable solution and take people on that journey.

Sharing is caring

The whole notion of a design system can seem overwhelming but not every aspect needs to be solved right from the beginning. Sometimes it’s about how you can share stuff that improves the quality of the experience the end users have. You might not have the space to work away on design tokens or complex components from the beginning but experimenting and learning with workflows and components can be invaluable. It doesn’t even need to be labeled as a design system at that point just ‘how can we do this better, together?’.

It might be that you don’t have your color palette nailed down yet or got bogged down in talking about naming conventions and that’s totally fine! Getting something out quickly as a proof of concept grounds what may become a design system in something tangible and real. As Dan Mall said in his talk at Converge, it doesn’t matter what you agree on. It just matters that you agree. Forming a consensus can be really hard but better to agree on something, give it a try, and learn then improve it later. The mechanisms we establish with how decisions are made as a collective can be iterated upon as much as our design artifacts.

It’s about time

Talk of experimentation can sound like a timesink for those that don’t have much time they can devote to getting a design system off the ground. Objectively looking at the problem space you’ve defined and focusing on one things can be a win can help the whole idea gain traction. A design system isn’t a thing you can or should take off the shelf (though there’s plenty of UI kits that might form part of your solution), a win for you might be quantifying problems that currently exist that in some way working together might help ameliorate. This solution may end up being a design system.

If there’s one thing you could do, just one, what would it be? As Dan also mentioned in his talk, you could pick the most tough or gnarly component and get that out over something generic like a button. Is there something of value you can create for the end user you can use as an example of how to work collaboratively, often in a way that structures haven’t previously enabled as well as they might. Providing something of value also doesn’t mean it’s the perfect solution or made in the ideal way. Once it’s there and gone through a process from conception to design, code to QA, that should be a repeatable process that enables iteration. Be prepared to be wrong.

Scrappy starts

A blank sheet of paper can more of a hurdle that having something imperfect to critique or improve. You don’t need to solve every problem at once! Stash ideas of areas to explore and understand why things like atomic design and design tokens exist and what problems they aim to solve to you have them in your toolkit for when or if a time comes.

If you’ve made one component better…maybe your site’s header and navigation…that can be a vehicle for starting so many of the bigger, slower changes. There’s an actual thing live that people can point to that has been improved and can be changed more quickly than it could before. Do it together. Break it together. Take the win and use that to have those more detailed conversations around colors and typography. Be prepared for those to be wrong the first time or first few times you try and do them. Set the tone that experimentation is part of the process, balanced with offering the end user and everyone along the workflow something even a little better.

Shiny and oh, so bright

You first design system might not be branded and shiny. Maybe it never will. That’s OK – you’re solving your problems in your organisation in a way that you’ve done from the inside as collaboratively as circumstances allow. Document your choices along the way and use that as a way of validating with teams each time they try to use anything from the system; use it as an on-boarding tool and improve it each time someone has feedback. Having a few things that people know how to use is ultimately better than 100 design tokens that people need domain knowledge or tooling to use properly.

How cool is this? You can make things better by just trying to create a design system. It doesn’t have to be in any way like a big, mature system. It can just solve your problems and make your stuff better. Maybe one day it will be shiny, but it’ll be on your terms.