by Mina Markham

MYTH #1: Designers “own” the design system

Mina describes herself as an engineer who designs.

She had a conversation with a designer where she asked to contribute to a design system and she ended up being dismissed.

The conversation of design systems is dominated by product designers. Engineers who work on these projects

Engineers provide invaluable knowledge about cross-browser functionality, how to implement the design in-browsers, build tooling, build performances not these systems, do rigorous testing… all of these things are paramount to the success of a system but they don’t get much of a look-in.

Deisgn systems should be multi-disciplinary. The HOW you go about creating something is just as important about the WHY. The code is ultimately the sources of truth for the system.

“Design systems teams should have representatives that bring different skill sets. Design, code, writing, accessibility, product management, and so on.” – Jina Anne

Design & engineering are intertwined but companies don’t know how to utilize people with hybrid skill sets.

The first mythological creature: The HYBRID (aka the Unicorn)
Possesses complimentary skill sets, such as design and code, but are often forced to choose between them based on the way their organization is set up.

We still don’t really know what to do with hybrid skill sets. The answer is let them work on design systems!

Design systems were MADE for hybrids. Design systems give hybrids a home.

Mina imagines that most engineers don’t feel welcome in the design system space.

Hybrids help bring unity to an organization the same way design systems do. Design systems Bridge the gaps within an organization and bring unity.

MYTH #2: Design systems kill creativity

“They don’t work for editorial projects…”
“Design systems are just components / style kits / UI kits.”

On the whole Mina feels there is an over reliance on components within a design system.

Mythological Creature: Components
see also: Mermaid
A Component can mean one thing in one system in one company and a completely different thing in a different system/company. Every system has this creature in it.

“Design systems are really just a bunch of UI kits and libraries of icons. People aren’t designing, they are just rearranging components someone else designs. Great job scrapbookers” (tweet)
This concept suggested to her a lack of understanding of what a design system actually is.

Design systems provide a foundation for visual expression. It has a lot of different aspects involved. You PROBABLY think of a library of buttons and treatments and drop downs that

Good design systems take into consideration a wider aspect of the company’s operations like tooling, accessibility standards, the workflow and processes in place, high level design systems, brand guidelines interpreted for the web, coding standards, governance and maintenance of the system. When these broader aspects are left out you’ll probably end up with a design system that will be outdated or abandoned after a few months since you don’t have a system in place that will let you deal with the evolving creature that is the design system.

For her, ‘a design system is a set of rules that is reinforced by your company culture, processes and tooling, things that government how your organization creates products.’ – Mina

Rules and creativity are not mutually exclusive. Rules can (and sometimes should) be broken. Does this make her a hypocrite?

There is a time and a place for stricture stock components and there is a time and place to create complex visual extensions of your specific brand (Alice Lee)

Your design system isn’t a cookbook, but more of a pantry that you can use that you can use as you see fit. Yesenia Perez-Cruz

You decide what the rules are. The way you arrive at those rules should be informed by your team’s process and your team’s workflow. You decide on the art direction, layout, design patterns based on your own rules.

