Seems like a lot of the comments are not getting it.
The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions.
Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green.
When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time.
This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows.
It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR.
An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.
CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.
I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise thatâs done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and thereâs tons of stakeholders you have to align due to the risk to the brand.
Front end engineers love to opine over amazingly flexible design systems, though.
This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize".
That said, it's not just about "updatability" of systems, it's in great part about scaling a design language across multiple surfaces, products, modes, locales, and sometimes even multiple brands.
The orthogonal complexity of design decisions can be pretty high, and does requires powerful interoperable tooling to handle. Hence the need for this methodology and a spec.
> CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers.
Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.
As I get older, I have grown to really distrust any technological choice of having a "single source of truth" and "Cross-Disciplinary" concerns.
Having a tool reconcile data across sources makes sense. Having a single source, sadly, does not. Especially not when you are forcing stakeholders/users to either use a new tool for this, or worse, to change their vocabulary and tooling to support it.
So, I get the desire. It would be nice to have a way to say "this color red is always used for whatever reason." But then you will have people try and layer that on with "for other reasons, things of another type will always be darker by about 4 shades." Someone will see one of these interactions go poorly, and add whatever emphasis they can to the rule they care about. Then the obfuscations begin.
You're right in that the "centralized single source of truth" actually rarely is a thing at scale.
It's common to adopt a mixed approach: some design tokens make sense to centralize (like global brand colors), and others are local, such as tokens for a specific product or sub-brand.
For example, a web app can build its own token architecture based on an existing foundation shared with iOS and Android apps. They share _some_ concerns, but technical implementations differ they may offer different theming features, too.
Most realistically, the main alternative will be processes focused on product release. With a statistical acceptance of mistakes. Consider that Coke has a specific shade that they have used for a long time.
My main problems with efforts like this is that they cannot distinguish between different organizational priorities on design considerations and they make virtually no allowance for what different practitioners are using today.
That later point is the one that drives me the most crazy. We have very few tools that can help reconcile a graphic design to a website. Most of what we have are attempts to change how graphic designs are created so that they can be more directly transferred.
As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operationalizing design. Plus, it creates a growing maintenance burden on the team maintaining that single source of truth.
Can you explain what problem you are trying to solve, and how do you think is the best way to solve it?
The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.
A few members and myself have commented to explain in various ways what we're solving.
This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury.
The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.
Isn't the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?
Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is expressed separately. We also need to provide ways for folks to codify dark mode / light mode / high contrast values.
Another example is what we call "aliases" or "references": a token can reference another one. Their resolution process needs to be specified (as in: when exactly does an alias get resolved in the lifecycle, and how tools must process them, whether it's okay to rasterize them in the CSS/XML/JS/.. output, etc).
Note that we intend to provide a JSON schema, and the community has already published a few TypeScript type definitions, linting tools, and build tools based on the spec.
> some are pixels or rem or whatever
The 'or whatever' part is what we're trying to tame. For example an Android app may need to consume 'dp' values, web 'rem', iOS 'pt'... There are tons more examples where platforms differ in how they would express dimensions, typography, color... The spec provides a way to encode the source tokens, and then translation tools handle the conversion to platform-specific values.
I guess this was my thought - a language/framework-agnostic format for a bunch of variables, but also with some opinion towards how they should be structured (option/decision/component layers) ?
And then standardising it provides opportunities for interop between tools and multiple frameworks etc
I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now.
I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?
It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild.
The main areas that need work for us to publish a "V1" are:
- colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years)
- "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.
It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc.
At a certain scale, design and brand teams need infrastructure to drive change. These teams rarely have sufficient engineering headcount (if any) to build such tooling and delivery pipelines all the way to the user. Having interoperable formats brings alignment across design and engineering toolchains. The industry needs this methodology to be baked in, rather than requiring folks to build their own tooling.
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent.
Now imagine rolling out dark mode across an entire suite of products, or perhaps a brand refresh.
Having a single source of truth and tooling that supports it end to end from design to engineering helps roll out changes fast and on brand. In turn, it's good for the user!
I know a lot of folks here may come from a more backend background so it may help to think of it as: a way to unlock continuous delivery for your design decisions.
What you describe sounds like a config dictionary. What benefit does it offer to standardize that for this very special (and probably rare) use case?
I don't know many companies that could actually have the problem of scaling a design change up to 50 apps, because most don't have 50 apps. But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for design parameters.
If you want such a hard dependency and kind of automation in this case is another question. I could imagine a lot of special cases where this would cause another set of issues with, e.g., accountability (which part of the codebase belongs to which maintainer and so on).
It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me. UI design decisions are rarely artifacts in any deployment pipeline, so more power to the design team then, which is a good thing imho.
I know many companies (enterprises) that actually have this problem of scaling a design change up to 50 apps. These apps are either new products, rewritten parts, outdated "legacy", or stuff that has been outsourced previously. Now these companies are in demand for "rebranding for the digital age". It all depends on how well design tokens integrate into those situations and its used design tools.
A problem I see is also that such enterprises rarely make use of a better ratio than having 2 designers for the whole company, which then, in turn, suffer from opinion overload by various stakeholders. The UI design process produces visual artifacts and good designs always feel simple. I seen it various times that stakeholders therefor wrongly conclude that the design process must be simple, and that's the never ending circle of a designers life. That brings me to another concern...
Since design tokens open up the automation possibilities with specific design pipelines that might find their way into a deployment to production, and it isn't uncommon stakeholder-thinking that "designs are easy" - all that while LLMs are on the rise, mind you - I can also imagine some kind of horror scenarios finally playing out, especially when changes aren't well tested (responsive design, accessibility etc.).
The role of the spec is to have alignment throughout proprietary and open source toolchains, from design tools to CI build scripts to UI frameworks, so everyone working on an experience can speak the same language, have high fidelity end to end, and reusable automations.
The idea that this can be solved through accountability doesn't scale in my experience. So much of this work is maniacal and low-value, there's very little incentive for teams to prioritize it... But in aggregate, UI inconsistencies bring death by a thousand papercuts.
Companies with design infrastructure teams and mature design cultures have automations in place. The goal is to bring such power even to those without design infra teams and early on their design maturity journey.
Correct, I'm fact I've advised a few teams to only introduce layers of abstraction they needed and could actively document & support.
It's very tempting to copy fortune 500 companies because they're the ones with design & engineering who'll have written the most about this... but most folks just need a pretty simple token setup.
> But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for design parameters
This is never a priority, so it never gets done. When it suddenly becomes a priority, you get all the problems described above.
A large company doesnât mean thereâs a team to handle everything. It just means thereâs a lot more people to talk to before you can start work on anything.
Doesn't brand refresh often includes new components and new design language? In creative space, every design agency tries to sell something different to the organization and thus brand refresh will discontinue any prior design tokens and come up with new one.
When working on products that can last decades, you can't just throw away all styling and start from scratch. In this case, design tokens are essentially styling hooks that allow teams to propagate design changes at scale without rebuilding everything.
Can you explain the challenges in standardizing this? I don't mean to say it's simple, but curious which parts were easy to standardize and which part are most contentious.
I appreciate the standardization efforts here so thanks! So I've been working on an accessible color palette creation tool (https://inclusivecolors.com/) and wanted to add export formats that were easy to import into other tools.
For Figma, amazingly there doesn't seem to be any official/standard way to import variables yet, and instead lots of semi working/broken/abandoned import plugins that support different formats. I ended up adding DTCG, Style Dictionary, and CSS export so the user had some options to try different Figma plugins.
It would have been great if there was a single well supported format that was reliable to use here, instead of having to code several export formats that are all roughly the same. Do you know if Figma will adopt DTCG?
Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Wonât you still have to check every nook and cranny of the UI to make sure the change doesnât break anything?
> Is the goal to be able to change a design token and see that change reflected across all your various UIs?
That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a PR for example)
> How do you ensure people remember to use the design token instead of hardcoding the value?
A combination of great docs, education (onboarding, training), autocomplete, and linting. In design tools, it's baked in to the UI so adoption is less of a problem.
> Wonât you still have to check every nook and cranny of the UI to make sure the change doesnât break anything?
Yes, and that's where visual regression testing comes in and proves valuable to not just developers, but also designers.
For us the killer feature is being able to build the UI once with design tokens and then transform it radically into different themes. In our case the themes serve different brands (of the media company I work for) but more commonly this is a great way to build out light and dark modes.
Our tokens are integrated into the designerâs tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
> Our tokens are integrated into the designerâs tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
Like did you integrate into figma, or write a gui for them, or something else?
The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions
As for the "pretty weird" aspect â it's definitely uncommon but it's been seen before: the $ prefix is also used by the JSON Reference ($ref): https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01... â and just in case, we ran this syntax past Ben Hutton (inventor of JSON Schema) to ensure we weren't doing anything silly.
There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience.
That said, there definitely are other valid ways to solve it.
The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?
This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500.
Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.
It has to be useful for large organizations like for example IBM who need to maintain consistency on various domains, displays and media types. But I suspect it also can stiffle innovation.
It also helps small teams build faster. A shared language around color, spacing, typography makes design/engineering collaboration way smoother, and reduces rework.
A good first step is to have your color palette in your design tool of choice consistent with the variable names used in CSS.
> But I suspect it also can stiffle innovation.
Like any system: it can both be empowering or the opposite.
It's a tough balancing act. Let's say you're Adobe, and you want Photoshop/Illustrator/InDesign to feel like a single family of products across web/iOS/iPadOS/Windows: where do you want to let feature teams innovate, and where must they adhere to the system so users can navigate seamlessly across these products and platforms?
Part of the reason I like design tokens is that they are a middle ground between the chaos of utility classes[0] and impracticality of pure semantics, while being in a way better defined than either of them.
Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue.
[0] When it comes to CSSâof course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.
The term âdesign tokenâ seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the âtokenâ part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors.
Itâs kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but thatâs just how it goes. Inventing jargon isnât bad. There is certainly a lot of programming jargon that we inflict on others.
The core idea seems to be putting visual parameters in a single place that can be shared across platforms. That way you can tweak the design everywhere without having to edit N different platform-specific implementations.
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.
It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.
Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that.
Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.
We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo.
We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects.
Everything was working great until the designers decided the existing tokens were insufficient, and new designers joined who simply chose not to use them (because... reasons).
My point is that tokens work well when there is full alignment between the design and engineering teams. However, it requires extra effort from both sides to consistently "follow the rules".
Of course. If you don't design your system right and enforce consistency it will be a mess. That's programming and pretty much engineering in a nutshell.
This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element".
Here is my slightly edited comment from below:
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.
âDesign tokenâ is an accepted and widely used term (see Amazonâs Style Dictionary, Adobeâs Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike âdesign elementâ, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as âtokenâ rather than âelementâ.
(The term âvariableâ may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.)
As an old-school designer, I didnât like the term at first, but to be honest it is winning me.
I was taught design in terms of design models and design systems, so there was not much of a leap to âdesign tokenâ as referring to a building block.
I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are tied. At the same time, I can see how even while using tokens it is entirely possible to design a bad interface. However, I also see value of them when it comes to maintaining consistent and intuitive UIs.
> I also see value of them when it comes to maintaining consistent and intuitive UIs
Absolutely. It's like the proper legacy of the GoF's "Design Patterns" book, whose lack of importance and acceptance has bewildered me for close on 30yrs now. Of course, it also means I have rich fields to till for my own work, so bwahaha :-)
[Note that the actual design patterns described in their book are not the important part; their understanding that we must implement software using patterns is their most important concept.]
You can already imagine OS vendors publishing their design tokens to let you "easily" integrate your applications even if not using their UI libraries.
I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
DevOps thinking is exactly what got us into this IaC mess we're in now. Back in the day (like 15 years ago), things were actually simpler - you were either dev or ops, period. But then K8s and all that jazz came along, and suddenly we need this whole army of "DevOps engineers" just to keep the lights on and make everything 10x more complicated than it needs to be. And please don't say "yes but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'.
I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate?
The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve.
I can't wait for Design Token Engineers to become a thing /s
Thank you for sharing â sounds like we've had different experiences but I can absolutely see how poorly implemented devops is worse than well-implemented ops.
I've written about operationalizing design and design/engineering collaboration for a while now, and work at a frontend cloud PaaS... So I appreciate hearing from folks outside of my own bubble!
The path from idea to production was arduous for frontend and design back in these days. I for one appreciate being able to deploy frontend changes to production in just a few minutes, which the cloud + SRE + DevOps mindsets have helped democratize.
Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs:
1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code.
2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast.
3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages.
Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices).
I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers!
UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before?
Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers.
The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.
In one sentence: Design tokens are a standardized way of defining constants used in a design system.
If most developers haven't heard of them, it's because most developers don't create design systems. Even when you use a design system, the actual use of design tokens would likely be hidden.
yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer
Well you could distill most "modern" methods to one subtitle of The Mythical Man-Month book: Plan the system for change.
TDD, DDD, extreme programming etc come from the same observation: the client does not know their needs. Even if they do, those could change. So you want to build systems which are easy to change. And we still get thousands of pages published in the form of books or blog post for something written and explained in a book almost 50 years ago.
The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.
Not true. This kind of comment is exactly why most of us flock to this site. It's important to point out when the emperor wears no clothes. There's already an army of self-promotipn types forcing this nonsense onto everyone.
I mean it's kinda jargony and yeah kinda like #define, but I think the idea is specifying a namespace and specific types with a focus on UI/UX design.
In C you'd maybe do it by prefixing all the relevant macros with DESIGN_foo but I think part of the goal of this is outlining all the potential "Foo"s and utilizing it to maintain consistency across a large organization
I'm all for simplifying the indecipherable, but this is a case where things need to be made as simple as possible, but not simpler. Design systems determine how everything looks and feels, and this means specifying a number of things together, such as what colors a button has, how it looks when pressed and hovered, how dialogs look, what is dark mode or light mode, etc. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.
Seems like a lot of the comments are not getting it.
The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions.
Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green.
When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time.
This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows.
It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR.
An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.
I think people get hung up on the term "tokens" and imagine something more. They should've kept it simple and called it design variables or something.
CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.
I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise thatâs done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and thereâs tons of stakeholders you have to align due to the risk to the brand.
Front end engineers love to opine over amazingly flexible design systems, though.
This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize".
That said, it's not just about "updatability" of systems, it's in great part about scaling a design language across multiple surfaces, products, modes, locales, and sometimes even multiple brands.
The orthogonal complexity of design decisions can be pretty high, and does requires powerful interoperable tooling to handle. Hence the need for this methodology and a spec.
> CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers.
Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.
As I get older, I have grown to really distrust any technological choice of having a "single source of truth" and "Cross-Disciplinary" concerns.
Having a tool reconcile data across sources makes sense. Having a single source, sadly, does not. Especially not when you are forcing stakeholders/users to either use a new tool for this, or worse, to change their vocabulary and tooling to support it.
So, I get the desire. It would be nice to have a way to say "this color red is always used for whatever reason." But then you will have people try and layer that on with "for other reasons, things of another type will always be darker by about 4 shades." Someone will see one of these interactions go poorly, and add whatever emphasis they can to the rule they care about. Then the obfuscations begin.
You're right in that the "centralized single source of truth" actually rarely is a thing at scale.
It's common to adopt a mixed approach: some design tokens make sense to centralize (like global brand colors), and others are local, such as tokens for a specific product or sub-brand.
For example, a web app can build its own token architecture based on an existing foundation shared with iOS and Android apps. They share _some_ concerns, but technical implementations differ they may offer different theming features, too.
What is the alternative? "Having a tool reconcile data across sources " ? Is that more or less hard?
Most realistically, the main alternative will be processes focused on product release. With a statistical acceptance of mistakes. Consider that Coke has a specific shade that they have used for a long time.
My main problems with efforts like this is that they cannot distinguish between different organizational priorities on design considerations and they make virtually no allowance for what different practitioners are using today.
That later point is the one that drives me the most crazy. We have very few tools that can help reconcile a graphic design to a website. Most of what we have are attempts to change how graphic designs are created so that they can be more directly transferred.
> processes focused on product release
+10000
As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operationalizing design. Plus, it creates a growing maintenance burden on the team maintaining that single source of truth.
Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1]
There's a whole movement bringing DevOps and SRE thinking to design/UX, essentially working on design infrastructure. Design Tokens are a part of it.
Ask me anything â this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more.
1: https://tr.designtokens.org/format/
> Ask me anything (...)
Can you explain what problem you are trying to solve, and how do you think is the best way to solve it?
The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.
A few members and myself have commented to explain in various ways what we're solving.
This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury.
The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.
Isn't the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?
Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is expressed separately. We also need to provide ways for folks to codify dark mode / light mode / high contrast values.
Another example is what we call "aliases" or "references": a token can reference another one. Their resolution process needs to be specified (as in: when exactly does an alias get resolved in the lifecycle, and how tools must process them, whether it's okay to rasterize them in the CSS/XML/JS/.. output, etc).
Note that we intend to provide a JSON schema, and the community has already published a few TypeScript type definitions, linting tools, and build tools based on the spec.
> some are pixels or rem or whatever
The 'or whatever' part is what we're trying to tame. For example an Android app may need to consume 'dp' values, web 'rem', iOS 'pt'... There are tons more examples where platforms differ in how they would express dimensions, typography, color... The spec provides a way to encode the source tokens, and then translation tools handle the conversion to platform-specific values.
"isn't it just... variables?"
I guess this was my thought - a language/framework-agnostic format for a bunch of variables, but also with some opinion towards how they should be structured (option/decision/component layers) ?
And then standardising it provides opportunities for interop between tools and multiple frameworks etc
Yes to everything you say, except for "option/decision/component" as that's up to the users.
The spec is acting just like how CSS doesn't tell you how to name and nest classes.
Why call it tokens instead of variables?
A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term.
I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!
I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now.
I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?
It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild.
The main areas that need work for us to publish a "V1" are: - colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years) - "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.
> Ask me anything â this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more.
How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques?
In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]?
0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sekti...
1 - https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sekt...
It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc.
At a certain scale, design and brand teams need infrastructure to drive change. These teams rarely have sufficient engineering headcount (if any) to build such tooling and delivery pipelines all the way to the user. Having interoperable formats brings alignment across design and engineering toolchains. The industry needs this methodology to be baked in, rather than requiring folks to build their own tooling.
> At a certain scale, design and brand teams need infrastructure to drive change
What does this mean?
Do you have a concrete example of where this actually solves a real problem? And what problem would that be?
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent.
Now imagine rolling out dark mode across an entire suite of products, or perhaps a brand refresh.
Having a single source of truth and tooling that supports it end to end from design to engineering helps roll out changes fast and on brand. In turn, it's good for the user!
I know a lot of folks here may come from a more backend background so it may help to think of it as: a way to unlock continuous delivery for your design decisions.
What you describe sounds like a config dictionary. What benefit does it offer to standardize that for this very special (and probably rare) use case?
I don't know many companies that could actually have the problem of scaling a design change up to 50 apps, because most don't have 50 apps. But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for design parameters.
If you want such a hard dependency and kind of automation in this case is another question. I could imagine a lot of special cases where this would cause another set of issues with, e.g., accountability (which part of the codebase belongs to which maintainer and so on).
It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me. UI design decisions are rarely artifacts in any deployment pipeline, so more power to the design team then, which is a good thing imho.
I know many companies (enterprises) that actually have this problem of scaling a design change up to 50 apps. These apps are either new products, rewritten parts, outdated "legacy", or stuff that has been outsourced previously. Now these companies are in demand for "rebranding for the digital age". It all depends on how well design tokens integrate into those situations and its used design tools.
A problem I see is also that such enterprises rarely make use of a better ratio than having 2 designers for the whole company, which then, in turn, suffer from opinion overload by various stakeholders. The UI design process produces visual artifacts and good designs always feel simple. I seen it various times that stakeholders therefor wrongly conclude that the design process must be simple, and that's the never ending circle of a designers life. That brings me to another concern...
Since design tokens open up the automation possibilities with specific design pipelines that might find their way into a deployment to production, and it isn't uncommon stakeholder-thinking that "designs are easy" - all that while LLMs are on the rise, mind you - I can also imagine some kind of horror scenarios finally playing out, especially when changes aren't well tested (responsive design, accessibility etc.).
> It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me.
I wish you were responsible for writing the article. This is a much better explanation.
The role of the spec is to have alignment throughout proprietary and open source toolchains, from design tools to CI build scripts to UI frameworks, so everyone working on an experience can speak the same language, have high fidelity end to end, and reusable automations.
The idea that this can be solved through accountability doesn't scale in my experience. So much of this work is maniacal and low-value, there's very little incentive for teams to prioritize it... But in aggregate, UI inconsistencies bring death by a thousand papercuts.
Companies with design infrastructure teams and mature design cultures have automations in place. The goal is to bring such power even to those without design infra teams and early on their design maturity journey.
> early on their design maturity journey
I would argue that it's not in anyone's interest to add such kind of complexity when it's not needed.
Correct, I'm fact I've advised a few teams to only introduce layers of abstraction they needed and could actively document & support.
It's very tempting to copy fortune 500 companies because they're the ones with design & engineering who'll have written the most about this... but most folks just need a pretty simple token setup.
> But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for design parameters
This is never a priority, so it never gets done. When it suddenly becomes a priority, you get all the problems described above.
A large company doesnât mean thereâs a team to handle everything. It just means thereâs a lot more people to talk to before you can start work on anything.
> or perhaps a brand refresh.
Doesn't brand refresh often includes new components and new design language? In creative space, every design agency tries to sell something different to the organization and thus brand refresh will discontinue any prior design tokens and come up with new one.
"it depends"
When working on products that can last decades, you can't just throw away all styling and start from scratch. In this case, design tokens are essentially styling hooks that allow teams to propagate design changes at scale without rebuilding everything.
How about instead we just start making companies smaller but have more of them?
The UNIX philosophy doesn't play well with the ego of ones business, unfortunately.
Can you explain the challenges in standardizing this? I don't mean to say it's simple, but curious which parts were easy to standardize and which part are most contentious.
I appreciate the standardization efforts here so thanks! So I've been working on an accessible color palette creation tool (https://inclusivecolors.com/) and wanted to add export formats that were easy to import into other tools.
For Figma, amazingly there doesn't seem to be any official/standard way to import variables yet, and instead lots of semi working/broken/abandoned import plugins that support different formats. I ended up adding DTCG, Style Dictionary, and CSS export so the user had some options to try different Figma plugins.
It would have been great if there was a single well supported format that was reliable to use here, instead of having to code several export formats that are all roughly the same. Do you know if Figma will adopt DTCG?
Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Wonât you still have to check every nook and cranny of the UI to make sure the change doesnât break anything?
And if thatâs not the goal, what is the goal?
> Is the goal to be able to change a design token and see that change reflected across all your various UIs?
That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a PR for example)
> How do you ensure people remember to use the design token instead of hardcoding the value?
A combination of great docs, education (onboarding, training), autocomplete, and linting. In design tools, it's baked in to the UI so adoption is less of a problem.
> Wonât you still have to check every nook and cranny of the UI to make sure the change doesnât break anything?
Yes, and that's where visual regression testing comes in and proves valuable to not just developers, but also designers.
For us the killer feature is being able to build the UI once with design tokens and then transform it radically into different themes. In our case the themes serve different brands (of the media company I work for) but more commonly this is a great way to build out light and dark modes.
Our tokens are integrated into the designerâs tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
> Our tokens are integrated into the designerâs tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
Like did you integrate into figma, or write a gui for them, or something else?
Why does the format use $-prefixed keys? That's pretty weird as far as JSON schemas go.
The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions
As for the "pretty weird" aspect â it's definitely uncommon but it's been seen before: the $ prefix is also used by the JSON Reference ($ref): https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01... â and just in case, we ran this syntax past Ben Hutton (inventor of JSON Schema) to ensure we weren't doing anything silly.
You can usually do this by only being additive with the spec, and by never mixing user-defined keys and spec-defined keys in the same object.
I've only ever seen $ used before with meta properties that work across all schemas like the $ref you mentioned and $schema.
There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience.
That said, there definitely are other valid ways to solve it.
Not just weird, it kinda overlaps with json schema builtins like $schema, $ref, $id, etc
The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?
This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500.
Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.
It makes sense, but I struggle to see the value outside of whitelabel products that you may look to rebrand, but with the same UI.
Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change.
You eventually end up with a rebranding and along with that some sort of UI refactoring.
This approach is incredibly valuable when building something that won't change drastically when you are changing those tokens.
It has to be useful for large organizations like for example IBM who need to maintain consistency on various domains, displays and media types. But I suspect it also can stiffle innovation.
It also helps small teams build faster. A shared language around color, spacing, typography makes design/engineering collaboration way smoother, and reduces rework.
A good first step is to have your color palette in your design tool of choice consistent with the variable names used in CSS.
> But I suspect it also can stiffle innovation.
Like any system: it can both be empowering or the opposite.
It's a tough balancing act. Let's say you're Adobe, and you want Photoshop/Illustrator/InDesign to feel like a single family of products across web/iOS/iPadOS/Windows: where do you want to let feature teams innovate, and where must they adhere to the system so users can navigate seamlessly across these products and platforms?
Part of the reason I like design tokens is that they are a middle ground between the chaos of utility classes[0] and impracticality of pure semantics, while being in a way better defined than either of them.
Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue.
[0] When it comes to CSSâof course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
Agree, you tap into the rigidness of a semantic color and type hierarchy, while allowing utility classes for specifics of a platform/environment.
It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.
The term âdesign tokenâ seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the âtokenâ part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors.
Itâs kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but thatâs just how it goes. Inventing jargon isnât bad. There is certainly a lot of programming jargon that we inflict on others.
The core idea seems to be putting visual parameters in a single place that can be shared across platforms. That way you can tweak the design everywhere without having to edit N different platform-specific implementations.
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.
same. I don't understand what he is talking about. is he working in front-end? sounds like tons of "consulting" talk.
It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.
Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that.
Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.
It's not like this is a new concept, here's bootstrap almost 15 years ago:
https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo. We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects.
Everything was working great until the designers decided the existing tokens were insufficient, and new designers joined who simply chose not to use them (because... reasons).
My point is that tokens work well when there is full alignment between the design and engineering teams. However, it requires extra effort from both sides to consistently "follow the rules".
[1] - https://tokens.studio/plugin
[2] - https://amzn.github.io/style-dictionary/#/
Of course. If you don't design your system right and enforce consistency it will be a mess. That's programming and pretty much engineering in a nutshell.
This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element".
Here is my slightly edited comment from below:
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.
âDesign tokenâ is an accepted and widely used term (see Amazonâs Style Dictionary, Adobeâs Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike âdesign elementâ, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as âtokenâ rather than âelementâ.
(The term âvariableâ may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.)
[0] https://github.com/design-tokens/community-group
Thanks. That makes sense, even if my old-school brain finds the term less than optimal.
As an old-school designer, I didnât like the term at first, but to be honest it is winning me.
I was taught design in terms of design models and design systems, so there was not much of a leap to âdesign tokenâ as referring to a building block.
I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are tied. At the same time, I can see how even while using tokens it is entirely possible to design a bad interface. However, I also see value of them when it comes to maintaining consistent and intuitive UIs.
> I also see value of them when it comes to maintaining consistent and intuitive UIs
Absolutely. It's like the proper legacy of the GoF's "Design Patterns" book, whose lack of importance and acceptance has bewildered me for close on 30yrs now. Of course, it also means I have rich fields to till for my own work, so bwahaha :-)
[Note that the actual design patterns described in their book are not the important part; their understanding that we must implement software using patterns is their most important concept.]
You can already imagine OS vendors publishing their design tokens to let you "easily" integrate your applications even if not using their UI libraries.
I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
Thanks. That's not my workspace, so it makes sense that I would be unaware of it, my just being a programmer.
> There's a whole movement bringing DevOps and SRE thinking to design/UX
Heaven help us. Hope this dies a quick death.
Say more
> DevOps and SRE thinking
DevOps thinking is exactly what got us into this IaC mess we're in now. Back in the day (like 15 years ago), things were actually simpler - you were either dev or ops, period. But then K8s and all that jazz came along, and suddenly we need this whole army of "DevOps engineers" just to keep the lights on and make everything 10x more complicated than it needs to be. And please don't say "yes but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'.
I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate?
The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve.
I can't wait for Design Token Engineers to become a thing /s
Thank you for sharing â sounds like we've had different experiences but I can absolutely see how poorly implemented devops is worse than well-implemented ops.
I've written about operationalizing design and design/engineering collaboration for a while now, and work at a frontend cloud PaaS... So I appreciate hearing from folks outside of my own bubble!
The path from idea to production was arduous for frontend and design back in these days. I for one appreciate being able to deploy frontend changes to production in just a few minutes, which the cloud + SRE + DevOps mindsets have helped democratize.
Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs:
1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code.
2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast.
3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages.
Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices).
I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers!
UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before?
Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers.
The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.
someone should write an article explaining this in folk language
In one sentence: Design tokens are a standardized way of defining constants used in a design system.
If most developers haven't heard of them, it's because most developers don't create design systems. Even when you use a design system, the actual use of design tokens would likely be hidden.
Material Design uses them. https://m3.material.io/foundations/design-tokens/overview
Fluent UI uses them. https://fluent2.microsoft.design/design-tokens
So, basically #define?
yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer
Well you could distill most "modern" methods to one subtitle of The Mythical Man-Month book: Plan the system for change.
TDD, DDD, extreme programming etc come from the same observation: the client does not know their needs. Even if they do, those could change. So you want to build systems which are easy to change. And we still get thousands of pages published in the form of books or blog post for something written and explained in a book almost 50 years ago.
The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.
This kind of comment isn't welcome here...
> This kind of comment isn't welcome here...
Not true. This kind of comment is exactly why most of us flock to this site. It's important to point out when the emperor wears no clothes. There's already an army of self-promotipn types forcing this nonsense onto everyone.
Why do you say that?
Said who, a consultant?
I mean it's kinda jargony and yeah kinda like #define, but I think the idea is specifying a namespace and specific types with a focus on UI/UX design.
In C you'd maybe do it by prefixing all the relevant macros with DESIGN_foo but I think part of the goal of this is outlining all the potential "Foo"s and utilizing it to maintain consistency across a large organization
It's just the usual over-engineered BS that can be expected from the domain in question - my 2 cents.
âTokensâ makes me think of crypto/blockchain. Suboptimal naming.
For context, this name was coined 10 years ago, before the crypto/blockchain craze.
what is so "architecture" about constants?
Consultancy money. Why should Robert Cecil Martin have all the fun? Other Martins want in.
There should be some research into how many code bases have been ruined by these panacea peddlers.
> what is so "architecture" about constants?
I'm all for simplifying the indecipherable, but this is a case where things need to be made as simple as possible, but not simpler. Design systems determine how everything looks and feels, and this means specifying a number of things together, such as what colors a button has, how it looks when pressed and hovered, how dialogs look, what is dark mode or light mode, etc. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.
Compare with Cue, Jsonnet, etc. Systems for sharing configuration settings can get pretty elaborate when itâs done at scale.
The millions of websites designed without using them. This insight was lost at some point, even if it seems obvious in retrospect.