Design Token Implementation

I have spent hundreds of hours analyzing design systems. One of the things that confused me for many years is how to structure color scales and tokens. I have experimented with multiple structures at different sizes of design systems, and at a high-level recommend the following approach: 1. Primitive Colors Your design system foundations should always start with a full color scale that is based on your brand identity. We call these colors Primitives, and your variable/token collection should look like this: - purple-600 - purple-500 - purple-400 - And so on.. To create a Primitives palette you will want to start from your main brand colors and use a tool like UIColors, Supapalette, Colorbox to expand to the full scale. (links in comments) This is a great foundation to have, as it gives you a set of shades that can be used in different ways, and ensures all of them have consistent hues, saturation and brightness. However, Primitive colors are simply not effective when used directly in your designs: - They create ambiguity - Their names have no contextual meaning - They are often misused due to similarity If you have had the “why are there 20 different shades of gray?” conversation with an engineer, you know what I mean. So let’s see how we can improve that. 2. Semantic Colors This is my default recommendation to all product design teams that don’t have a highly complex design system. What you will want to do here is create a new variable collection named Semantic, which is what’s visible in your design files, and comprises of: - Brand / Action - Text - Link - Border - Icon - Surface / Background - Bias - Data / Charts Each color should point to a primitive value, e.g. - text-primary → gray-800 - text-secondary → gray-600 - text-tertiary → gray-400 This takes a bit of setting up, but creates immense long-term value. A great example of a simple, theme-level Semantic structure is Shopify’s Polaris (link in comments) 3. Component-level Semantic Lastly, if you are working on a design system with a lot of complexity and, ideally, a dedicated design systems team, you might want to add another level of hierarchy and specify colors at a component-level. In this structure, you would want to create color tokens based on how they are used in each component. - input-text-filled → text-primary - input-text-placeholder → text-secondary - input-text-disabled → text-tertiary This eliminates all guesswork, but also increases the complexity exponentially. It does serve a purpose though. As design systems scale, you may find that: - A theme-level semantic structure is too restrictive - There is still some guesswork - Decisions need to be documented. An example of this is Uber’s Base and Adobe’s Spectrum design system, linked in the comments. I’m curious to know, what structure are you using for your design system and what has worked well for you? — If you found this useful, consider reposting ♻️ #uidesign #designsystems #productdesign

In Figma, we use variables. But are they the same as tokens? And what is that JSON file developers keep talking about? Let’s understand this for a better workflow: 1. Variables in Figma Variables let you define values like colours, spacing etc. --> Example (Figma): color/danger = #FF0000 This keeps designs consistent inside Figma. 2. So what is a token? A design token is a simple name + value pair that describes a design decision in a format code can use. --> Example (JSON): "moon-color-text-danger": "#FF0000" 3. Isn’t that the same? Not quite. Tokens are intentionally simpler. Each token represents one decision: one value only. • A colour token maps a single hex value • A spacing token maps a single pixel value • A radius token maps a single corner value This simplicity is what makes tokens portable across platforms. They don’t carry Figma-specific logic like modes or variable aliasing. 4. The JSON file This is the container for tokens. Think of it as the dictionary of all design decisions in your system. Inside it, every decision is expressed in a consistent, structured format. Why it matters: • JSON is machine-readable • JSON is tool-agnostic • SON becomes the single source of truth for both designers and developers 5. What works well today in Figma • Variables can be grouped, aliased, and scaled across files • They can be applied to styles and components • With plugins such as Token Studio, variables can be exported into JSON 6. Where it falls short • Figma does not yet export a “true” token file natively • JSON export requires plugins or manual workflows • Bi-directional sync (design ↔ code) is still early • Naming conventions are not enforced, which risks drift between design and dev 7. How it connects Here’s the flow today: • Designers create variables in Figma (design intent) • These variables are exported (manually or via plugin) into JSON (structured tokens) • Developers translate that JSON into platform code (iOS, CSS, Android, etc.) When the JSON updates, every platform can stay in sync 👉 The takeaway Figma variables are a flexible design tool. Tokens are the code-friendly format. JSON is where those tokens live as the single source of truth. The pieces are coming together, but we are not yet at a perfect one-click sync between design and code. How is your team handling this today? Are you exporting variables into tokens, or still managing JSON separately with developers? Any handy tools I might have missed?

For the longest time, every new project meant starting from scratch. New colors. New typography. New spacing. New everything. And honestly, it took a lot of time that could’ve been better spent designing for users. So I decided to create a 𝐦𝐚𝐬𝐭𝐞𝐫 𝐅𝐢𝐠𝐦𝐚 𝐟𝐢𝐥𝐞, one that works like my personal design foundation. Here’s what I set up:  🎨 𝐂𝐨𝐥𝐨𝐫 𝐭𝐨𝐤𝐞𝐧𝐬 - primary, secondary, tertiary, semantic colors, and a detailed gray palette.  🔡 𝐓𝐲𝐩𝐨𝐠𝐫𝐚𝐩𝐡𝐲 𝐭𝐨𝐤𝐞𝐧𝐬 - scalable system with clear hierarchy.  📏 𝐏𝐫𝐢𝐦𝐢𝐭𝐢𝐯𝐞𝐬 - border widths, spacing, radii, number scales.  📑 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 - all neatly organized in one place. Now, every time I start a new project, I simply duplicate this file, and in just a few clicks, I update the tokens using variables, and everything across the file reflects instantly. Easy peasy. It sounds simple, but it’s been a game-changer: 𝐍𝐨 𝐦𝐨𝐫𝐞 𝐢𝐧𝐜𝐨𝐧𝐬𝐢𝐬𝐭𝐞𝐧𝐭 𝐬𝐭𝐲𝐥𝐞𝐬 creeping in. 𝐍𝐨 𝐦𝐨𝐫𝐞 𝐰𝐚𝐬𝐭𝐞𝐝 𝐡𝐨𝐮𝐫𝐬 redefining basics. And handing over to developers? So much smoother. If you’re someone who juggles multiple projects back-to-back, setting up a reusable token-based system in Figma might just save you a lot of time (and sanity). #uxdesign #variables #tokens #typography #colorstyles #freelance