Once you get the rules out of the way you don’t have to worry about it! You can focus your time on more creative things like great motion guidelines (rather than trying to make a landing page for the umpteenth time.

The trick is to find key moments of brand expression. You can do this whether you want to create a strict design system of a loose design system.

Strict vs Loose Design Systems 

Strict design system: There are very boxed in rules around what you can and cannot do. This is more suited around product design / product work where you want things to be predictable and you don’t want to confuse your users so you want to be as consistent as possible.

Ex: Airbnb
They have a lot of emphasis on the components that are used that can be rearranged to create screens that are needed without a lot of variation around the controls of the product.

Loose design system: More open for experimentation and intentional deviations. The system provides an underlying foundational framework but allows a lot of freedom that is often necessary for editorial work. Designers are free to use or not use the system. To stick to certain aspects of it or to deviate as the situation requires.

Ex: TED design system.
Their design system has loser standards that you’re welcome to use or discard.

“Consistency is really only good insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context is necessary.” – Michael McWatters

“A good design system help you improvise” – Yesenia Perez-Cruz

Product vs Marketing

In product design, people are using your product day-in and day out. If you’re doing more visual creative sites, you’re allowed to play, to be as expressive as you need to be.

You don’t want to FIGHT the snowflakes so much as you want to enable the snowflakes. A loose design system is key to maintaining consistency while still allowing for exploration and creativity.

MYTH #3: A design system is a side project

This is implied in how some organizations talk about design systems. Some organizations are reluctant to provide the resources and time to prioritize a design system. But it should be prioritized. You’ll hear something like ‘Let’s move this work to next quarter.’

Mythological Creature: Later
See also: Phoenix
It rises from the ashes of completed projects to provide adequate space for addressing design and technical debt.

“Many people are convinced ‘Later’ exists but she’s never seen it. She’s never seen ‘later’ on a roadmap”

When you push your design system to ‘later’ you’re treating your it as a second class citizen. It’s never going to be able the value

Design systems require real investment. They require you to put your money where your mouth is and invest the time and resources to get it done.

Some people will say ‘just do it! Just get it done!’ But she thinks this is a bad idea. ‘Just doing it’ on the side sets you up for failure.

Put your money where your mouth is, and put the design system on the roadmap just like your other priorities.

Mythological creature: Roadmap
See also: Cerberus
The roadmap is a many-headed beast that every time you think you’ve accomplished one things and you finally have time to focus on this system you want to give your attention to, another head pops up and bites you on the face.

MYTH #4: Design systems should be on the roadmap.

A design system in reality should be tied to high priority projects that are ALREADY on the roadmap.

She was asked to create a design system based on the donation platform that already existed for HillaryClinton.com
She essential refactored her way to a design system.
The donation platform served as the North Star of the very first iteration of the ‘Pantsuit library’.

The downside of doing this is that sometimes it ends up being very biased towards that particular project. If you allot room in your timeline to slip in design work to your project, eventually as you make more and more projects, you’ll see that the system eventually grows and matures to where it can encompass almost any project.

A system’s value is realized when products ship features that use a system’s parts. As you’re able to ship more and more projects and you’re able to ship them faster and more efficiently, you’re also able to demonstrate how useful that system was to get that product out the door.

If you put a design system on a roadmap, it implies the design system has an ‘end’ and that it will be done. However, a design system is never REALLY finished.

MYTH #5: Our system should do what XYZ’s design system did.

We have so many examples of how other people approached problems with design systems.
There are great systems and examples of documentations you can look to

Mythological creature: Inspiration
See also: succubus
A powerful seductress who might seem fun at first but ultimately leaves you feeling intimidated and exhausted.

Design systems should be built with your organization in mind, not as a carbon copy

Your system shouldn’t look like someone else’s because it’s solving problems that another company’s system is not trying to solve.

Case Study: Slack kit vs Spacesuit
Two design systems for Slack (for the actual product vs the marketing website)
Establish common language between the teams that are working on them, reduce technical debt, increase developer velocity… but that’s where the similarities ended. They are vastly different in many ways.

A question she’d sometimes hear is ‘why isn’t our system like Slack kit?’ They were drawing inspiration from Slack kit but it doesn’t make sense to compare them. Be inspired, but don’t expect the same results.

MYTH #6: Everything is awesome in design systems work!

Design systems that are put out to the public are kind of like Instagram. We don’t know the behind the scenes stuff that happened to get to that finished product.

Everything isn’t TERRIBLE behind the scenes, everything mostly works. There is a reluctance to show the mess behind the finished product. We don’t want to share our work until we think it’s perfect… which is the final mythological creature:

Mythological Creature: The Perfect Design System
See also: angel

Benevolent creature acting as an intermediary between worlds. May also guide and protect those who need it.

But it may or may not exist. Nothing is quite as perfect or as smooth as you think it is.

“For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing code base.” – Arquay Harris

It’s a rare thing to start with a clean slate.

Designing Spacesuit was a project with 5 people, and they still ran into issues. They’d see that someone merged something this morning and something else would get messed up across the whole website.

There were also 2 components that look very similar, have similar elements within them, and that do basically the same thing, but they have 2 different names (HERO & Section). WHY?! No idea, a decision was made at the beginning to do this and then it never got fixed because of the mythical creature ‘Later.’

Long story short – many mistakes were made. Why would she expose these mistakes?!
She thinks is important for us to show our mistakes publicly and be vulnerable and transparent so other people can benefit from them.

Show the messy stuff and the mistakes you made, share your work in progress, share how you got there, share something unfinished. Be more willing to learn out in the open and help others learn, too.

Myths:
1. Designers should own design systems
2. Design systems kill creativity
3. A design system is a side project
4. A design system should be on the roadmap
5. Our system should do what XYZ’s did
6. Everything is awesome!

@minamarkham