‘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:
- Developers don’t want to repeat the same work on different mediums.
- Companies want to be more efficient.
- Product designers and owners want the products they work on to be faster, more accessible whilst still looking sharp and consistent.
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.
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:
- Main Marvel platform
- Prototype viewer
- Design tool
- Handoff
- Mobile apps (iOS/Android)
- Mac apps (Sketch plugin)
We also develop and support a few static sites:
- A marketing website
- A WordPress blog
- A bunch of isolated back-end templates
Using our own API, we build and ship integrations and their marketing pages like these:
- BotBot
- Dashboard
- Userflows
- Keynote to Marvel
We also send out HTML emails daily:
- Some of them are automated
- Some of them have to be built specifically for an announcement
We also have different teams collaborating on a daily basis:
- Product
- Front-end
- Back-end
- Marketing
- Sales
With all of these different platforms, channels, teams and processes involved, there are a range of challenges that surface. For example:
- How do we make design accessible to all the different teams?
- How do we ensure each team uses the same technologies, elements, and patterns?
- How do we ship new features for each product without repeating the same work over and over again? Or, in other words, how do we stay efficient?
- How do we bring over consistency to all of these?
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:
- What happens when a design value needs to change?
- How much of it was influenced by user research?
- How do we improve what we already have?
- How do we introduce new patterns?
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:
- Detailed documentation
- Regular audit
- User research
- Testing
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:
- Identical components were implemented inconsistently.
- Colors were not balanced properly.
- Transition durations were set seemingly at random.
- There were almost 100 unique font sizes.
- We counted 18 slightly different shades of the same gray.
- Lots of CSS was either duplicated or unused.
From there it was deciding on tech and our approach to solve the following problems:
- Build a framework to unify all design values
- Build a pattern library to make existing user interfaces consistent
- 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:
- Good, concise documentation
- Rules and guidelines that are easy to understand
- Clear reasoning on why certain decisions were made (A good example of this is Bulb’s design system, which has insights below each component and give context to why certain decisions were made – mostly backed by user research)
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
