Design tokens

class: middle, center, naked
name: intro

.c-content[
# Using .u-primary[design tokens] to promote <br> collaboration and maintainability <br> of a design system

<br>

]

???
- Je suis tout à la fois très effrayé et très content de pouvoir contribuer pour la première fois à la communauté.
- Et je voudrais prendre le temps aujourd'hui de vous parler d'un sujet très orienté intégration / front-end: l'utilisation de "design tokens" pour promouvoir la collaboration et la maintenabilité d'un design system.

---
class: relative

# About

- Thibault Mahé ([@tibomahe](https://twitter.com/TiboMahe))
- Front-end developer [Startup Palace](http://www.startup-palace.com)

.l-flex-col--50[
.u-center["I build design systems<br> for startups and larger companies."]
]

???
- Présentation
- Dans le contexte d'agence que nous avons, et pour les typologies de clients pour lesquels nous travaillons, nous avons mis en place et travaillons depuis 2-3 sur une méthodologie de design system / styleguide.

---
class: c-slide-list-lg

# Design system

- Toward a **new paradigm**, thinking in **system**
- **Consistency** and visual identity
- Shared vocabulary and easier **communication**
- More methodical and modular **workflow**
- Fast **testing** and **prototyping**
- **Extensible** and **scalable**

.l-flex-row[
.l-flex-col--25.u-pd[
.u-center[
<img src="im/styleguide-sj-buttons.png" alt="">
]
]
.l-flex-col--25.u-pd[
.u-center[
<img src="im/styleguide-sj-cards.png" alt="">
]
]
.l-flex-col--25.u-pd[
.u-center[
<img src="im/styleguide-sj-tunnel.png" alt="">
]
]
.l-flex-col--25.u-pd[
.u-center[
<img src="im/styleguide-sj-dragdrop.png" alt="">
]
]
]

???
- C'est une méthodologie que certains d'entre vous utilisent déjà, très orientée sur la maintenabilité et la collaboration, notamment pour les designers et intégrateurs d'un projet web.

---
class: c-slide-list-lg

# Some issues remain hard to solve

<br>

.l-flex-row[
.l-flex-col--50.u-pd[
.u-center[
<img src="im/redlines.png" alt="">
]
]
.l-flex-col--50.u-pd[
.u-center[
<img src="im/zeplin.png" alt="">
]
]
]

.u-center[*Assets and design "basis" are often still <br> managed locally and not at the system scale.*]

???
- Chaque année nous essayons de progresser sur la mise en place de cette méthodologie, et nous identifions toujours quelques soucis auxquels nous faisons encore face actuellement.
- 1er soucis: la transition entre design et intégration
- Cette transition se fait bien souvent à l'aide de redlines et d'outils comme Zeplin, qui ne proposent pas vraiment d'approche systémique en donnant des "cotes" localisées et non globales.

---
class: c-slide-list-lg

# Some issues remain hard to solve

.u-center[
<img src="im/broken-system.png" alt="" style="height: 300px;">
]

.u-center[*A "**zombie styleguide**" (Jina Bolton) is an <br>"abandoned" styleguide, half-living half-dead. <br>It is often because of a **lack of adoption** and a <br>**desynchronization** between the guide and the production.*]

???
- 2ème soucis auquel on fait face: l'abandon du design system, et ce que certains ont pu appeler le "zombie styleguide".
- C'est un système qui n'est plus vraiment vivant parce qu'il n'est plus en phase avec la production, à cause du manque de synchronisation ou un manque d'adoption de la méthodologie au sein de l'équipe

---
class: c-slide-list-lg

# Some issues remain hard to solve

.l-flex-row[
.l-flex-col--50.u-pd[

- Too wide range of unique... :
  - font sizes
  - colors
  - margin and padding sizes
  - media queries
  - border radiuses
  - ...

]
.l-flex-col--50.u-pd[
.c-img--md.u-center[
<img src="im/too-much.gif" alt="">
]
]
]

???
- 3ème soucis: la gestion des "unités de base" pour le visuel des interfaces.
- Il peut exister beaucoup d'éléments visuels "de base" (font size, couleurs, ...) et sans approche systémique dès le design et sans gestion appropriée de ces "assets", leur nombre peut très vite croître et devenir ingérable.

---
class: c-slide-list-lg

# Design tokens

.c-img--lg.u-center[
<img src="im/article-bolton.png" alt="">
<br>
*Jina Bolton*
]

???
- Pour essayer de progresser dans la mise en place de design systems et pour notamment essayer de faire face à ces problèmes rencontrés, nous expérimentons la mise en place de "design tokens"
- Les premiers design tokens semblent avoir été mis en place par l'équipe UX de Salesforces dans son Lightning system.
- C'est d'ailleurs très intéressant de noter que c'est l'équipe UX qui l'a mise en place: il s'agit mis d'améliorer l'expérience des utilisateurs du système, considéré comme un produit à part entière.

---
class: c-slide-list-lg

# Design tokens

.c-img--lg.u-center[
<img src="im/article-curtis.png" alt="">
<br>
*Nathan Curtis*
]

???
- Cette méthodologie a par ailleurs été popularisé par un article de Nathan Curtis, un consultant spécialise dans l'approche design system, mais aussi un des auteurs, des "papes", les plus prolixes / prolifiques sur le sujet. Et un des plus pertinents.

---
class: c-slide-list-lg

# Design tokens

.u-center[
<img src="im/sp-guides.png" alt="" style="height: 450px;">
]

???
- L'idée de départ est que chaque site web, chaque système, possède en son coeur des "atomes" qui en sont la base visuelle.
- Les plus importants sont généralements les couleurs, la typo et les îcones.
- C'est dans ces atomes que l'on retrouve (entre autre) l'identité visuelle d'une marque et la "patte" du designer.

---
class: c-slide-list-lg

# Design tokens

<br>

.c-blockquote.u-center[
  "Design tokens are the visual design **atoms** of the design system — specifically, they are **named entities** that **store** visual design attributes. We use them in place of hard-coded values [...] in order to **maintain** a **scalable** and **consistent** visual system for UI development."

.u-block.u-right[– Salesforce]
]

???
- La définition qu'en donne Salesforce: ce sont des entités **nommées** dans lesquelles sont **stockées** les attributs visuels du design. Comme des variables, ils sont utilisés à la place des valeurs hard-codées pour favoriser la maintenabilité, la scalabilité et la cohérence visuelle.
- C'est-à-dire qu'au lieu d'être "enterrés" dans des fichiers de style, sass, less, etc., les assets sont stockés de manière abstraite dans un autre format de donnée dans lequel ils vont être organisés.

---
class: c-slide-list-lg

# Design tokens

.l-flex-row.u-top-align[
.l-flex-col--50.u-pd[
.u-large[Design tokens are...]

<br>

- **Stored**
- **organized**
- **centralized**
- **propagated**

<br>

.u-large[visual design attributes..]
]
.l-flex-col--50.u-pd[
.u-large[...aiming for:]

<br>

- **communication** ("named entities")
- **consistency** through technologies and platforms
- **reusability** ("atomic" metaphor)
- **maintainability**

]
]

???
- Les design tokens sont donc stockés sur un format de données différent.
- L'objectif est de travailler sur leur nommage, de les rendre technology-agnostic, et comme on a vu de travailler sur une meilleure réutilisabilité, scalabilité et maintenabilité du système.

---
class: c-slide-list-lg

# Organized

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
.u-center[
*What can I do?* <br>
Every design system offers ***options***. <br>
Options are visual identity properties.
]
<br>
```yml
# Colors options
# ---------------------

blue-base: '#2b7de8'
blue-deep: '#38bfea'
blue-dark: '#3239e8'
grey10: '#262729'
grey20: '#313131'
grey30: '#4d4d4d'
grey40: '#888'
grey50: '#aeaeae'
grey60: '#ccc'
grey70: '#eaeaea'
grey80: '#f4f4f4'
```
]

]

???
- Généralement, dans l'organisation de ces tokens, on retrouve d'une part ce que l'on pourrait appeler des "options".
- Les options sont tous les atomes que le designer se donne pour travailler sur l'identité visuelle.

---
class: c-slide-list-lg

# Organized

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
.u-center[
*What can I do?* <br>
Every design system offers ***options***. <br>
Options are visual identity properties.
]
<br>
```yml
# Colors options
# ---------------------

.l-flex-col--50.u-pd[
.u-center[
*What choice do I make?* <br>
Design systems submit ***decisions***. <br>
Decisions are options applied to contexts.
]
<br>
```yml
# Colors decisions
# ---------------

# global
primary-color: $blue-base
text-color: $grey30
body-background: $white

# objects
navbar-link-text-color: $white
headband-color: $white
hr-color: $grey40
```
]

]

???
- On retrouve ensuite les décisions, qui sont des assets qui associent ces options à des objets ou à des "qualificatifs" métiers.

---
class: c-slide-list-lg

# Centralized

<br>

- Stylesheets are "**decisions propagated through a system**" (Nathan Curtis)

<br>

```scss
// Design specifications
// ----------------------

.c-button {
  display: inline-block;
  font-size: $font-size-button;
  padding: $space-m;
  color: $text-color;
  background-color: $white;
  border-radius: $border-radius-base;
}

.c-button--primary {
  background-color: $primary-color;
  color: $white;
}
```

???
- En stockant tous les assets dans un format de donnée, cela nous permet de les gérer en un seul endroit, et donc on n'a plus de valeurs hard-codées dans le css.
- De cette façon, pour reprendre l'expression de Nathan Curtis, les feuilles de style ne font plus qu'appliquer les "décisions" sauvegardées dans des tokens.
- L'approche permet de considérer le lien entre le code et les spécifications du design d'une manière différente aux redlines / zeplin.
- Ici les feuilles de styles commencent à ressembler à des spécifications de design et deviennent plus lisibles.

---

# Centralized

.l-flex-row.u-top-align[

.l-flex-col--25.u-pd[
.u-center[
*At the root of the files system* <br>
<img src="im/token-architecture.png" alt="" style="height: 390px;">
]
]

.l-flex-col--25.u-pd[
.u-center[
*Legible & editable <br> by anyone* <br>
]
```yml
# Typography

font-family:
  base: 'Lato, Helvetica'
  heading: 'Montserrat, Helvetica'

font-size:
  xs: 8px
  s: 16px
  m: 20px
  l: 28px
  xl: 32px
  xxl: 40px

font-weight:
  light: 300
  regular: 400
  medium: 500
  bold: 700
```
]

.l-flex-col--50.u-pd[
.u-center[
*Opened to everyone to foster <br> collaboration and maintainability* <br>
<img src="im/tokens-process.png" alt="" style="height: 390px;">
]
]

]

???
- "Centralisé" signifie également que ces tokens sont disponibles et accessibles à tous.

---

# Propagated

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
.u-center[
*Tokens are compiled with a task runner* <br>
]
```javascript
// Compile Design tokens
// -----------------------
gulp.task('build-token', function() {
  return gulp.src([paths.designTokens.files])
    // transform tokens from yaml into json
    .pipe(yaml())
    // store json
    .pipe(gulp.dest(paths.designTokens.jsonOutputFolder))
    // transform tokens from json into scss
    .pipe(jsonSass({
      delim: '-',
    }))
    // store to output folder
    .pipe(gulp.dest(paths.designTokens.outputFolder));
});
```
]

.l-flex-col--25.u-pd[
.u-center[
*Json output*<br>
]
```json
{
  "font-family": {
    "base":"Lato, Helvetica",
    "heading":"Montserrat, Helvetica"
  },
  "font-size": {
    "xs":"8px",
    "s":"16px",
    "m":"20px",
    "l":"28px",
    "xl":"32px",
    "xxl":"40px"
  },
  "font-weight": {
    "light":300,
    "regular":400,
    "medium":500,
    "bold":700
  }
}
```
]

.l-flex-col--25.u-pd[
.u-center[
*Sass output*<br>
]
```scss
$font-family-base: Lato, Helvetica;
$font-family-heading: Montserrat, Helvetica;
$font-size-xs: 8px;
$font-size-s: 16px;
$font-size-m: 20px;
$font-size-l: 28px;
$font-size-xl: 32px;
$font-size-xxl: 40px;
$font-weight-light: 300;
$font-weight-regular: 400;
$font-weight-medium: 500;
$font-weight-bold: 700;
```
]

]

???
- Enfin, les tokens sont "propagés", c'est-à-dire convertis dans des formats utilisables pour nos applications.
- Par exemple ici on transforme les tokens en json et en sass afin de les utiliser avec les deux technologies

---

# Propagated

.u-center[
<img src="im/nathan-curtis-tokens-propagation.png" alt="" style="height: 360px;">
<br>
*"We define our design in a single location and use a system to cascade it down to all platforms. We call it our **Single Source of Truth**." - Sönke Rohde, UX engineering at Salesforce. <br> (schema: [Nathan Curtis](https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421))*
]

???
- Pour des entreprises ou des produits de plus grandes dimensions, les tokens représentent véritablement le "Single Source of Truth" du design de la marque, propagés sur plusieurs plateformes et technologies, mais tous gérés depuis la même base.
- C'est le coeur de l'esprit design system

---

# Propagated

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
<img src="im/theo.png" alt="" style="height: 390px;">
]

.l-flex-col--50.u-pd[

<br>

Salesforce created **Theo** for transforming and formatting Design Tokens

Theo **transforms** to Lightning (aura), sass, less, stylus, json (ios), xml (android), color swatches (photoshop & sketch).

It can also **convert** colors and sizing units to different formats.

]

???
- Salesforces s'est créé un outil sur-mesure pour imposer un format particulier à ses tokens et les propager sur plusieurs technologies et formats.

---
class: c-slide-list-lg

# Propagated

.u-large[For smallers companies and agencies, propagation is still relevant. <br>It allows:]
- **Synchronisation** between:
  - external "traditional" CSS components (HTML, Twig, ...)
  - **css-in-js** components (React, JSS)
  - even "css-in-shadow-dom" components (Polymer, ...).
- **Dynamic** and **automatic** styleguide (tokens and assets introduction)
- Technology **transition** (towards post-CSS, CSS custom properties, ...)

<br>

.u-large[With all the other benefits of the design tokens.]

???
- Par rapport à l'utilisation qu'en fait Salesforce, l'intérêt est évidemment plus limité pour nous, puisqu'on ne gère pas forcément plusieurs plateformes, des app, du Java, du less, du sass, etc.
- Mais cela reste pertinent.

---

# Synchronization and automation

???
- Ici les cards sont générés directement depuis les tokens en Json.
- Plus besoin de mettre à jour le design system sur ces tokens.

---

# Synchronization and automation

.c-img--lg.u-center[
<img src="im/comet-options.png" alt="">
<br>
*How the Comet design system present its option tokens.*
]

???
- De la même manière, cela nous permet de présent dans le styleguide toutes les options et décisions pour faciliter la communication et l'utilisation de ces tokens.
- Et sans dépendance de technologie sur les tokens, cela permet d'avoir une documentation automatique.

---

# Going further

.u-large[Can our "decision" tokens match our actual decision approach?]

<br>

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
.u-center[**"Object-oriented CSS"**]
```scss
// Button definition
// ----------------------

.c-button {

display: inline-block;
  font-size: $font-size-m;
  padding: $space-m;
  color: $text-color;
  background-color: $white;
  border-radius: $border-radius-base;

&--primary {
    background-color: $primary-color;
    color: $white;
  }

}

```
]

.l-flex-col--50.u-pd[
.u-center[**"Functional CSS"**]
```scss
// "Pure" CSS classes
// ----------------------

.u-bg-white { background: $white; }
.u-bg-grey { background: $grey; }
.u-bg-primary { background: $color-primary; }
.u-bg-secondary { background: $color-secondary; }

.u-white { color: $white; }
.u-grey { color: $grey4;}

.u-primary { color: $brand-primary; }
.u-secondary { color: $brand-secondary; }
.u-tertiary { color: $brand-tertiary; }

.u-inline-center { text-align: center; }
.u-inline-right { text-align: right; }
.u-inline-left { text-align: left; }

```
]

]

???
- Pour aller plus loin j'ai essayé de voir comment nous on pourrait utiliser ces tokens.
- On utilise effectivement une approche qui distingue les objets et les utilitaires
- Si n'importe qui peut avoir besoin de modifier une décision sur un objet, il est aussi possible que l'on est besoin de crééer ou modifier un utilitaire de la même manière.

---

# Going further

<br>

.l-flex-row.u-top-align[

.l-flex-col--50.u-pd[
.u-center[*Classes could be compiled from tokens*]
```js
// Compile Utility tokens
// ----------------------
gulp.task('build-utilities', function() {
  return gulp.src(paths.designUtilities.files)
    // transform tokens from yaml into json
    .pipe(yaml())
    // store json
    .pipe(gulp.dest(paths.designUtilities.jsonOutputFolder))
    // transform tokens from json into scss
    .pipe(jsonSassUtilities())
    // store to output folder
    .pipe(gulp.dest(paths.designTokens.outputFolder));
});
```
]

.l-flex-col--50.u-pd[
.u-center[*Input*]
```yml
position:
  relative: relative

background-color:
  bg-blue: *blue
  bg-green: *green
```

.u-center[*Output*]
```scss
.u-relative{ position: relative; }
.u-bg-blue{ background-color: $blue; }
.u-bg-green{ background-color: $green; }
```
]

]

???
- On a "prototypé" un plugin qui permet de générer des utilitaires à partir d'un fichier de token que l'on définit.
- Cela permet notamment aux développeurs d'ajouter les utilitaires qu'il manque ou qui n'ont pas été prévu.
- Cela permet aussi d'automatiser l'affichage sur le styleguide des utilitaires, qui sont une partie importante de notre approche et qui manque pourtant de documentation ou de visibilité sur le styleguide.

---
class: c-slide-list-lg

# Conclusion

- Design Tokens are a **cross-platform**, **human-readable**, **abstraction** of visual styles, that **sync** with all the style files in the system
- Tokens introduce a new format of **storing styles** data (as serialized data — either JSON, or YAML)
- Design options and decisions become **centralized** and **available** to any product, designer or developer in an easy-to-use predictable formats

---
class: c-slide-list-lg

# Advantages

- **Specs**: Organize and present the design choices and decisions
- **Naming**: better communication and reduced nomenclature errors
- **Maintenance**: technology-agnostic tokens, living documentation and less hardcoded-values
- **Collaboration**: empowers non-developers to engage with code with a more human-readable language
- **Opportunities** to synchronize and extend the system into designer tools (Sketch, ...)

---
class: c-slide-list-lg

# Some sources

<br>

- Jina Bolton - [Using Design Tokens with the Lightning Design System](https://www.youtube.com/watch?v=wDBEc3dJJV8)
- Sönke Rohde - [Living Design System](https://medium.com/salesforce-ux/living-design-system-3ab1f2280ef7)
- Nathan Curtis - [Tokens in Design Systems](https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421)

.u-large[Examples of design systems using Design Tokens:]

<br>

- [Salesforce design tokens](https://www.lightningdesignsystem.com/design-tokens/)
- [Comet design tokens](https://comet.discoveryeducation.com/resources/tokens.html)

---
class: naked, middle, center, blue

# Thanks