(intro)

A few months ago I was casually reading my Twitter feed and bumped into this tweet from Brad Frost

(brad frost tweet)

He says that design systems are 80%-90% people stuff and only 10-20% design, development and tools stuff.

I started thinking what exactly was this "people stuff" and there was one particular reply that caught my attention

(reply tweet)

A design system is a language.

If people aren't speaking the same language, there will be nothing but confusion.

Make sure your design system speaks to both technical and non-technical people.

This last bit in particular really connected with me so I decided to start this journey of finding a language for design systems that speaks to everyone and today I'm going to share what I discovered with you.

(personal intro)

My name is Bernardo, I'm a software engineer at TravelRepublic here in London and that's where you can find me on Twitter and pretty much everywhere else.

(robin tweet)

So Robin didn't know at the time but he tweeted the exact outline of this talk back in March, way before I even knew that I was going to be here today.

We're going to split this talk into 3 chapters: one about documentation, another one about code and the last one about the relationships in a design system.

(design is doc / code / relationship main slide - doc highlighted)

Let's start with the documentation.

Design Systems have gained a lot of popularity recently, just the fact that this conference exists is a good indicator of that, but this conversation actually started a long time ago, perhaps not in the exact same format but we'll see that there are many similarities

(apple desktop guidelines)

In 1986 Apple published for the first time their guidelines for the "Apple Desktop Interface".