So many teams treat design tokens like variables: colors, font sizes, spacing... But the truth is that design tokens are more like genes on a strand of DNA. The real magic is how/when they replicate, mutate, and scale. Get tokens right, and every component inherits the right traits. Get them wrong, and chaos spreads through your product, quietly but relentlessly. Having rolled out tokenized design systems for a handful of brands at this point, here's what I've found matters the most: → Tokens aren't about speed—they're about resilience → They create predictable inheritance (and minimize the risk of change). → They force systematic thinking—beyond how something looks. → They bridge the gap between design intent and the code reality. Strong tokens = cohesive products at every touchpoint. Weak tokens = Frankenstein systems no one wants to maintain. In truth, most design system failures aren't due to bad components. They're about bad foundational decisions. Call your color "blue-500" instead of "primary-action"? You're building technical debt into every component. Skip a mathematical spacing scale? Every layout becomes a one-off. Ignore typographic hierarchy? Your content slips into chaos. But build tokens with intention—semantic names, math-based scales, clear inheritance—and your system starts to build itself. → New components that immediately feel on-brand → Design handoffs become about logic (vs. pixel-policing) → Updates keep consistency, even as you scale → Expansion to new platforms doesn't mean starting over The real win: Tokens force better decisions. Naming colors semantically makes you ask "what's this really for?" Math-based spacing creates rhythmic layouts. Encoded typography hierarchy makes content clearer. When your foundational decisions are sound, everything built on top inherits that quality. When they're weak, that fragility compounds. How are you managing your tokens? Where's your system fragile—or resilient? #designsystems #uxdesign #designtokens ——— 👋 Hi, I’m Dane—your source for UX and career tips. ❤️ Found this helpful? Dropping a like would be 🔥. 🔄 Share to help others (or for easy access later). ➕ Follow for more like this delivered to your feed every day.

🧠 Practical Guides To Naming Design Tokens and Components (+ Figma Kits) (https://lnkd.in/eYi-GQwp). Practical naming guidelines for complex multi-brand, multi-themed design systems — with a well-orchestrated system of collections, from brand and primitives to semantics and pages. Kindly shared by Alexandra Dyulgerova, Robyn Layton, M Smith from Vodafone UK. 🎨 The Brand Collection includes all core brand attributes such as colors and fonts, but there is no digital or component context at this level. These variables aren’t used on the level of the component and aren’t linked to other collections. Brand designers may edit them if needed. E.g. color-vodafone-red, color-turquoise. 🔘 The Brand Primitives Collection stores raw digital values such as spacing, radius, aspect-ratio, digital color palette, motion and elevation. All values have no component context at this level. E.g. surface-color-default, motion-axis-zoom-300. 🗂️ The Semantics Collection takes raw digital values from Primitives and gives them a component-specific context. This is where different brands are mapped against each other using modes. E.g. surface-background-primary-inverse-vodafoneUK-100. 🖼️ Finally, the Page Collection defines how components behave across viewports and controls breakpoint-dependant booleans. These variables are used directly on the components and design frames, hence read-only. E.g. component-size-navigation-button-XL. I love that by looking at the names alone, one can gather quite a lot of insight about where a token is used and what it represents. A fantastic scalable taxonomy system that’s building on top of years-long work by Nathan Curtis and ensures that changes don’t break existing patterns. 👏🏼 👏🏽 👏🏾 💠 Naming Guidelines in Design Systems Nordhealth: https://lnkd.in/eQVpbsrv Goldman Sachs: https://lnkd.in/dxGzb5AR NewsKit: https://lnkd.in/eucYnEhY Atlassian: https://lnkd.in/eBNjTR7d Pinterest: https://lnkd.in/eg9aRrni 🧲 Useful Figma Kits and Resources Naming Tokens In Design Systems, by Nathan Curtis https://lnkd.in/eFENY7tS Flexible Design Token Taxonomy, by Nate Baldwin https://lnkd.in/ehk8MCsr A Practical Guide To Naming Components (Figma Kit), by Luis Ouriach https://lnkd.in/eqAfDYg4 Naming Tokens In Design Systems (Figma Kit), by Marta Conde https://lnkd.in/e4Cijc_F Design Token Names Inventory Spreadsheet, by Romina Kavcic https://lnkd.in/eqQdw2jA Good Design Practices For Naming (+ Checklist), by Javier Cuello https://lnkd.in/es4T6-cB .classnames: How To Name Things (Word Lists), by Paul Lloyd https://lnkd.in/ddWfAUwS Multi-Brand Design System Figma Kit, by Pavel Kiselev https://lnkd.in/eShgnPnW #ux #design