Naming things is hard.
One way to go about naming things is via topology, the practice of classifying things by way of their visual characteristics. It is a subtle art.
Topology is a good approach for the naming of design tokens. Unfortunately, in the context of design token name creation we are burdened by the tyranny of category. It demands distilling everything down to a single word, and consequently, a linear order.
Because of this, you need to craft a taxonomical structure that leads to results whose end point should be immutable:
This kind of codification is desirable because it creates:
- A more precise grammar,
- More easily-identifiable deviations from canonical values,
- Less ambiguity across one or more teams authoring and consuming the tokens, and
- Less overall maintenance.
A mature token name
Design token names can be as simple or as complicated as you need them to be. In my experience, it is best to start out simple, then grow them to meet the needs of your design system as it grows.
This approach takes advantage of one of the main benefits of design tokens: being able to target a canonically described quality distributed across one or more systems, and then modify it with an extreme degree of confidence.
Mature token names are long, because they represent a ton of underlying abstraction. To help illustrate this, we'll identify a single token extracted from a text input component:
This token’s name is derived using the grammar of an established design system:
The token name might seem like a lot, potentially to the point of seeming absurd to you. However, I can assure you that in a large, mature design system that this level of detail is needed.
What I’m proposing has already been discussed by Nathan, notably this part:
Similarly, interfaces vary feedback color to alert the user of:
- success (aka
- error (aka
- information (aka
The design systems I work on have feedback-level considerations, so this definitely resonated with me.
In my experience, validation is oftentimes lumped in with user-facing state, so you’ll have valid/invalid values exposed at the same level as hover/active/focus values. I’m not so sure that’s a great idea.
Consider the following situation, where an invalid text input has a hover effect. How do we accommodate this?
What I’m proposing is where validation feedback should be placed in the token’s naming structure.
Where do you put validation feedback in a design token?
Remember: we want to whittle down our potential futures as much as possible.
Becasue of this, I propose that validation is placed after Type, and before State. This allows you to have a space where validation feedback can have user-facing state applied to it:
This is how our design token could be inserted into code. You’ll notice the Sass nesting strategy follows the token’s order of precedence:
// 1. Import border color token into initial component-level properties
// Other initial component-level CSS Custom Property declarations
// Other initial component declarations
// User-facing validation state styling
// 2. Redefne our border color with an updated token
And here’s how our token’s structure would translate to use it in English:
In ourdesign system, what is the value for the of a of a with content placed on a while is active?
I quite like the “translate it into English” bit, in that it helps inform a shared vocabulary to verbally communicate the totality of consideration to your peers in a consistent way.
So, there you have it: Codified and encapsulated validation state.