Design Systems 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

🧠 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

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?

Don't need to comment, like, or connect. Download it. Read it. Use it. Learn with it. Over the last weeks I kept seeing the same pattern. Designers were curious about MCP, but stuck. The path was unclear. Setup felt intimidating. Real use cases were missing. So I built the Design MCP Adoption Toolkit. A practical guide for using MCP inside a real Figma workflow. No theory. No hype. Just execution. Inside you will find: → What MCP is in plain language. → The three MCPs that matter for design work. → The mental model for Anthropic Claude Code to Figma, OpenAI Codex to Figma, and Figma Console MCP by Southleft, LLC and TJ Pitre. → The full setup in nine clear steps. → Nine real workflows you can test this week: Accessibility audits. Ticket validation before handoff. Token migration. Multi platform component handoff. Component documentation generation and more. Our roles are evolving. We are moving closer to that old Webmaster model where design, systems, structure, and technology connect. The designer who understands systems and automation will have leverage. This toolkit is my contribution to that transition. Consume it. Test it. Break things. Ask questions. Explore your own use cases. These are exciting times, and we move faster when we learn together. If you build something interesting with it, share it. Concrete examples help the whole community level up.

One of the simplest yet more underrated changes you can make as a brand to be more instantly credible is... *drum roll* 🥁 Yes, boring old consistency 🤯 Imagine... marketing says one thing. Sales says another. The website is still saying something from 2021 (yes, people notice). To me, this is the number one killer of brand trust: inconsistency. When you're already fighting for awareness and relevance, any break in your consistency across channels confuses your audience. And a confused audience rarely buys. So, how do you ensure you show up with the same story across every channel? Here's my framework for implementing more brand consistency: Phase 1: run a channel audit. This is where we map every touchpoint. → External: Website, email, social handles, review sites (Glassdoor/TrustPilot). → Internal: Intranet, newsletters, onboarding decks, trainings, etc. Test: Read them side-by-side. Do they sound like they come from the same company? If you are preaching "world-class service" on LinkedIn, but your TrustPilot reviews are being ignored, you have a credibility gap. Phase 2: prioritize, prioritize, prioritize. You do not need to be everywhere. You need to be tactical... Seriously, if a channel is a ghost town or off-brand, archive it. Focus resources only on channels where you can maintain a sharp, subjective POV. You don't need a strategy for TikTok, Reddit, and Bluesky. You need a strategy for where your audience actually makes decisions or wants to learn about you. Phase 3: Create an internal playbook (my personal favorite). Consistency breaks when internal teams aren't aligned. If marketing builds the brand, but sales uses a deck that contradicts it, the trust is broken. My recommendation: create an unbreakable "Source of Truth" resource (could be a document, a webpage, an FAQ) accessible to everyone in the org. What goes in this "source of truth": → Codify the identity: "We are X, we are never Y." Don't leave room for interpretation. Map out the visuals (fonts, colors, imagery) alongside the voice (tone, language, personality). Pro tip: Create a "Do vs. Don't" list (e.g., "We say 'clients', never 'users'") so teams can self-edit. → Define the narrative, the one story everyone tells. Make a global version and allow for local nuance, but never change the core plot. → Update the resource quarterly or when necessary and communicate internally (use newsletters, the intranet, brand champions, Slack/Teams, etc). I am thoroughly convinced that consistency and clarity are the strongest forms of leadership. What channels are you prioritizing now?

What if AI coding tools could speak the same language as your design system? That’s what Waqar Ali and the team at Typeform set out to explore. In their latest post, they shared how they built a Design System MCP server to bridge the gap between Figma and code, making their Echo Design System machine-consumable by tools like Claude Code, Cursor, and Cline. Here’s what stood out to me: • They used their Storybook docs as the foundation for an intelligent system interface • The MCP server helps AI tools identify component boundaries, usage, and context • It's not about generating code from scratch — it’s about giving AI the right constraints • They’re aligning design tokens, props, and behaviors to work across humans and LLMs • And they’re doing it all while keeping their system stable, documented, and scalable. But it also raises some deeper questions: 🔹 Is your current documentation format AI-friendly by design? 🔹 How far can we push the idea of “design-to-code” when LLMs get involved? 🔹 What kind of governance or structure will this require from design systems teams? You can read the full story here: https://lnkd.in/dEtMAhwC Kudos to Waqar Ali for driving this and breaking it down so clearly. Is anyone else exploring something similar with AI and design systems? Drop your thoughts or experiments below 👇 This is a space that’s evolving fast, and we can all learn from each other. #AI #DesignSystems #designsystem #DesignToCode #LLM #Figma #Storybook #Typeform #DesignOps #UXEngineering #uxdesign #uidesign #uxui #uiux

