Can you start a design system if you’re not a designer or developer?

When we think of design systems, we tend to think of them being either design or development-led as these specialisms are closest to the creation and work in the systems themselves. What if you’re not in either of those areas but recognize that a design system can really help your organization?

While you might not be able to create components yourself, there are some fundamental things you can put in place to help the formation of a design system and a group of people around it. The best part of a design system journey is bringing people together and using it as a way to work more collaboratively, so here are some things you can try:

traffic light illustration – stop

Identify the problem space

Design systems can fall into the category of being a buzzword so what is it you think a design would give to your organization? What problems do you think it might solve? Establishing a view of what issues you have as a collective and getting more input can be a really useful means of starting the ball rolling. Is everyone seeing the same thing? Can workflows and processes be improved?

It’s a great opportunity to get some clarity around some fundamental questions like:

• What problem(s) do you think a design system might address?
• What goals are you trying to achieve?.
• What would make this design system successful?
• How could your design system fail?

Audit all the things

Looking at the way things are and laying them out can help validate your assumptions of the problem space. You can audit workflows and processes to see where existing pain points might be, which is useful to refer back to when you have proposed solutions (such as a design system). Most commonly, doing a cursory audit of your site or app can be a useful starting point to illustrate what could benefit from some improvements. Often that can serve to illustrate where there are inconsistencies, duplications, or unloved parts of the site. You can do this in any way that feels comfortable from print-outs on a wall so a collaborative online workspace such as FigJam, Miro or Mural. Much as with identifying the problem space, it’s a process of giving clarity to what exists, and where the potential issues are so it’s clear what a design system can do to help.

Without being a designer or developer, you might look to atomic design and see how you might classify the parts of your site you discover and break them down into smaller parts. In most web browsers, you can right-click on your mouse to inspect the source code that makes up the website (like this in Chrome). If you’re confident with that, you could grab the colors and typography used to give greater depth to the current state of your users’ experience. If you’re someone that has technical experience, getting the lay of the land with what codebases exist, what exists as components and what workflows exist can save a lot of time later on. It’s not uncommon to have multiple implementations of similar looking components scattered around multiple codebases, especially in legacy projects!

As part of this rounded view of the current state of play, look at what tools are used across specialisms. Do all designers currently use the same design tool? Aside from codebases, are there constraints that developer tooling might impose on any emergent system?

traffic light illustration – amber

Document it all

OK, you’re reading this on zeroheight so we’re bound to say that documentation is important but in some way capturing all of these findings and having a space to collate when decisions are made is invaluable. Having a single URL for anyone that’s interested to get up to speed with the design systems journey and contribute can help with that awareness and so adoption later on.

At this point, we’re not looking at documenting components or design decisions as those areas would benefit from working collaboratively but establishing some principles and signposting language can be a great starting point. It is also a great tester for people to see that these things aren’t carved in stone and can (and should) be changed over time. Going back to the audit of workflows and processes, it might be quite easy to collate some do’s and don’ts, some guidelines for what the system should be and also what it isn’t.

Going further, there’s aspects that could be started as an individual but fleshed out laster as a team or collective. Even at early stages, it’s worth considering how governance might work in your context and what you imagine a contribution model might be for your team or teams. Through our audit stage, we have a sense of the shape and constraints of our developer-designer ecosystem; who the people are, how they work, the tooling and processes. All of this is really useful stuff. As time moves on, it’s also a great barometer of where things were before the design system.

No people, no problem

Well…not exactly. If you don’t happen to have designers, developers (or both) maybe there’s a limit to what you can do on your own. You might not have a well-structured, considered set of values and components in a design tool or robust, accessible components in code. The audit you did earlier can have value: document these things; explain as best you can what they are, how they’re currently used, and any views on how they could be improved.

You might have a date picker component (or may different date pickers) – drawing attention to their purpose and intent as well as their use cases has value. This visibility can empower people to make better choices. You might not be able to resolve every inconsistency or issue quickly but knowing what the problem is is half the battle. Encouraging ‘boy/girl scouting’, the notion of leaving things better than you found them can chip away at this mountain and often not add overhead to day-to-day tasks. In some cases, the visibility that this proto-design system offers up can save time.

traffic light illustration – go

Now you’ve started…

At this point, we don’t have a design system but we do have a clear recognition of the problems that a design system might solve and have a view of how things are today. There is a point that designers and developers are needed to make this a proper design system but even without expertise in those areas, you’ve made a great start.

The journey to getting here often involves talking to other people in parts of the business you might not normally come into contact with; it involves some work to get that collaborative environment around this work. Maybe you don’t even call it out as a design system at first but laying the groundwork for making things better in some way.

What this research and documentation can do is serve to convince others that there are problems that can be solved. It may even be possible to find a way in through getting clarity over when you could tackle first that would give your organization the most value. The clarity of the problem space can give focus to something more tangible that then makes a design system as a solution resonate – it’s not a case of needing a shiny buzzword but this concept could materially improve the way we work and the quality of our output. That clarity can lead to the investment of attention, time, and even funding – perhaps becoming its own team. Getting started can be the hardest step but applying it to your problems in your organization prevents the feeling that it’s a mountain to climb for little benefit.