Reduce friction and improve productivity by implementing a Design Language System
Tags: frontend, webdev, styleguide, ux
Published: 2019-03-06 17:13:09

---
title: Reduce friction and improve productivity by implementing a Design Language System
published: true
description: I wanted to write about an article that I read by Design at Airbnb. It talks about some really important practices and discusses how they moved over to a Design Language System (DLS)
tags: frontend, webdevelopment, styleguide, ux
---

I wanted to write about an [article](https://airbnb.design/building-a-visual-language/) that I read by Design at Airbnb. It talks about some really important practices and discusses how they moved over to a Design Language System (DLS) - not too dissimilar to our own Style Guide that we used when I was at Zuto. They talk about how it helped them to quickly prototype, speed up their design process and release products much faster. I recommend reading the article before reading this post, just for some context (and because it's a great article).

I wanted to outline some things from the article that will hopefully help those who might not understand why a tech company have such a thing a as a style guide or DLS. I also want to help you understand how we used ours at Zuto, what the value of it is for us as developers and how it can help us to prototype more.

One quote from the article stood out for me:

> "The DLS provides us with a shared understanding of our visual style, and streamlines contributions to a single system. This system also enables all of us to prototype and experiment with ideas in high fidelity faster and at a lower cost."
-Airbnb

While we had a Style Guide in place at Zuto and we used the components that it is made up of to produce many of our products; we were still actively trying to improve on the "shared understanding of our visual style" - side of things. The design team were hard at work on figuring out the best way to display and visualise what Zuto is as a brand and discovering the best way to use that brand across the DLS, is what helps us to gain a "shared understanding of our visual style".

Once we have created a DLS with a so called "visual style", prototyping becomes much easier too, because we no longer have to worry about fonts and colours (the finer details), we can focus more on the functionality of products that we want to build/prototype.

> "It enables product reviews to focus on the actual concepts and experiences of a design, rather than padding, colors and type choices."
-Airbnb

As I said above, if we already have a DLS in place, prototyping is easy and quick. Using a style guide, we can knock up really quick and simple high fidelity wireframes, using only elements from our Style Guide. We can then use those prototypes to present our ideas to product owners or our peers. Moving on from there, we can start to mock up a more established React prototype and continue designing the prototype in the browser with the help of designers. Then when it comes to actually implementing your prototype, you will have already done a lot of the groundwork, allowing you to focus on the logic.

If you really get this process down, your life as a developer would be much easier. The design team would carry a lot less weight on their shoulders too, because they would no longer have to create fully fledged designs that take a long time to conceive. Also, product owners would benefit from the fact we would be building much more MVPs, rather than all singing all dancing pixel perfect products, because we are releasing value quicker!

I believe that prototyping enables us to design and build better products, and enables us to do both of those things faster and more often. It can help to move your team away from trying to build completely perfect products first time around and instead work on the MVP, test its value and iterate. If we are using elements from our style guide, then there should be no need to make small pixel perfect adjustments.
When talking about the effect the DLS had on their process, Airbnb wrote:

> Development is generally faster, since product engineers can focus more on writing the feature logic rather than the view code. Additionally, engineers and designers now share a common language.
-Airbnb

So development was quicker, but not only that, design and engineers are on the same page, which massively boosts productivity and reduces push backs! We certainly felt that after implementing the DLS into our workflow and involving designers in the contribution process to the DLS.

However, all of the above is dependent on your tech department as a whole being committed to maintaining a style guide/DLS and following it's guidelines. Creating and more importantly, maintaining a DLS is the difficult bit. If you are able to get all engineers/designers/product owners, invested in the value that a DLS will bring, then hopefully the passion to maintain it and use it will come naturally.