In a hybrid team, "I didn't get that message" is often a symptom of a fragmented communication strategy, not a forgetful employee. 📝 When your team is split between the office and the spare bedroom, you can’t rely on "watercooler chat" to keep everyone aligned. If information is shared inconsistently across different channels, you create a "knowledge hierarchy" where those in the office feel more informed than those at home. To keep your hybrid team on the same page: - Digital-first mindset: Treat every update as if the whole team is remote. If a decision is made in a hallway, it must be documented in a central digital space immediately. - The "Live Blog" approach: For major projects or crises, use a running blog on your intranet as the definitive source. Point all other channels—emails, Slack, or Yammer—back to this one link to ensure everyone sees the latest, verified facts. - Consistent touchpoints: Use regular, short updates to stay top of mind, rather than waiting for big "all-hands" meetings that might not suit everyone's schedule. When everyone has access to the same information at the same time, you remove the "us vs. them" divide and build a more equitable culture. How do you ensure your remote team members don't feel like they're missing out on the "in-office" loop? 🤝 [Image description: Green tile with black headline text that reads: Is your hybrid team getting the same messages at the same time? Below is a meme featuring a black-and-white cartoon of a business woman holding her glasses in one hand with the caption: 'Thank you for "reminding" me about that thing you never told me about in the first place.']

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

💡Design System Canvas Design System Canvas is a strategic tool created by Paavan Buddhdev that helps teams outline design system properties during its planning and gather buy-in from stakeholders. It breaks information about the design system into 10 sections, prompting questions to ensure the design system is well-thought-out. 1️⃣ Problem Identify challenges faced in designing new products and services. This helps clarify why a design system is necessary. Example of a problem: inconsistent visual design of a product. 2️⃣ Existing assets Conduct an audit of all design-related assets: style guides, components, documentation, etc. List the current UI elements—styles, components, and visual assets—that can be integrated into the design system. 3️⃣ Maturity level Assess the current level of your design system on a scale from 0 to 4, where: ✔ 0: No reusable assets. ✔ 1: Basic foundations like color and typography. ✔ 2: Reusable components but not integrated into workflows. ✔ 3: Most components are linked to documentation and workflows. ✔ 4: Fully integrated, with dedicated maintenance and usage across teams. Honestly assess where your design system stands. This helps prioritize what’s needed next. 4️⃣ New resources Specify new assets and processes needed to advance the design system’s maturity: ✔ 4A. Assets: Components or resources required. Prioritize assets based on their impact and usage frequency (e.g., buttons, input fields, icons). ✔ 4B. Processes: Workflow adjustments or guidelines to support the system. Define clear design and development workflows, like component approval or update processes. 5️⃣ Affected products List the products or services that will benefit from implementing the design system. Consider the impact of your design system on new versus existing products. 6️⃣ Consumers Identify the end-users of the design system, such as internal teams or external developers. Engage with these consumers early to gather feedback and buy-in. 7️⃣ Maintainers & champions ✔ 7A. Maintainers: The people or teams responsible for maintaining the design system. Assign a team to oversee updates and improvements. ✔ 7B. Champions: Individuals who advocate for and support the design system’s adoption. Identify influential team members who can advocate for the system. 8️⃣ Scope Define the extent of the changes. What parts of the system can realistically be changed or developed? Be realistic about what can be achieved in phases. Prioritize components or guidelines that will have the most impact. 9️⃣ Adoption strategy Outline how to encourage teams to adopt the design system and who will lead this effort. Use success stories and metrics to demonstrate the impact of the design system and encourage wider adoption. 🔟 Costs Consider the financial and resource investments needed, including time, team capacity, and tools. Break down costs into categories: team time, tools, and training. #design #designsystem #productdesign #uxdesign