Episode 32 Raw Data

	A	B	C
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 32, deep dive hosted on September 12, 2024 with Ben Callahan and Donnie D'Amato. There are 85 answers. The question this week was: ----- Hello curious people! Donnie and I have been talking token architecture and we want to bring you into the conversation this week on The Question. These days, there are quite a few design systems with publicly available documentation sites. These sites are often as much about marketing as they are about instruction, but they are fantastic for seeing how other smart people have already solved the problems you’re currently trying to solve. The benefit of this is that you can find other great solutions to model your own after. The challenge is that you can spend a lot of time copying what has worked for another organization before you realize whether or not it will work for you. One area where this is particularly prominent is in how an organization architects their tokens. This week, we’re diving into the origin of your token architecture, talking about what’s working and what’s not, and discussing some fresh thinking around tokens in general. With all of this as context, here is The Question for this week: Does your design system program have design tokens? If your design system offers tokens, how did you determine the architecture and naming conventions? If your design system doesn’t offer tokens (or you’re not sure), how would you go about determining the architecture and naming conventions? If your design system doesn’t offer tokens (or you’re not sure), how would you go about determining the architecture and naming conventions? What challenges do you currently see, or expect to see, with your token architecture and naming conventions?
2	Question 1: Does your design system program have design tokens?	Question 2: If your design system offers tokens, how did you determine the architecture and naming conventions? If your design system doesn’t offer tokens (or you’re not sure), how would you go about determining the architecture and naming conventions?	Question 3: What challenges do you currently see, or expect to see, with your token architecture and naming conventions?
3	Yes	We tried to choose as simple, yet flexible, an architecture as we could. We went with a three-layer approach of core, semantic, and component tokens, prefixed with the design system name in shorthand.	This has worked well for the central team, but we’ve not documented or explained this well enough yet to be as effective externally. The architecture is also specific to our choice of theming, whereby we swap the whole token set, but could be tricky with mixed theming or multi-brand.
4	Yes	Determine how many themes and modes within themes we need support for the business. Then determine how far we can go with semantic naming only and wherever we need to go to component level tokens we determine that too. Of course we establish a global set of tokens for a spatial system, type and color. The taxonomy of tokens is detailed out with the help of the engineers	Multi themed applications and supporting legacy systems
5	No	na	na
6	Yes	At the moment, I started a new job and I have previously received from the old team a very complex structure, where they used global tokens to create component tokens, without having a semantic in the middle. I plan to simplify this in the long term, keeping only 2 levels of tokens (global and semantic).	I am asking for a big breaking change to the dev team and they can't change it due to their backlog, since my goal is to be release-friendly and be as aligned as possible with the code, which wasn't a concern in the past colleagues—also, making those breaking changes on Figma in a way that doesn't break design assets as much as possible.
7	Yes	Read many articles from Nathan Curtis and iterated a bit during the initial phase to come up with a naming convention that works for us.	Can’t connect our tokens with our Figma variables with our current licence without paying for a plugin. Also there’s a question of how to document the naming convention and make it easy for other designers to continue building on tokens in the future because most designers don’t have experience with this aspect of design systems.
8	Yes	.	.
9	Yes	We are using web components (Stencil) for our component library, which encapsulates each component, isolated from the other components. We also serve two separate color schemes (we're merging two design systems), as well as light and dark mode. Currently, our naming convention is scoped per component using: componentName-attributeType-attribute-state. For example button-color-bg-hover. These tokens point to four different values, depending on color scheme and mode.	There's a lot of duplication and bloat, since we're repeating the same values across many components.
10	Yes	At the moment, we have a massive spaghetti factory mess of nonsensical t-shirt sizes and bodges names/categories which was defined by a designer who did the first iteration and didn't know what he was doing. Now, I've made it the responsibility of the developers in the team to think about this (which should have been the case to begin with) so that they can take the design intent as input and actually engineer a flexible, sensible and extendable tokens architecture that works. This will take time though, and in the interim, we are just doing unstructured overrides to changes the presentation of components within our 3 critical themes.	The actual design language of an important new theme has not yet been adequately thought about a designed properly. It's very difficult to construct a token architecture without have a good fine grained understanding of what the design decisions it should actually cater for are.
11	Yes	We’re still answering this question. This far, it’s been a process of research and hunting for models we like enough to want to follow. Some clients already have established architectures while others need us to create it.	One challenge is how tokens are implemented within Figma as variables and the limitations that come with that.
12	Yes	Followed CTI naming, informed by additional research/articles/community discussions.	Building a white label DS for a very large creative agency, we are currently revamping our token architecture to follow the latest practices but mainly through the lens of extreme clarity for consuming teams and simplified brand theming for non-system designers who aren’t as familiar with concepts of tokens.
13	No	We're currently starting to work on defining the naming convention.	The biggest challenge at the moment is re the amount of tokens we may end up with. We've seen ways of reducing the amount of tokens but then we risk getting to restrict. We also looked at creating groups of tokens for certain components, but still not sure if that's the way to go.
14	Yes	This is a painpoint a bit of a power struggle at the moment.	agreeing on naming convention
15	Yes	We follow MUI semantics 😣	Extending the theme/tokens. As a designer I’m unsure whether this is because of the complexity of the APIs or user and builder knowledge around tokens.
16	No	I would follow google guidelines	They are too complex to adopt
17	Yes	I’m speaking about my previous company: This was about a 6 month process. Conducted external and internal interviews, tested with designers and engineers, and designed with context. Tested ideas against old UI screens and the new design language we were rolling out	It is intentionally restrictive in some areas. For example, we offered only one primary color for backgrounds. When I pulled the old repo I found that there were new tokens arbitrarily added. If tokens are added just to unblock a use case, eventually there will be too many tokens.
18	Yes	I feel like the naming conventions were not given a lot of attention. I feel like they were thought more of as “variables” as opposed to a token architecture.	One of the issues I see is actual usage and implementation. Our tokens are seen as root level variables, so the issue is utilizing them in a way that can scale and have changes propagate thorough out the design system.
19	Yes	First looked at other design systems and any best practice standards we could find. Then we looked at what the needs of our UI was to help determine large categories of UI that could be styled together using token sets. From there we broke everything down in figjam, looking at language and names and testing our way to seeing what might work.	None specially but mostly a concern that we might have too many tokens at any point. We tried to use the misenmode approach for one elements in a light theme appear on a dark background, but our Dev teams weren't able to do it so we not only have light and dark themes but also support for inverse tokens inside those themes. Architecture wise, the challenge that we're going to be facing is mostly needing additional tokens for product specific libraries at the semantic level. But this is more of a problem for how we design across multiple organizations and brands in my opinion and shouldn't be solved through tokens but rather alignment with those teams. Naming wise, we've been able to flex pretty well so I don't have any concerns in those areas that I can see right now
20	Yes	I tend to think simple is better. I do a deep dive on our brand colors and which values we actually need/use for a specific purpose. Typically I'm interested in creating scales (whether it's color, space, type, etc). The needs/current usage determine the increments on each scale. The scales tend to be my first layer (base/core). The second layer tends to be where I name the tokens according to their function (semantic layer). At this level we can introduce modes if needed. Since they are named according to job, the job typically stays the same when switching between modes keeping the name informative. I rarely create third layers because—hot take, I don't want to! A third layer hasn't simplified or streamlined my life yet, nor has it increased my consumer's enthusiasm for any given system I've been a part of.	Honestly, this has worked pretty well 🤷‍♀️
21	Yes	We truly need to reassess our token architecture.	Scalability
22	Yes	We start from a common base that we have established that is a good starting point for new systems (agency work). We then take a selection of common components and the various themes or brands we are supporting, and make sure the token architecture supports the components across brands. Adding or removing tokens as we go.	It's not uncommon for a client to add a theme to a system after the token architecture has been established. Sometimes that architecture doesn't directly support all of the design customization that a designer might want for the new theme. Creating a token architecture that is flexible without being overwrought is a delicate balance.
23	Yes	We've adapted Github's naming conventions (prefix, namespace, pattern, variant, property, variant, scale) https://primer.style/foundations/primitives/token-names	As with everything, the biggest challenge is communicating the naming convention across teams and ensuring everyone is aligned with the approach.
24	Yes	I'm not the most in the weeds when it comes to our token architecture, I"m here to listen :)	I hope to bring my designers/UX engineers to the session.
25	Yes	I created the CTI+ Taxonomy and use that as the blueprint for naming tokens. https://medium.com/user-experience-design-1/how-to-name-tokens-in-a-design-system-5b218589dadc. The taxonomy is a collection of dynamics which has a specific responsibility of information/language. Much like a table-top game, the system is built upon easy to follow rules.	Our system is 'nounless', or avoids the use of the ITEM dynamic that describes a specific component. There is no color-primary-button-background. Instead it is interactive-primary-030. I suspect we need to consider adding ITEM dynamics and/or possibly abstract to embrace a Warhol naming convention.
26	Yes	We decided to break our design token architecture down into the standard three tiered system (global tokens, semantic tokens, and component tokens). However, application of our design token architecture looks different because some of our component level tokens link directly to the globals, AND some of our semantic tokens are linked directly to the component itself.	One particular challenge we saw in the beginning of our token naming convention was the issue of either front loading the component name, and token location, in the naming convention or backloading it in the token name. Devs find it easier to read tokens if the most relevant token info is back-loaded to the end of the token, but product designers have a difficult time finding and viewing color tokens (published as local styles) if the most relevant token info unless the important info is front-loaded to the beginning of the token.
27	Yes	This was quite a process! I started with a lot of research that included reading through every article I could find. This 10-part series was one of the most thorough and helpful, https://gos.si/blog/inside-design-tokens-definitions-traits. I audited all of our components and went through several rounds of exercises that started with mapping audit results to different naming conventions, like the ones from Nathan Curtis (https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676) and Nate Baldwin (https://medium.com/@NateBaldwin/creating-a-flexible-design-token-taxonomy-for-intuits-design-system-81c8ff55c59b). Because we weren't starting from scratch as a system and had many organizational things to consider we probably ended up with a more complex blend of the two to start with. Then came the conversations about what to do with component tokens vs. more shared semantic ones. Opinions are all over the spectrum for this one, and I spoke to folks with opposing approaches, including some time with Donnie! After that we went through another round of revisions to try and get as semantic as possible to avoid component tokens. We still have a few, but will continue to adjust. Towards the end of the main effort I mapped out all of the considerations I had to consider for naming, and there were well over two dozen that included everything from our tooling to historical naming, modes to principles, and tooling to language. The current state of our naming is documented at https://design.gitlab.com/product-foundations/design-tokens. As we continue to tokenize remaining components and concepts we're also fine tuning the naming and making adjustments as needed. I suspect this will be baked into our process moving forward.	So far the naming convention has worked well and helped us align on many decisions. Ironically, one of the main challenges is getting all tools to be able to use the tokens. Figma, in particular, doesn't allow certain naming or structural conventions, so we've got our own plugin to translate things out of Style Dictionary into Figma so the structure and inheritance ends up being correct for design. Our company has team members in over 60 countries. A design token name can often read like a sentence. Having it read or interpreted the same in all locals can be challenging when a different order of terms infers a different meaning. This hasn't been a big problem, but it does factor into decisions.
28	Yes	Lots of research and Medium articles Nathan Curtis is the man. Our architecture was determine by the early decision that we wanted a high level of specificity to our different brands, so that meant component specific tokens. Naming convention is an ongoing process, I originally named created the convention by myself with input from engineering, but as we got deeper into it, I wished it had been more of collaboration. Our names are fine, but they could be streamlined more.	on the UX side, out biggest issue is changing platforms (Token Studio to Figma variables) and how we are able to work with the UI available For the most part our token naming and architecture is working well enough.
29	Yes	We name them based on semantic usage guidelines and group them based on such. For example, we group tokens by typography, interaction type, surface/screen, and branding.	Some challenges we've encountered are designers misusing the tokens at times because they want to use them based on visual vs semantics. We've limited the tokens in Figma's variables to certain usage types, such as stroke, fills, typography, etc. But when a designer tries to search for a particular token that doesn't show up because we limit the tokens, designers tend to think it's a bug or issue.
30	Yes	Whew!! I’m the token person at my spot, and I did a ton of research before coming up with a hybrid naming structure for our system heavily based on Nathan Curtis’s structure but very much tailored to our system. I went and audited every component in our system and I nice we gathered I found and grouped and categorized all of the states and color/ type changes, and sort of whittled all of our choices down so we could clearly see where things overlapped and then went from there.	The thing about tokens is understanding how to build them in a way that acknowledges that things change and scale and that’s ok. Plan accordingly as best you can but just remember things will change. You may have to rename or restructure based on shifting needs but your naming convention should help make things a bit easier if you’ve accounted for that as part of your naming strategy.
31	No	in design we use a very limited set of styles that are tokenized in code. They styles are more like primitives than trues tokens. We expect to go deeper into tokening in the future but honestly need some guidance.	refactoring effort, design adoption
32	Yes	We have several different colors, each with different lightnesses (blue90, blue50, etc). I think we set them up this way because we saw that’s how other design systems were set up.	The biggest issue we have is that people often hard code the colors instead of using the tokens. It’s hard to catch until we try to make changes.
33	Yes	It is in development, but it is really a mix of industry standards, user testing and engineer/designer feedback.	Lack of general knowledge about design tokens itself. No matter what nomenclature we use, a lot of education will be needed.
34	Yes	Naming them to easily identify what they are "name/state" for instance.	Trying to get everyone to adopt the system I believe is the challenge.
35	No	I think the namespace Nathan Curtis has suggested makes a lot of sense.	Determining high-level namespace (mode, theme, etc) and staying scalable. e.g. my company waffling on whether they want dark mode or not.
36	Yes	We followed Nathan Curtis's guidance (https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676) for the most part.	There's a bit of a discrepancy between Nathan's guidance and how front-end devs see tokens naming (more closely matching CSS property/value structure. What CSS properties need to be tokenized? What should be and what should not be a semantic token? When does something need to be a component-level token vs creating a new semantic token?
37	Yes	There are "realms" of marketing (usually prefixed with "m" to make it obvious), and the rest is assumed to be product UI. Tokens are grouped by component or UI area like header, footer, global nav, component name, layout type. Tokens are then divided into categories such as color, type, size, spacing. And finally size or some other attribute.	Too many tokens. So I like to grow them organically as needed, not overthink it.
38	Yes	We do have tokens. As the only content designer working on the system when we adopted tokens, I never had time to focus on that taxonomy. But, I’m deeply interested in learning how others approach this.	Unclear names and potential problems that come up as the system grows.
39	Yes	Worked on naming for a few different systems. General principles I've followed are to use system names that are unique and separate well (not likely to be used elsewhere in code. Human readable. States intention if applicable. I've experimented with using steps in scales to represent size increments so X1, X2, X3 vs small, medium, large. some success with this approach. I think simpler better, it can be tough to reflect a system's structure in naming. I do like global vs local.	In a recent experience a lot of naming decisions baked into the CMS were not ideal. Departing from those names is a better longer-term option but created some tension upfront. Also - hey Donnie!
40	Yes	Our lead engineer did some discovery work to audit how other systems (and practitioners) have engineered their schema's for the long haul. She took a stab at the overall construct and presented it to the team, where which we all weighed in with feedback and suggestions to evolve the schema for our needs (supporting our Alpha version).	There will be A LOT of consumer education needed (no surprise there) on how/where/what to do with tokens. Being in an Alpha state, we've bought ourselves the freedom to change and evolve that schema (and the system) during a Pilot Phase in January 2025 to make sure our initial decisions can scale alongside the system by way of the organization as a whole.
41	Yes	Architecture is mostly driven by engineering and aligned with user experience designers - naming conventions led by UX but agreed upon and aligned with engineering	None at this time but I’m not as close to that work so I’m sure there will be some
42	I don't know	I answered "I don't know," but the reality is more nuanced. We have some tokenized elements scattered throughout our system, but no unified token structure serving all platforms. Historically, an Android engineer saw the value in component tokens and created some within that library. However, we are now undertaking a larger initiative to establish a standardized token structure that truly showcases the benefits of tokens as understood in the industry (that is hopefully felt by our organization too). I have some experience on the Design side of the house working with tokens, and have run into complexities in the past that were difficult to solve because of the cost on the Engineering side. My goal is to keep token naming straightforward. Yet, when researching best practices, I'm repeatedly struck by the prevailing complexities which seem inevitable. I'm eager to hear about others' learning and experiences in this area.	I expect that our tokens will be complex and that Designers will struggle with them, but that we'll need those complexities to serve the implementation and make them useable on the Engineering side.
43	No	This will have to be a conversation between the designers and each of the platform engineers to ensure the architecture naming convention works for everyone. There are certain questions I would want to answer as a group: What will the naming format of the tokens be? - Prefix in relation to our brand - Anatomy for the rest of the name - Character delimiters between spaces & between parts of the name How will tokens be organized? - To use the pyramid token structure, we need to define each layer of abstractions - We should understand which of these layers are always needed and which are sometimes optional What will the types of tokens be? - This does not have to be comprehensive, but we should have enough types represented for us to adequately stress test. Once we answer the questions adequately, we should stress test on a subset of tokens and extrapolate for future values.	Adoption and consistency across members of the team
44	No	I joined and we only have SASS. I'm starting to implement a token strategy now, so have the benefit of lots of known patterns in production to inform thinking. I am approaching it with a theming/white-label approach, and focusing on the use/intent and expecting to need to be very granular with things. We have a brand refresh in the works, so its the opportune time to wire-up our DS with as-is themed tokens and then iterate on the new theme. Figma isn't the source of truth for our customers, they use what gets shipped. PROCESS: tl;dr Audit → Experiment → Code proto → Refine → Coded tokens → Figma (last, maybe pulling from external) We have a big current state set of categorised specs, I'll start with these and convert them to layers (global, semantic, component) and focus on the first two. Work in a combination of spreadsheets and code, probably not Figma at this point. I'm so temped to just play with Token Studio Graph Engine, but i know it has its own learning curve. NAMING: Separation between layers of tokens, so we have predictable naming structure at the global and semantic layer. Assuming it will be CTI (Category > Type > Item > State), but open to change that. TESTING: 1. Setup Tokens with tooling (style dictionary or other) 2. Branch the DS and setup a kitchen sink of pages and examples of permutations. 3. Rig up components and wrappers with tokens, 4. Test with code and iterate IDEAL/STRETCH: 1. Visual diffing during experimentation phase to capture results easily 2. Rig DS components coded with the "default theme" tokens and shipped to staging environment 3. Setup Chrome Extension with WIP theme(s) and use that to showcase internally, allowing anyone to preview the progress and review/test their own work.	The non-DS components and pages, enterprise need to support legacy tech stacks. The unquantified effort to map the new tokens/theme/modes to these outdated non-standard components, patterns and pages.
45	Yes	The tokens we work with sit a the very primitive level, so there was never sufficient thought required at the time. Now we are looking at reworking those and include aliases and component specific as well	The fear of "breaking-freaking-changes" mindset
46	Yes	We don’t have consistency currently in the codebase. Ideally following system-category-variant-scale to name tokens for core values. Maybe adding role modifier in there as well. Then having semantic tokens in some form of element-modifier	Mainly having verbose enough values while also keeping names simple enough in order to reference appropriately.
47	Yes	The primitives were done by an outside agency to get the design system rolling. I'm currently working on the semantic/intents naming, open to ideas on the 'best' direction.	how it will scale and adoption.
48	Yes	I'll use the term "token" loosely here. We are leveraging Figma Variables for the time being. We chose to start very basic and very small when it came to our token structure. In some respect, Figma having a somewhat limited product offering when it comes to Variables helps. We are limited to what we can currently do. I had originally created our Foundations via Tokens Studio, but the team found it to be too confusing. When it came to naming we reviewed many other strategies used by other design systems. We listed those examples, then voted on what we think works best for us as a team.	The limitations of what you can do with Figma Variables is already becoming an issue. We are building new products. We want to make sure there is separation in segmentation in our token architecture. We may already need to migrate and rearchitect our structure to make it more modular. In short, the challenge is making sure you are thinking of the future and making things scalable. Trying to forsee the obstacles ahead and design your tokens for them, before they occur.
49	Yes	The naming is primary, secondary, complementary, onsurface, background, analogous, on_text, state	My design system currently includes primitive tokens. However, my main goal is to develop semantic tokens, which will allow me to create variables in Figma. This will enable the creation of two libraries: one with accessible components and another without accessibility.
50	Yes	Managed by the design system team. Designers test names with internal users. Keep it as simple and as few tokens as possible.	Managing tech debt - hard to make changes to existing architecture across many teams. & designers ignoring semantic naming/not reading the guidance.
51	No	I would leverage existing design tokens from other organizations, while also ensuring they align with what my engineers are comfortable working with.	Managing them effectively, especially during token updates, to ensure smooth integration and minimal disruption.
52	Yes	Followed CTI naming and what worked with style dictionary	Too verbose
53	Yes	I watched a handful of design presentations from Figma schema that talked about design tokens and used those as inspiration for our own structure	Once it's set up, it seems very challenging to change the structure. Also it seems like sticking to a rigid naming convention sometimes results in more complexity
54	Yes	Current architecture: Global tokens - base layer - all the bits and bobs we need. - Type_Category_Item Semantic tokens - mid layer - Type_Category_Item_Modifier Component tokens - last layer for implementation - Component_Variant_Item_Type Modes and themes to modify the token values on top of everything And the mapping between the three layers using aliases ofcourse. -Arko	Bloat. Huge amounts of bloat. We're dealing with a scenario where designers designing pages would like to use tokens but they get lost and confused in the forest of options. We want to shift to more dynamic, dimensional tokens where the context and mode shifts a small number of tokens that designers don't get confused about. -Arko
55	Yes	Still trying to figure that out!!!	Everyone being on the same page
56	Yes	We divided them into: reference tokens - the raw values that don't carry semantic meaning (i.e. sky-blue-100) system tokens - semantic values (i.e. light-color-primary) component tokens - mapped to specific components (i.e. button-primary)	sometimes developers use reference tokens when they should be using the semantic ones. this happens because they'll inspect the CSS values of the figma file or look in the dev tools of a component that looks like it has the styling that they want, and grab those raw values instead of using the correct token.
57	Not applicable to me	I think naming conventions need to be looked at from a holistic view. First we need to understand the scope of the system, the future hopes for the system, and what the system is supporting. It's beneficial to follow common practices for easy of use and onboarding future team members, but I also think each system may have different and unique needs. It's important to ensure the entire design system team and subscribers understand the terminology that is decided on.	n/a
58	Yes	A mixture of a pattern of what we saw throughout the industry and bem.	it's manually done...
59	Yes	The naming structure for design tokens follows: - Category: Top level that contains foundational elements such as text, color, spacing - Sub-Category: Describes and narrows category for token. For instance, color-text will define a color for text and can be used for icons - Item: Continues to narrows usage for token. For example, if text is a property, the item could be form to indicate text used in a form control - Sub-Item: Describes and narrows category for token. For instance, form could be modified by input - Variant: Describes prominence or state for a token - Size: Describes size for a token, if applicable There's also a table view here: https://cedar.rei.com/tokens#naming-structure. Quite a bit of thought went into this structure when we initially set them up - that was a few years back so I don't recall all the detail, but it seems to be holding up well!	We are currently adding in theming and palettes, so we're adding in a new layer of tokens to specify which tokens to use for specific color palettes. We are also renaming some composite token names to align with the new Wc3 recommendations and compatibility with v4 of Style Dictionary.
60	Yes	Trial and error, past experience, Nathan Curtis' articles.	Pipeline, distribution, Design Tokens Format Module compatibility.
61	Yes	Unfortunately, nobody cares much about the architecture or naming. We just have a few tokens, and they're named somehow to make some sense.	There are no plans to do anything as far as I know.
62	Yes	The initial setup was determined by the designers in Figma and then exported through a plugin / Style Dictionary to the code. Since, the developers have deviated, naming conventions have changed, and although they exist and are still used, there is a bit of chaos surrounding the tokens as a whole as we upgrade to variables / v2 of the system.	Although general alignment of my design and development teams have been good - getting them to align on naming or perception of "what the thing is" has been a challenge. Also recently we have been introduced to another team with their own version of a system and their own tokens so there will need to be much conversation between all of us to determine the best path forward.
63	Yes	At present, everything is labeled with the component it corresponds to, the aspect of the component the token affects, they style of component, and the state of the component (if necessary).	The complexity of it all. I travel down a path hoping things make sense at the end and often I feel like I end up over thinking the process.
64	No	We are in process of defining our token architecture. At the moment we only have color token architecture completed.	The naming of the second tier is the one that proves tricky. Also, we are even considering a fourth tier but that might be an overkill? we haven't seen many examples out there of 4 tiers...
65	Yes	We created a taxonomy based on a combination of the great research of Nathan (https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676), and the existing names of tokens from the pre-v1 of the current design system.	The biggest hurdle currently is syncing across tools and the limitations of Figma Variables. Figma Variables are not currently mature enough to use as a starting point, however we have designers that want to use them exclusively. We're looking at a combination of exporting tokens from Tokens Studio to Figma Variables for designers, while on the code side pushing from Tokens Studio to our source control, and then to Zeroheight to take advantage of Zeroheight's Style Dictionary under-the-hood implementation to make tokens available in multiple formats for engineers.
66	Yes	We have a low level set of tokens as mainstream tokens or primitives, a handful of system tokens and component tokens.	I believe tokens can become a burden for designers when the structure is to complex, that makes it difficult to understand. Nevertheless I've found that my team mostly uses spacing and color the most. We have components for headings and text holding styles.
67	Yes	We structure design tokens with a taxonomy called CTI+, based on the CTI structure offered by Style Dictionary but expanded.	I see some tokens defined without sufficient dynamics to account for all use cases
68	Yes	Identifying the layers of theming that is needed for the architecture was very important. Making sure names are short and descriptive (re visual communication / language)	Designers not being on the same page about when a new token / visual language is needed or when we should stay with the current options.
69	Yes	We split color tokens into two distinctions: decision tokens and option tokens. Decision tokens are named based on use case. We have favorable, critical and primary text colors in various levels of high/low emphasis and hover/press states. The semantic naming tells the designer where to use the color. The background/interactive/emphasis-high token is for a button background or other high emphasis interactive element. Option tokens leave the door open for flexibility. The options tokens are called blue-50 or red-100 so that the designer could pick the color they wanted without filtering their thought process through use case. We prefer designers to start with decision tokens and only use options tokens where they don't have a decision token that makes sense.	Over time, our distinction between decision and option tokens has become exhausting to explain. Same or similar colors are available as both decision and options tokens. The challenge continues to be emphasizing the use of decision tokens almost exclusively. To that end, we've updated or replaced some names like base-0 to page-background. Base-0 made sense for the lightest background use cases and allowed for base-1, base-2, etc. for the darker backgrounds. Most page backgrounds were base-1, a slight gray. Page-background is more restrictive and makes every background full white, but also more clarifying and unifying. The decision also makes it easier to define dark mode values that won't ruin contrast ratios.
70	Yes	I prefer to keep naming simple for the sake of the developers using the system. For example, so anyone could apply the correct spacing value based on the design, tokens were structured with "$spacing--" followed by the number equal to the value. So, if the developer needed to add a margin of 16px, the developer would type "margin: $spacing--16." This proved to be very helpful for our Eng team since many complained about the previous structure being too abstract, which led to many visual issues because the tokens were too esoteric.	We haven't seen any issues as of yet. Taking a simpler, cleaner, more generic approach to naming has helped with adoption.
71	Yes	We're currently defining them. Our fledgling DS team spent a while reviewing comparatives, compiling an inventory of the components in use across products, and building some core components to better understand the problems we were trying to solve with our tokens. Out of that, we developed a set of "sensible suggestions" for both our primitive and semantic tokens, aware that they didn't solve every problem and aware that we weren't even privy to every problem. (We opted not to use component tokens.) We made good progress coming up with primitive and semantic tokens for typography and sizing, but we're struggling most with semantically meaningful color tokens. Here's the pattern we're recommending so far: Pattern `color-[context]-[theme/intent]-[interaction]-[intensity]` Where: -- context = application or usage, e.g. bg, borders, text -- theme = brand-related colors, e.g. base primary, secondary, accent -- intent = intent-related colors, e.g. warning, info, success, danger, emergency (not changing from brand to brand) -- interaction = interactive states, e.g. disabled, hover, press -- intensity = modifier for differences in visual weight, e.g. bold, light, weak But this is still a work in progress.	In order to achieve consensus between stakeholder teams (branding, UX, web developer, application development), we ran a series of workshops with our central UX team to define naming conventions and assigned options for our typography and color tokens. We ran into several challenges. First, the goal of the workshops was to standardize our token naming, but it became quickly apparent that we needed to start first by making a case for tokens and explaining their value. We had gotten sign-off for these workshops from leadership at a high-level, but it's almost like we needed a preliminary meeting with everyone to explain the technical details to better frame the conversation. In other words, it was difficult for folks who didn't fully understand the value of tokens to make decisions about their architecture. Second, a discussion about tokens can get really abstract. I struggled to find consensus because of how disconnected it was from the actual product design. We really needed a set of components to help ground the conversation, but we worried that would devolve into a battle over design decisions, especially since we were trying to drive some consensus from such a broad set of teams. Third, there is a significant divide between the design needs of our digital web applications and the more content-heavy web sites, so finding semantically meaning names for a wide range of applications is challenging. We're looking to build consensus, but we're also feeling more like we need to start by building out a thoughtful system of tokens and then approach teams and say, "what are we missing?"
72	Yes	Using dot notation, we move from the most constant to the most variable. System, context, and theme as examples of constants with element, property, state, and emphasis bringing more variability. For example, ds.dark.button.bg.primary.hover	We purposely aimed to keep technology and implementation choices out of the token structure as much as possible. Some items like “link” must be included, mindfully breaking our rule. This gives the token system more resilience and also promotes the use of “token utilities” in our applications allowing teams more stability in their use and making platform decisions when they’re appropriate.
73	No	We don't have tokens in Figma, nor in our CSS layer! Figma currently uses styles, not variables. CSS uses a few Sass variables, and no custom properties. Naming is very inconsistent. I'm pushing for a "pause" so we can re-align design & front-end code, before we roll out another theme. Thankfully, our Figma and coded components do adhere mainly to atomic design principles, so they're named appropriately. I would need to get everyone in the team consuming articles like https://www.smashingmagazine.com/2022/12/anatomy-themed-design-system-components/ and https://www.smashingmagazine.com/2024/05/naming-best-practices/ to help them understand the benefits.	Pushback from client saying we don't have time to refactor!
74	Yes	First, we identified a series of buckets that tokens fall under, then established an order that translated to a naming convention. e.g. GROUP-COMPONENT-VARIANT-ELEMENT-STATE	Bloat. So much bloat. Hoping we can resolve this with tooling in a Post-CSS-esque step.
75	Yes	I joined after the architecture was set up, but right now we have an opportunity to revisit our patterns. I don't have a great handle on conventions and trends yet, but would see what I can learn from thought leaders and existing design systems (including our own).	Understanding how to make the best use of our tokens alongside Tailwind. Staying in sync with Design and Design tooling.
76	Yes	I think we probably referenced Nathan Curtis' documentation originally and created categories like color, breakpoints, typography, spacing, etc. At some point we tried out component-specific tokens but backed off of that pretty quickly.	We've already had to deprecate a bunch because we created duplicates by accident with slightly different names. I think nowadays we lean towards more "base" tokens (e.g., color-palette-teal80) than descriptive/decision tokens (e.g., color-header-background) because we've found that there are so many different contexts we're serving the descriptive/decision ones dont hold up.
77	Yes	The first iteration was a very KISS approach, but we hired a dedicated designer before our initial release and after reading a lot of articles on the subject, settled on a two tier structure with Global and Alias tokens.	I’m not sure it will be clear for consumers why there are two layers, or which layer to look for the token they need. I’m not sure how much product devs will use the tokens directly, or how much they even need to, but if they do adopt heavily then making breaking changes to the architecture is going to be very disruptive.
78	I don't know	Don't know enough to say	-Understanding tokens -Time
79	Yes	Not sure on my current system as it hasn’t been rolled out yet and I am new. But the way we did tokens before was to relate them directly to the product taxonomy map and CMS so that they translated across teams.	I personally think this architecture should stay simple and universal so that it can stay consistent while the product may change over time. But then everything changes.
80	Yes	Myself and one of our designers come up with the architecture of the tokens. We developed them using existing Figma styles along with SCSS variables we had in code. Currently, we only use our tokens internally in the DS but this is one area of the DS that we would like to improve. We would love to be able to expose these tokens as a micro-adoption tool for consumers that might not be able to use the component library.	We built out our tokens about 18 months ago without having a clear strategy in place. This has lead to a lot of bloat within our token library. Our naming convention could also be improved to make it easier to find the correct token.
81	Yes	A lot research, examining other's systems, reading the proposed spec and based a bit on tooling examples.	We started smaller with a mvp. So we didnt build in different levels/layers of tokens. I'm hoping we can expand into those as we grow.
82	Yes	I would determine the architecture and naming conventions by collaborating with the entire team who is building the design system as well as performing some end-user research.	Conventions would need to be adopted across the board and should be easy to understand.
83	Yes	We work between content strategy, design, and engineering to establish naming and architecture conventions.	Consistency and scaling by adding complexity and people to the process.
84	Yes	We use MUI, and thus MUI's theme structure. It's straightforward, if not particularly semantic. We don't have a separate semantic vs functional layer, they just sort of have both for colors, e.g. palette primary, palette warning/success/error. It's editable but we haven't really found the need to add much custom other than some brand colors. IMO most token architectures are overly complex for very little value. Good tokens that actually provide full restyling is Hard Mode and I don't know of many/any co's that are actually doing it well.	The biggest issue right now is dark/light mode; in the current MUI you have to build a separate theme, which I refuse to do. We don't really need/care about dark mode rn (or even use any inverted components), but switching to the MUI Joy CSS Vars token setup would allow you to just switch/invert colors based on a mode, which is a far smarter setup.
85	Yes	We started with primitive tokens (action-primary-60, accent-secondary-60), then added a semantic abstracted layer (border-color-action, gradient-accent-stop-1), and added a component-specific layer (that we feel bad adding to) when necessary (button-surface-hover, button-surface-active). We created a shared language (default for system or browser defaults vs primary to imply hierarchy, surface for backgrounds vs color for foregrounds) and BEM-inspired naming convention (component-element-modifier).	Design needed less context in their token names than development did. Adding the context needed for development created names that were repetitive, long, and cluttered in Figma. We ended up using the Figma API and Style Dictionary to solve for this, but the extra step isn't ideal. We also ran into some contrast issues when retrofitting existing brands into our color scales and themed tokens.
86	Yes	Balance between Design and Eng, found naming conventions from other open Design Systems that we enjoyed	Breaking changes to token names. Challenges with pushing changes, when Figma is the source of truth. Names are kind of long in Figma, or in the browser DevTools
87	Yes	Our tokens start with a primitives approach then they are applied to each system (we have 3) via their intended use case.	Biggest issues we have is keeping things consistent across the individual systems we manage. Also implementing alternate dark mode tokens.
88
89
90
91
92
93
94
95
96
97
98
99
100