What is a Design System Anyway?

An interview with Yavor, a Designer at Marvel, breaking down the what, why and how of Design Systems.

‘Design Sprints’, ‘Agile’, ‘Stand Up’, ‘Lean’ – Is ‘Design System’ just another one of those buzz words we hear?

It really depends on how you choose to look at it. I find that everything that’s ‘trendy’ or ‘buzz-wordy’ is usually so for a reason. There is a lot of innovation in the design systems space at the moment hence why there is so much talk around it.

There’s plenty of reasons why this is happening, to name just a few:

All of these are real problems we face on the day-to-day that have pushed us to develop new technologies, seek out new ways of working and new ways to better manage and scale design.

These are just some reasons companies started investing so much more in the design systems space. However, because it’s a new term, it’s meaning and process is still unclear, vague and inconsistent – which is why we’re seeing a flare in discussions, buzz and occasionally a good ol’ meme.

Design Systems Meme

Let’s imagine for a moment that I’m an alien, now explain a design system to me.

I doubt that aliens have to worry about design in the same ways we do but I’d actually love to see what challenges they face!

As far as I’m aware, there isn’t a formal definition on what a design system is. I think because the problems it solves (particularly in the digital product space) have emerged fairly recently – so to try and explain what it means for us at Marvel, I’ll give a real-world example.

We have a bunch of products that all have separate codebases and more or less separate teams/owners:

We also develop and support a few static sites:

Using our own API, we build and ship integrations and their marketing pages like these:

We also send out HTML emails daily:

We also have different teams collaborating on a daily basis:

With all of these different platforms, channels, teams and processes involved, there are a range of challenges that surface. For example:

We’ve created a system that manages all of this and most importantly evolves with it. It lives inside all of our products and web apps, but is a separate entity entirely. That means maintenance is done in one place and almost eliminates the need to think about design processes and workflow when working on a product.

How does it work?

The following flow chart goes into slightly more detail – but please forgive my vague terminology:

We have a bunch of design values for colors, typography, layout and more, structured in a simple JSON format. From there, we send them to a few places. On one hand, we have a Swift Styleguide Generator which generates the design values consumed by our iOS and Mac apps. On the other, we have a simple atomic CSS framework, which then gets consumed by anything that uses web technology; be that React, PHP or old school email table templates.

We also manage design work with Abstract and use shared libraries extensively to distribute the same UI kit into everyone’s projects. We’re also experimenting with sending out our live production components into Sketch, instead of recreating them manually, demonstrated with the dashed lines in the diagram.

This diagram is an example of what our design system looks like. Other companies will have different needs, so a solution might look entirely different. Simpler and more elegant, or twice as complex.

Of course, there’s a lot more to it than a simple flow diagram. For example:

For further reading, I would recommend this article by Varya Stepanova which goes into a lot more detail on design system terminology, which in our case is a little all over the place! Another great read is the design systems book by Alla Kholmatova.

What are the advantages of using a design system?

I briefly mentioned some of the problems we faced before building our design system earlier. So the advantages work out to be solutions to the mentioned problems such as shipping consistent and accessible products across different mediums, reusing and maintaining code and design in a more efficient way. And of course, improve cross-team collaboration.

What have you learnt from building a design system?

Building a design system that scales well as the team grows is challenging. Doing the same thing whilst the products grow in scope and complexity is even more so. It takes a lot of time and effort and there always seems to be hurdles in the way.

What I’ve realised in the past two years is that treating the design system as a separate product is hugely helpful. It needs it’s own requirements, it’s own set of features, a solid roadmap and clear prioritisation.

For example, our pattern library is not something we’ve built and left in the wild. It evolves every day, there’s an ever-growing backlog of feature requests, just internally, and we haven’t even open-sourced it yet. So managing all of these things whilst making sure the products that consume it’s APIs stay consistent, don’t break or look odd proved to be the most challenging part for us. At the end of the day, it’s a mixture between design and software so it needs to be treated in the same way.

Other things that I realised were crucial to the process, especially when time and resources are tight, were:

Lastly, it might sound very obvious, but I’ve noticed that anything new that’s complicated (a UI kit or a pattern library, or even design process for that matter) will be slow to get adopted – unless enforced religiously.

If it causes overhead in learning and takes time to get used to, people will get confused and ignore it. Reason being is that everyone wants to get their job done fast, which means they’re more likely not to invest in something new that slows them down in the short term. It’s just hard to see the long term efficiency gains. Any deviation from regular workflow is going to need some time for adjustment, so making sure your solutions are easy, understandable and straight forward might be a challenge too.

How does somebody even begin with building a design system?

Another question I have no concrete answer for as every business is different but I can share how we went about doing it. The first thing we did was an audit of the existing brand, products and user interfaces.

When we started building our Styleguide, Marvel had already been running for two years. By that time, it was an established product which already had a good, consistent design which people loved and enjoyed using. However, it was getting to a point where major features were being introduced and turning it into a platform, rather than a single product, so the need for consistency was becoming more and more essential.

We did an audit of the existing codebase and identified quite a few problems which Colm Tuite summarised in his post on how we built the first version of the Marvel Styleguide:

From there it was deciding on tech and our approach to solve the following problems:

  1. Build a framework to unify all design values
  2. Build a pattern library to make existing user interfaces consistent
  3. Set clear guidelines and rules on how to use the above

You can read more about it all in the original article.

What makes a good Design System?

I don’t think I can really pin point a specific thing and would say it definitely depends on execution, but I think the following makes for a good design system:

Any times when using a design system is not a good solution?

If it over-complicates and clutters people’s workflows with unnecessary process, then it’s not a good solution. In fact, it isn’t a solution at all.

You can have a pattern library without calling it a Design System. You can have a simple UI kit. Or a set of design variables when building a simple website. If it helps you build faster, then it does the job. It doesn’t always have to be a system.

You can also design and style everything on the go. Like when you’re building marketing sites. Or products with a lifespan as part of marketing campaigns. It doesn’t really matter what and how you use, as long as you are productive, efficient and get the work done.

┳┻|
┻┳|
┳┻|
┻┳|
┳┻|
┻┳|
┳┻|
┻┳|
┳┻|
┻┳|
┳┻|
┻┳|
┳┻| _
┻┳| •.•) I don’t know what
┳┻|⊂ノ a “design system” is
┻┳|

— Stevie Buckley (@StevieBuckley) September 17, 2018

No bio is complete without mentioning coffee or tea. So there you have it: coffee is my cup of tea. I design and code at Marvel. Hit me up on Twitter!

Related Posts

During a recent conversation with David Sleight, Design Director at ProPublica, I found myself realizing and saying “we need design that is faster and design that is slower.” Who are we and what is this thing called design? When I say “we,” I mean our whole industry, when I say “our whole industry,” I mean design, and when I say “design,”… Read More →

Five pitfalls that get in the way Today’s pace of change demands that collaboration and processes be sped up to meet the growing expectation of customers and stakeholders. But is this growing crunch on time stifling creativity? It isn’t enough to make decisions, products and services quickly, we must encourage creativity and create an environment to help the business succeed in… Read More →

This month’s post is a compilation of what our product designer at Marvel, Oleg, found inspiring this month in design. Uber When you think ride-sharing and ordering a taxi from your mobile phone, you probably think Uber. Over the last 10 years it’s seen an explosion of growth, amassing over 16,000 employees, 3 million drivers, and 75 million riders –… Read More →