Re: [community-group] The Designer’s Workflow (#43)

These are all fantastic comments and I second a lot of what has been said above. 

I firmly believe that the creation of tokens is fundamentally a different type of design — something that existing tools have not yet figured out for our space. So the creation of design tokens in any current UI design tool is not appropriate.

I love how @sebfriedrich  put it:

> “…rules are more and more shaped in a mathematical or logical sense and computers assist to apply these rule sets, where before the engine was all human only.” 

Creating design tokens is done by designing a **system**. And designing a system **≠** component design. A step further, I would add that in my opinion there are two types of tokens: _system authoring tokens and consumption tokens._

Color and type are the best examples to amplify this difference, so I’m glad they are the requested perspective to use.

## System authoring tokens
What I mean here are the **minimal values used to define a system**. 

## Consumption tokens
These are what most people identify as “tokens” today. They are the proxy used to deliver, consume, or use a system in order to design or build components, patterns, or applications (or other branded non-digital material). These are what others identify in the “export” line of thought.

However, in some platforms, the authoring tokens would still be a more desirable form to consume. Line height is a great example, where some tools need a resolved pixel value, iOS and Web are much better suited with the unitless value (eg `1.3`)

I will touch on each type of token for Typography and Color:

#### Typography (system authoring)
System authoring tokens for typography would require only these tokens:
base size = `14`
multiplier = `1.125`

Those values create all other tokens for type sizing. There would need to be additional configurations, of course, to define how many sizes are needed, what direction to increment (up or down), and a naming system.  By that I mean that all type tokens are given a name, such as `font-size` and the author can define a specific system or convention for naming. We do this pretty commonly:
* Base size index is considered to be `1`
* All indexes are multiplied by 100 for naming convention (`1` = `font-size-100`)
* All other sizes are powers. Ie: the third increased font size name is `base * 1.125^3`
* This gives us the proper value of ~ 20 (rounded) and a name of `font-size-300`
* Decrementing works a bit differently but in the same line of thought.

#### Typography (consumption)
This would be the output of some sort of export feature, which to some degree would also be “exporting” within the internal systems authoring tool in order to allow users to assign aliases to the generated tokens. 

**System generated consumption tokens:**
* font-size-100
* font-size-200
* etc.

**Manually created consumption tokens:**
* font-family
* font-weight-light
* font-style-italic

#### Color (system authoring)
Color systems are very complex. Most color tools out there are so lacking that multiples must be used, or one is left to build their own. Much like @sebfriedrich, we used to use excel to help audit the many aspects of color, and have since then built our own open-source tool, Leonardo. 

The things that need to be systematic for color palettes are:
* transitioning between hue and saturations for tints and shades
* hues selected to be part of the palette must be perceptually distinguishable (_this is a rabbits’ hole topic so I’ll spare the caveats and nuance_) 
* Contrast levels must be met for specific usages of color
* Color must translate to multiple **themes** while still meeting all other criteria (_also theme definition is another rabbits hole_)
* (and more)

We use [Leonardo](https://leonardocolor.io/) for our system authoring tokens, which lets us define a single color (by hue family name) based on parameters that give us a full scale of color:
`colorKeys` (list of specific hue/sat/lightness values that we want to interpolate between
`colorspace` (the color space/model we want to use for interpolation)

Then we can create each output color swatch by defining the _contrast ratio we want it to have with the background_, such as `3` or `4.5`, etc.

We leverage the same naming conventions above as a system to generate the _consumption_ tokens for each color theme we support (6 total)

**Note regarding color format:**
I highly prefer that in an authoring environment, you can select specific values for each supported colorspace. One of the things I love about the Pantone system is that CMYK and RGB colors *are not a mathematical 1:1 conversion* in Pantone — they know that these are perceptually different, as one color will be perceived via reflected light, the other via direct. So the values defined for a specific color are done so to ensure color constancy to the best extent possible. Brands will want to do the same. 

#### Color (consumption)
Along the lines of my note above, there may be specific colors or unique transformations to color in order to support the desired consumption format (such as CMYK), however at a bare minimum these transformations should be available by default. To that point, there’s all sorts of nuance when you consider authoring a color system for consumers that will use CMYK or P3 colorspaces, especially when you make choices and preview all these decisions within the sRGB colorspace. 

**General notes on Color:**
CSS preprocessors should never be used for color conversions. Period. **Trying to use these functions to traverse colorspace is like drawing with an etch-a-sketch.** 

If you’re looking into color to the degree of having concerns about the interpolation of color (making lighter, darker, more saturated, less saturated, or shifting the hue, etc…) you need to use alternative tools to do so. CSS is a place for defining style attributes, not for negotiating color science :-) 

Not to be shamefully plugging this tool here, but we battled these same issues for Spectrum (Adobe), which we just started throwing all sorts of features into our tool [Leonardo](https://leonardocolor.io/) to help with. Color interpolation happens in the tool, so now you define a “color” as a full color scale; now color is _variable_. You don’t need to `lighten()` or `desaturate()` ever — because the interpolation path is predefined, and colors are output from this tool/system. You can visualize this with the 2d charts or the 3d model to see just how your color changes within each space. If you wanna get crazy, you can see how interpolation in one space _looks_ in another space. All great for subjectively evaluating color. Color spaces are offered that are outside the RGB spectrum, but all colors are *clamped* to RGB since that’s where they will be displayed (generally speaking). 

@sebfriedrich, the issues you point out for color are 100% spot on. What I want to add to that is that linear interpolation is flawed in its own right. It results in unusual outcomes (eg “making something 120% lighter”) because the interpolation is happening in a non-perceptual color space (transforming each channel of RGB color). L*ab and Lch get closer to a perceptual space, and there are color appearance models that (when using a normalized baseline) appear to enhance these previous models (CIECAM02 for example). These models change the numeric representations of color to fit more closely with how humans perceive color properties. So **in theory**, and from a mathematical standpoint, linear interpolation in one of these spaces **should** give the best result, however that is not always the case. Designers must still make informed, **subjective decisions** about color regarding the **path that a color should take as it becomes lighter or darker**, because it’s not only the color identity that is influencing these paths, but it’s also the subjective feeling or interpretation of brand that they represent — in some cases this means color must change *hue* as well. 

### Conclusion
_Sorry for the rant about color._ :-) 

Tokens should be authored in a hybrid tool that is neither an existing design tool, nor an existing engineering tool. Fundamentally, systems design is a unique form of design that is a prerequisite to the creation of tokens. We need that tool. 

-- 
GitHub Notification of comment by NateBaldwinDesign
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/43#issuecomment-710155955 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 16 October 2020 16:12:17 UTC