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

I think what would be good to keep in mind is, that the needs will change drastically depending on the project & the state of it.

In one scenario a designer works in a big organisation or otherwise on a project were the design tokens are defined by a different team. In this case, having your tool mere consume tokens and presenting them as options would be fine.

In another scenario, a designer creates a new product or for other reasons works on the design system. In this case being able to define tokens from within the tools where you figure out their values is extremely helpful and will make the adoption of this methodology much more likely.
From my personal experience it is rare, that tokens are a thing that you define only once. Especially in the beginning adjusting colors is common, e.g. when adding a secondary color you may need to nudge your primary one into a specific direction or add a tint to your neutrals.

@sebfriedrich concerning your second to last point:
> 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.

Can you please elaborate? I don't quite get what the "pitfall" is here? 😄 


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


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

Received on Thursday, 15 October 2020 12:41:33 UTC