English version is below.
Legos and Unicorns: Bridging the gap in Design Systems adoption
The title of this article is meant to evoke the colorful lego bricks, joined together to make the corral of a very pink and sparkling unicorn. Probably a huge rainbow coming from its single shiny horn. This article is about Design Systems, programmers, and designers.
I will bring up some of my own professional experience as a designer who had to learn to do programming work, and ultimately becoming what has been called a unicorn a term used to describe a designer that codes. Now, this is not supposed to be a brag, it’s actually very terrifying, as the imposter syndrome that comes with each discipline is felt more intensely. However, one important upside of it is being able to work from two different points of view, providing empathy and a better understanding of the whole.
How I became a unicorn has a lot to do with lego bricks. This is the way a previous boss explained to me how React with Typescript works, with components, props, and all that jazz. “Basically, you build a part with tiny blocks and then use it to make an even bigger thing: like lego bricks”. This seemed too condescending, simplified, and ultimately confusing at the time. For me, it didn’t click until I started making better use of tools such as bootstrap or materialize. Then I could actually see the bricks and how they could be assembled with examples. Later, I got better at making my own bricks as React components and then using SCSS to understand how to make my own style ruling.
Then, Design Systems appeared in front of me, and at first, I thought of them as glorified frameworks to do the incessant copy-paste of ready-made code. Soon enough, what interested me was its human component. It is not only about code and visuals, but it’s also about the people that make them, adapt to them, contribute, and maintain them alive.
In her conference “Design Systems Anthropology”, Jina Ann talks about the human side of Design Systems. While user interface components and documentation are what compose a Design System, at its core, it requires a group of people to adopt them and be willing to contribute to it. This requires a change in the culture of such a group. A Design System impacts how people work, how they communicate with each other: they need to be aligned with certain rules towards certain goals that are defined in order to be more productive while making quality products. Paraphrasing Ann: a design system by itself is not going to have success, rather the group of persons behind its creation, maintenance, and adoption, is what will make it succeed.
Design System Definition
There are many definitions for a Design System. Nathan Curtis defines it is a library of styles, components, and other elements that can help a person or group of persons so their products can be made more efficient and cohesive. He talks about a Design System being an interconnection of three systems in which its success depends: A kit of reusable, interconnected parts; a set of cohesive interconnected products; and a community of collaborative, interconnected people. This last point is ultimately what can keep a Design System in use, updated, and relevant.
In another definition, It is a set of tools for development teams of designers and programmers to use in their applications in order to keep continuity and an adherence to certain rules that define, for example, a brand. Audrey Hacq reminds us of the abstract nature of some Design System elements. While you can have libraries of components, predefined rules for colors, fonts, and other elements, there are also values, ways of working, a mindset, beliefs.
Hacq, talks later about the language that is built and used inside Design Systems. Colors, fonts, icons. All the parts have to be put together using certain guidelines, appropriate combinations that would make the system work. The components can be seen as words and the guidelines as grammar, similar to when speaking a language. It is not enough to know the vocabulary, but also how to arrange it to make sentences. Going further, it also requires knowledge about human contexts, for example, some languages have formal and informal registers depending on the speakers, and whether you are writing or speaking.
Anne also makes parallels with music, specifically the case of jazz, and mentions how Design Systems are not supposed to inspire creativity, rather offer a framework to collaborate with speed, creatively. Probably referring to following rules in order to achieve the harmony that the Design System aims to have.
In the above definitions, we can identify how Design Systems require certain disposition: if it’s a library, you have to be willing to consult it, if it’s a set of tools, you have to know how to use them properly, if it’s a language or music, you have to learn their basics, practice and have some discipline. Since Design Systems are a convention for a group of people to use, it is important that a community is present there to actually provide its members with the necessary support in order to have everyone in an understanding and adoption of the Design System, the cultural change that Anne mentions.
Design Systems need to bring people together. For many development teams, this means not only programmers who do all the work, they collaborate with designers, people from marketing, and other disciplines.
Back to personal experience, as a designer, trying to fit in with a team of mostly engineers was challenging. I expected to follow design principles of planning before starting production, make wireframes, visual flows, having the application first in a visual draft before proceeding to make it. However, having the pressures of a specifications list, and clients that care more about adding more and more functionalities, switches priorities: the thing has to work, “then we can put lipstick on it”.
In the end it is not an easy thing to do: different views have to be put together, under a single goal. It’s a human relationship at its core, and it requires good communication and empathy. A parallel of this office culture could be made with Design Systems: you have people from different disciplines working with and on it, thus you need some strategies to make it work.
In order to have someone adapt to a Design System, it requires some human effort. It goes beyond throwing a bunch of documentation to a newcomer, it requires having some sort of ambassadors that would take the time to actually talk and understand where the new member is coming from. Nathan Curtis refers to this kind of person being either a shepherd or steward, in either case, it’s someone who actually brings a human link to the library, tools, rules, and the many components of the Design System. This also includes introducing the community behind and encouraging the newcomer to participate and contribute to the Design System, once they have adopted it.
So, even though I had some experience programming, having someone sit down and explain it to me as lego blocks, was very efficient in retrospective. This person put both of us at the same level through the allegory of legos and actually took the time to hear my concerns and questions along the way. Of course, it didn’t stop there, I also had to look for tutorials, work on personal projects, and just keep on smashing my face to the screen of error codes. But along the way, I started to understand more from the programmer’s side, and ultimately started to make connections and see how design and coding actually relate. I believe these are the kind of connections that have to be understood in order to better comprehend Design Systems, and be motivated to use them.
I wanted to end this article with a “How to bring everyone together” subtitle, but really I don’t feel confident about saying what will or won’t work. Nevertheless, some important points I think should be considered for bringing a Design System team together are: Having good communication, being supportive of newcomers, and aiding with more than countless guidelines and beyond 2-hour meetings. Building up empathy for other work disciplines involved in the Design System adoption and maintenance, remember is not only one kind of job that uses it, and each discipline brings its own point of view. Finally, aiming to become a herd of unicorns; I’m not saying that every single member of a development team has to program and design as complete experts in both fields. But learning even basic concepts from each discipline, or even having a look at what other members do in their work, in this case working with a Design System, might help to create the channels that a development community needs.