[RFC] Glossary

[nagueva]

So far, design tokens are the best way to soften the communication between design and development. For the first time, as designers, we are not dependent on tools to hand-off our work. We are developing an agnostic language that empowers everyone to build and manage design components collaboratively. That's great.

But, as facilitators in the communication across design and development, we still miss some major definitions that are beyond the design tokens per se. Some of those definitions have a consensus in isolated teams, but not in a broader overview.

Being in a team responsible for ensuring design consistency across hundreds of applications, I can easily give a few examples:

Variation
What exactly is a component variation? If it is when a component changes, can we consider a hover effect as a variation? Are different themes in the same component a variation? Are variations just an additional component look?

Behavior
What exactly is a component behavior? Is it how behaves in an application or how it reacts to different interactions?

Theming
Is theming a definition for components or for the context where they are? If theming is for components, can I use them in different themes on the same screen? What sounds better: a blue button or a button inserted in a blue themed application?

We all know the answers - some of us probably have sound arguments on it - but we don't need to answer it now.

Since our goal is to harmonize the discussion, the real question is: why not have a glossary to support conversations and empower the beginners?

We are from different cultures, contexts, and areas. A glossary is a simple way to avoid misunderstandings and help all of us to communicate in the same way - especially in the long term, separating context from definitions. It can be a support for discussions, which is precisely the purpose of this group.

[jina]

Definitely. This was discussed (I brought up that this could be used as an educational resource as well).

[nagueva]

Yeah, definitely. It smooths the learning curve.

Shall we start a file (or a discussion) to sketch the items that we should cover?

[jina]

We can use this thread?

[phun-ky]

@nagueva

design tokens are the best way to soften the communication between design and development

It is also to soften communication between developer and designer. The communication should be a loop between the two parties, not just from the designer to the developer.

It's been far too long that the idea of design communication is only from the designer to the dev. Ive been doing frontend since 1998,so I've experienced my fair share of this.

A designer rarely knows the limitations of or implications of the design provided. A dev (and perhaps ux) does. And from what I've pointed out under #43, creating and maintaining tokens rarely falls under the designer role.

I have evangelized, for a time now, that we need to bridge the gap between designers and developers. We don't share the same language, we rarely sit together in the same team etc. Design tokens could be the key, or start, to help with this.

My utopian vision is that design and develop communication works as a continuous loop : (agreed upon) changes (tokens?) in a component by a dev should automatically be reflected in the design kit/sketches /lib, and any (agreed upon) changes (tokens?) in the design should also be reflected in the code.

[jina]

Closing this thread as we have implemented a glossary and can add to it over time. https://www.designtokens.org/glossary/

[jina]

A designer rarely knows the limitations of or implications of the design provided.

@phun-ky you have made broad statements about designers in multiple issues here in this repo. Aligned with our principle of Inclusive, I'm going to ask you to kindly refrain from making statements like this. It's very gatekeepery and just simply not true.

[phun-ky]

@jina first of all, my apologies. It was never my intention to be offensive or to be gatekeeping.

I am just trying to voice my concerns here, since the outtake, currently, from this initiative, and the threads that I've read, is that design tokens are designer centric. (my opinion). Design tokens as a coined concept is fairly new, but tokens for design (style) in code is decades old.

And I can understand the statement about this not being true, because we probably work in very different cultures and countries. My statement is from my experience with designers for over 20 years. I am very glad to hear that this is not the case in your experience, I feel a bit envious tbh.

And again, I deeply apologise for not being inclusive in my concerns. I hope I can be a part of this community, as a representative from the dev side <3