Published on <a href="https://blog.prototypr.io/pattern-library-style-guides-design-systems-do-you-need-one-b7857af0f255?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> UX Boot Camp 
<h4>#30dayUXchallenge [Day 24]</h4>
<h4>Pattern libraries, style guides, UI kits, design systems, design systems ops, design language system…</h4>
AAAAAA! So many options!
<h4>Why is the topic so hot so right now?</h4>
Ok, let’s face the truth: It’s hot because it works.
It’s hot because libraries, guides and systems are there to make our lives easier. As simple as that. Among its main benefits, they keep our designs consistent internally and they help us being more productive. They make our work scalable. Because we not only don’t need to redesign established patterns and interactions (we talked about patterns on <a href="https://blog.prototypr.io/ux-best-practices-part-1-ce447b316dd9">day 17</a>), but we can also understand and reuse elements that were already designed and validated before. But, ultimately, they also help improving collaboration.
The challenge we face today is that tools don’t communicate to each other very well, details fall through the cracks, there is a huge gap between design and engineering and we need to do a lot of manual work to make sure we are always on top of everything.
As our products evolve and MVP becomes wedding cakes, it’s natural that achieving consistency becomes more and more challenging. And then our users pay the price.
However, as Karri Saarinen from Airbnb defined, this is a deeper problem in the software industry overall:
<blockquote>“Airbnb has experienced a lot of growth over the years. Currently our design department consists of nearly a dozen functions and outcome teams. It became clear that we needed more systematic ways to guide and leverage our collective efforts. While we recognized these challenges within the company, I believe they are symptoms of larger software industry problems” (s<a href="https://airbnb.design/building-a-visual-language/">ource</a>).</blockquote>
So how can multiple teams effectively work together, while designing for different platforms and managing multiple stakeholders without creating a disjointed experience for our users?
A design system is actually only one of the answers.
So I won’t extend too much about the differences between styleguides, libraries, kits, etc… because I personally believe our industry often overthinks the terms and makes the entire conversation a bit dramatic. Instead, I will focus our conversation on design systems, as I believe it’s a much simpler concept that englobes our basic collaboration needs.
So what exactly is a design system?
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dfSJ6Z8OXxriUq9oDJ95LA.png"><a href="https://product-unicorn.com/design-systems-style-guides-all-those-libraries-what-the-hell-is-the-difference-4c2741193fdc">Source</a>
Design systems are basically a combination of tools and processes that will help our teams working better together. If it will be a combination of a style guide and a dynamic library or if it will be developed in React, it really doesn’t matter.
As <a href="https://publication.design.systems/design-systems-are-for-people-a484620b6988">Jina Anne pointed</a>:
<blockquote>We usually want design systems to help grow our products. That’s how we determine the success of a design system, right? By how we improve the quality of our product? How much faster we ship the product? How much code we reduce in our product?</blockquote>
<blockquote>But who are using those products? Users. Customers. People. That is why we do this. Our purpose is for people.</blockquote>
Design systems should be built for people, for our teams. It doesn’t matter if we will use the most expensive tool, if designers will code or if engineers will design: what matters is that our team feel empowered to contribute to our libraries, to adopt our libraries, to make it grow and to help it evolve.
What matter is that, at the end of the day, product teams feel empowered to design and build a consistent experience while our end-users get a cohesive (and not uniformed) experience on their side too.
<h4>How can we make a design system work for our team?</h4>
What do UXers do when asked “how can we make this work for our user”?
Well, we talk to our users, we observe their routine, we observe the tools they use and we understand what is their process — so that our solution can speak their language.
We need to do the same with our teams. We can ask the same questions. We need to understand what are the gaps the system need to fill, how can we improve our team mates productivity, which tools are we all using and, most importantly, what we aim to achieve and what is the first small step we can take towards our goal.
And now I may disappoint you by saying:
<blockquote>There is no right or wrong. There is no recipe. The right answer is whatever works for your team.</blockquote>
Envato, for example, is currently adopting libraries for Sketch App that can be improved through requests on a Trello Board. It’s just our first step and our first experiment and we will learn &amp; evolve as we use it. A previous team I worked for built a Pattern Library where designers could find established patterns, engineers could reuse its code and we all could check examples of how to apply on different scenarios. I also recently watched a talk where the speaker built an entire process to automate implementation of patterns through React and 554322 integrated tools (it was impressive, actually).
So instead of giving you a direction, I will quote <a href="https://publication.design.systems/distilling-how-we-think-about-design-systems-b26432eefef9">Sarah Federman</a> here because she perfectly explained what are the aspects we need to understand to put a design system in place:
The product is what users [our team] consume. The documentation (commonly called the styleguide), the UI kit, the code, etc. The product is the tangible parts.
The experience is how it makes them feel. Do your users like using your system? Or does it feel cumbersome and block their creativity?
The operations are how it’s made. And execution is the act of making it. What’s your testing process? How are assets stored and distributed? How do users learn about the system or get support?
So I am just here today to plant the seed in your mind and to invite you to reflect on what works better to your team and how you can support them to implement it. But, remember: there is not a right answer.
Take the first step, build your “Minimum Viable Design System” with the tools you have in place, then use it, test it, iterate on it and improve it. ❤
So here goes a few reading recommendations that could ~actually~ help you getting started:
<ul>
<li><a href="https://medium.com/@lewisplushumphreys/how-were-using-component-based-design-5f9e3176babb">How we’re using Component Based Design</a></li>
<li><a href="https://blog.prototypr.io/design-system-ac88c6740f53">Setup a design system</a></li>
<li><a href="https://www.uxpin.com/studio/ebooks/create-design-system-guide-checklist/">Creating a Design System: The 100-Point Process Checklist</a></li>
</ul>
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2F5eb5ba-2%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2F5eb5ba-2%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252F5eb5ba-2%252F%253Fenpose&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href">https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href</a></iframe><img alt="" src="https://cdn-images-1.medium.com/max/119/1*g1xXlc-Yf5xkdPNdA_gxEg.png">Gabi Braga — UX Designer at Envato Elements, freelancer at Toptal &amp; beer enthusiast in her spare time
This post is part of the #30dayUXchallenge: you can read more about why we started it <a href="https://medium.com/envato/why-were-embarking-on-a-30dayuxchallenge-e3d9f1bc1ac6">here</a>, and don’t forget to follow us on <a href="https://twitter.com/ux_bootcamp">Twitter</a> and <a href="https://www.instagram.com/ux_bootcamp">Instagram</a>!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b7857af0f255" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/pattern-library-style-guides-design-systems-do-you-need-one-b7857af0f255">Pattern library, Style guides, Design Systems. Do you need one?</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pattern library, Style guides, Design Systems. Do you need one?

#30dayUXchallenge [Day 24]

Pattern libraries, style guides, UI kits, design systems, design systems ops, design language system…

Top Stories