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

Hey @jina,

I had a brief look at several issues in this project here and I appreciate that your demand targets the direction of design process. It is quickly getting very technical here and there.

> As a designer, using the design tool of your choice, what would your ideal workflow be to define/deliver tokens?

## tool chain along the design process
It is about tools (plural) not THE tool :-)

Figma in general gives a good presentation of what I expect these days from a interaction design tool. The controls offered are fairly good enought to setup a representation of the design system's tokens in regard to what a designer produces in that tool (mainly prototypes). But as @dashouse already points out to some extend, Figma (or any competitive tool) is **not the source of truth** here, it is one of the deployment targets of a design system as well as some (JS) code is. Token definition should also not be limited by a certain tool, we should accept the fact that usage of a token is projected into application but it is one way and might involve potential loss in the conversion to be acknowledged.

## the role of the designer

It seems natural expecting a designer to curate colors and then share them for implementation as a designer mostly owns this domain. But it is a typical designer perspective on the world and doesn't allow for developers to become stakeholder in the process. To ensure developers can apply color correctly, token names and structure must align with a shared vocabulary. Any suggestion which promotes writing up some js files in a repo as well as generating a file from a design tool and pass it to a repo is biased thinking which I disagree with. These approaches create silos controlled by the one or the other role.

## color picking

I would actually wish for a tool a little more in the fashion of common color pickers on the web [Adobe Kuler](http://color.adobe.com) or [Colormind](http://colormind.io/bootstrap/) or [Color Review](https://color.review/). The perfect picker is not existing yet (in my opinion) as all these pickers leave you alone with the user flow you should follow to leverage them. Personally I use at the moment a combination of Excel to inform myself meeting expected levels of saturation, lightness (compensated for human perception), reading contrast, different eye cone stimulus, gamut coverage etc. while best-guessing utilizing self-made PSD templates and trying to tweak one color dimension at a time. This means I control what I can visually compose with some number indicators helping me judge the output reliably. This isn't perfect nor quick to do, but allows for measuring outcome, keep personal preference out and realize when its done. So Excel basically runs some kind of test cases and the basic idea is test driven color design what I try to achieve.

## typography

Somewhat same with test-driveness it is with tokens representing typographic style. If you want to judge and optimize a `line-heigth` which supports reading a long copy text best, you actually need a testcase with exactly such a text, in the right font and the right size, with the right runlength etc. Normally I use a design tool like Figma and build out samples of the use cases what turns the generic design tool into some token design environment, but it isn't out-of-the-box.
Also it is work intense to replicate as-is when starting with something given from legacy. 
Eventually I have a set of tokens to use for text. If I can categorize, what the text is about, I can choose the right token. I am not allowed to pick the font-size here and the text-color from there, I pick a tuple instead which offers a valid combination.

## the technical side / exchange formats
For sure, we need some human and machine readable format that is well-documented and stays reliable even when extended over time. So far so good.

I hesitate to just make a call for some JSON notation, just because many of the token usage will happen in the space of developing for the web, what effectively means ECMAScript to the widest extend. But design systems can also serve regular print, interior or physical product designs. First of all, a design system is just the logical extension of what was before known as corporate identity or other design guidelines. With the difference, that 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.

## other pitfalls

I just want to mention briefly to consider

* Having heard of [The rule of least power](https://en.wikipedia.org/wiki/Rule_of_least_power) one might find helpful when figuring out an exchange format
* Hexcodes for colors are biased. They are a syntactical transformation of sRGB. sRGB has lots of quirks which are designed for efficient encoding but not best authoring capabilities. The color profile is implicitly assumed. The color space used for reference in the internal represenation of color in a token is crucial.
* [JSON isn't performant](https://www.toptal.com/web/json-vs-xml-part-1) just because it's expression in text characters or filesize is a little less than the same expressed in XML for instance. JSON isn't easy to parse. It is also not ideal for text diffing happening in version control systems. I am not against it at all, but choose wisely
* When tokens can define other tokens (yes in theory I wish for that too @lukasoppermann), we should be able to do more, than just referencing them. Blending them or swapping between options by some threshold and so on are _Methods_ taking tokens as input. Probably they are expected to work agnostic to the input and output format of a color - to run such Methods, again managing color spaces comes into play. I see assigning a new pointer to some otherwise unchanged token as the simplest form of such a Method.
* Creating a design system means narrowing down on design choices a designer applying it needs to make. It is a level of abstraction. This is what speeds up the design process. Design systems which allow for very various combinations of super granular design tokens with lots of dependency levels miss their goal. It is an optimization polarity between designers `freedom of choice` and `time to product` what needs be balanced out when creating such a system.


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


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

Received on Wednesday, 14 October 2020 12:36:51 UTC