string(4) "blog"

CONTENTS

2020.8.30

Legos and Unicorns: Bridging the gap in Design Systems adoption (レゴとユニコーン。デザインシステム導入におけるギャップを埋めるもの)

written by Jacobo

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.

design-systems

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.

The gap

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.

programming

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.

//TODO:

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.

一覧に戻る
お問合わせ