Tag: design tokens

  • How to Build a Design System From Scratch in 2026 Using Figma and Tokens Studio

    How to Build a Design System From Scratch in 2026 Using Figma and Tokens Studio

    Design systems have gone from being the exclusive obsession of large product teams at Monzo or the BBC to something every serious designer and developer needs to understand. And honestly? The barrier to entry has never been lower. If you want to build a design system in Figma 2026 that actually scales, that your devs will love, and that won’t collapse into chaos six months later, this guide is for you. We’re going step by step, and we’re bringing Tokens Studio along for the ride, because design tokens are where the real power lives.

    Designer working on a build design system Figma 2026 project at a modern London studio workstation
    Designer working on a build design system Figma 2026 project at a modern London studio workstation

    Why Design Tokens Are the Foundation You Can’t Skip

    Before you touch a single component, you need to sort your tokens. Think of tokens as variables for your design decisions. Colour values, spacing increments, font sizes, border radii, shadow depths — all of it lives in tokens rather than being hard-coded into individual components. The moment you hardcode #1A1A2E directly into 47 components, you’ve built a maintenance nightmare, not a system.

    Tokens Studio (the Figma plugin) lets you define, organise, and sync tokens in a JSON format that your developers can consume directly. It also integrates with Style Dictionary, which transforms those tokens into platform-specific outputs: CSS custom properties for the web, Swift constants for iOS, XML for Android. That’s the handoff pipeline sorted before a single component is drawn.

    Naming Your Tokens Properly

    Naming is where most teams go wrong. There are broadly three tiers of tokens, and understanding them saves enormous grief later.

    • Primitive (global) tokens: Raw values. color.blue.500 = #3B82F6. These are the periodic table of your system. Never reference them directly in components.
    • Semantic (alias) tokens: Meaningful assignments. color.action.primary = {color.blue.500}. This is what your components actually reference.
    • Component tokens: Scoped to a specific component. button.background.default = {color.action.primary}. Optional but powerful for complex components.

    The reason for this three-tier structure? When your brand pivots from blue to teal (and it will happen, trust me), you update one primitive token and the entire system propagates the change. Magic, but actually just good architecture.

    Setting Up Tokens Studio in Figma

    Install Tokens Studio from the Figma Community. Once it’s running, you’ll see a panel where you can create token sets. Start with a global set for your primitives and a semantic set that references them. In Tokens Studio, you reference another token using curly brace syntax: {color.blue.500}.

    For teams working collaboratively, connect Tokens Studio to a GitHub repository. Your token JSON lives in source control alongside your code. Designers push token changes via the plugin; developers pull them and run Style Dictionary to generate updated CSS variables. The design-to-code gap narrows dramatically. According to the UK Government Design Principles, consistency and clarity are foundational to good service design, and a token-based system is precisely how you enforce both at scale.

    Close-up of Figma and Tokens Studio JSON panel used to build design system in Figma 2026
    Close-up of Figma and Tokens Studio JSON panel used to build design system in Figma 2026

    Component Architecture: Building for Scale

    Now the fun part. Components in Figma should follow an Atomic Design hierarchy, even if you don’t call it that out loud in your team documentation.

    Atoms First

    Build your smallest, indivisible elements first. Buttons, input fields, checkboxes, radio buttons, badges, icons. Each atom should use semantic tokens exclusively, never raw values. Use Figma’s component properties to handle variants: state (default, hover, active, disabled), size (small, medium, large), and hierarchy (primary, secondary, ghost).

    Keep each atom in a dedicated page or dedicated section within a page. Organise your layers obsessively. Naming matters here: use the Group/Component Name slash convention so Figma’s asset panel presents them cleanly. Button/Primary/Default reads like a file path, which is exactly what it is.

    Molecules and Organisms

    Molecules combine atoms into slightly more complex chunks. A form field is a molecule: it combines a label atom, an input atom, and a helper text atom. An organism is a full section: a navigation bar, a hero block, a card grid. Each layer of composition should reference its children as nested component instances, not as detached copies. Detaching components is the design system equivalent of deleting a git history.

    Using Figma Variables Alongside Tokens Studio

    Figma’s native Variables (introduced in 2023 and considerably more mature now in 2026) and Tokens Studio overlap in interesting ways. Figma Variables are great for live mode switching — light and dark themes, for instance — because they’re native to the runtime. Tokens Studio is better for complex multi-brand setups and for the developer export pipeline. In practice, many teams use both: Variables for the Figma-side interactive prototyping experience, Tokens Studio for the actual production handoff. It’s not either/or; it’s knowing which tool solves which problem.

    Developer Handoff That Doesn’t Make Developers Want to Quit

    When you build a design system in Figma 2026, the handoff process is where the theory meets reality. A few non-negotiable practices:

    • Token JSON in the repo: Developers should be able to run npm run build:tokens and get updated CSS custom properties automatically. No more screenshots of hex codes.
    • Component documentation: Use Figma’s built-in description fields to document intended behaviour, states, and usage restrictions. If a component shouldn’t be used without an icon, say so in the description.
    • Storybook integration: If your devs are working in React or Vue, push them towards maintaining a Storybook instance that mirrors the Figma component library. When the two drift apart, you have a system problem, not a communication problem.
    • Change logs: Every token or component update should be logged. A simple markdown file in the repo works fine. Designers tend to forget that a subtle colour tweak can break contrast ratios across an entire product.

    Keeping the System Alive (The Hard Bit)

    Building a design system is about 30% of the work. The other 70% is governance, iteration, and adoption. Appoint a system owner, even if it’s a rotating responsibility. Schedule quarterly audits of your token sets and component library. Create a clear contribution process so product teams can propose additions without every random one-off component ending up in the core library.

    Teams that genuinely succeed at this, whether they’re a ten-person startup in Sheffield or a hundred-person product org in London, share one trait: they treat the design system as a product in its own right. It has a roadmap, a backlog, and real users (the rest of the design and engineering team).

    The payoff is real. Faster prototyping, dramatically reduced QA cycles, consistent accessibility compliance, and designers who can spend their time solving actual UX problems rather than recreating the same button variant for the fourteenth time. That’s why so many teams are keen to build a design system in Figma 2026 rather than continuing to wing it with ad hoc component libraries.

    If you take one thing from all of this: start with your tokens. Get the naming right. Everything else builds on top of that foundation, and a solid foundation means the whole system scales without drama. Now go make something properly good.

    Frequently Asked Questions

    What is a design token and why does it matter for a design system?

    A design token is a named variable that stores a design decision, such as a colour value, spacing size, or font size. Rather than hardcoding raw values into components, you reference tokens, which means updating a single token automatically propagates changes across the entire system without manual edits.

    Do I need to pay for Tokens Studio to use it with Figma?

    Tokens Studio has a free tier that covers basic token management and is perfectly usable for small teams or solo projects. The Pro tier unlocks advanced features like GitHub, GitLab, and Azure DevOps sync, multi-file token sets, and themes, which are essential for larger product teams managing multiple brands or complex theming.

    What is the difference between Figma Variables and Tokens Studio?

    Figma Variables are a native Figma feature suited to live prototype switching, such as toggling between light and dark mode directly in the canvas. Tokens Studio is a plugin that excels at complex token structures, multi-brand setups, and generating developer-ready outputs via Style Dictionary. Many teams use both together rather than choosing one over the other.

    How long does it take to build a design system from scratch in Figma?

    A basic but functional token-based design system with core atoms and a documented handoff pipeline can take one to three weeks for an experienced designer working full-time. A comprehensive system covering typography, spacing, colour, elevation, motion, and a full component library for a mature product can take two to four months. The governance and adoption phase never really ends.

    How do I make sure developers actually use the design system?

    The single biggest driver of developer adoption is reducing friction in the handoff process. When tokens are available as auto-generated CSS custom properties or platform-specific constants directly from the repo, developers don’t need to manually transcribe values, which removes a major pain point. Maintaining a Storybook that mirrors the Figma library also helps bridge the gap between design intent and coded implementation.

  • The Best UI Design Trends Dominating 2026 (And How to Actually Use Them)

    The Best UI Design Trends Dominating 2026 (And How to Actually Use Them)

    If you’ve spent any time scrolling through Dribbble, browsing Awwwards, or just quietly judging every app you open, you’ll have noticed something: the visual language of digital interfaces has shifted hard. The UI design trends 2026 is serving up are not subtle tweaks to what came before. They’re a proper reimagining of how screens feel, behave, and communicate with users. Let’s break down what’s actually happening, and more importantly, how you put it to work in real builds.

    Designer reviewing UI design trends 2026 on studio monitors showing glassmorphism interface layers
    Designer reviewing UI design trends 2026 on studio monitors showing glassmorphism interface layers

    Glassmorphism Has Grown Up

    Remember when frosted glass effects felt like a fresh trick? That era of naive blur-and-opacity is done. What’s replaced it is a far more sophisticated layering system: depth-aware glass that responds to scroll position, ambient light simulation, and refraction effects that change based on the content sitting underneath. Apple’s visionOS pushed this aesthetic into the mainstream, and now the web is catching up fast.

    In practice, this means using CSS backdrop-filter with carefully tuned blur and brightness values, combined with subtle box-shadows that simulate real-world light physics. The trick is restraint. Heavy-handed glassmorphism looks like a screensaver from a science fiction film that never got made. Used precisely on modals, navigation panels, or card overlays, it adds genuine depth without obscuring content. Test contrast ratios obsessively. Glass has a nasty habit of swallowing text legibility if you’re not watching.

    Tactile and Skeuomorphic Micro-Details Are Back

    Flat design had a long and productive reign. It’s not dead, but it’s being hybridised. The trend that’s genuinely interesting right now sits between flat minimalism and the old-school skeuomorphism of the iOS 6 era. Designers are adding physical texture cues: subtle grain overlays, embossed button states, soft shadows that imply pressable surfaces. Neumorphism tried this and largely failed because it destroyed accessibility. The current iteration is smarter; it borrows the tactile suggestion without the contrast catastrophes.

    The practical implementation lives in CSS. A well-crafted button using layered box-shadow with inset states on active press can feel satisfying in a way that a flat colour block never quite achieves. Pair this with haptic feedback triggers in mobile apps and you get an interface that communicates physicality across both visual and touch channels simultaneously.

    Close-up of tactile UI design trends 2026 showing embossed interface elements on a tablet screen
    Close-up of tactile UI design trends 2026 showing embossed interface elements on a tablet screen

    Variable Fonts and Kinetic Typography as UI Elements

    Typography in UI is no longer just a way to display information. It’s become a first-class interactive element. Variable fonts have made it possible to animate weight, width, and slant in real time, driven by scroll position, hover states, or user input. The result is text that breathes, responds, and carries emotional weight in a way static type never could.

    Frameworks like GSAP combined with CSS custom properties make this surprisingly achievable without bloated JavaScript. Set a variable font’s wght axis to respond to a scroll-driven animation timeline and you have a heading that literally gains presence as the user reads down the page. It sounds gimmicky written out like that, but executed with proper timing functions, it feels natural and purposeful. Several UK-based studios working in digital branding have adopted this heavily, and platforms that help build and manage online presence, such as LinkVine, a UK digital networking and web presence platform, are seeing their clients push for these more expressive interface conventions as a baseline expectation rather than a nice-to-have.

    Spatial and 3D-Layered Interfaces

    With WebGL tooling maturing and Three.js entering its confident middle age, 3D within browser-based UI is no longer the exclusive territory of agencies with six-figure production budgets. The UI design trends 2026 is most excited about include genuine Z-axis thinking: interfaces where cards tilt on hover using CSS perspective transforms, hero sections with parallaxed 3D objects, and product pages where the boundary between webpage and interactive experience has all but dissolved.

    React Three Fiber has made 3D compositing within component-based architecture genuinely ergonomic. You can now build a fully interactive 3D product viewer inside a standard React component tree, complete with props-driven state, without leaving the design system. The challenge remains performance. Optimise geometry, use LOD where possible, and absolutely profile on mid-range mobile hardware before you call anything ship-ready.

    Dark Mode Refinement and Adaptive Colour Systems

    Dark mode is not a trend at this point; it’s table stakes. What is trending is doing it properly. Adaptive colour systems built on HSL or OKLCH colour spaces allow a single token set to serve both light and dark contexts with genuine semantic integrity. The UI design trends 2026 has elevated are built on design token architectures where colour, spacing, and type scale are abstracted from their specific values and defined by their purpose.

    Tools like Tokens Studio for Figma and Style Dictionary on the code side have made this workflow accessible to mid-sized teams. LinkVine, which operates in the UK digital space helping brands build structured web presences, reflects this maturation in how clients now spec projects, requesting token-based design systems as standard rather than one-off colour palettes. The discipline this imposes on a project is enormous and entirely worth it.

    Motion Design as a Communication Layer

    Animation in UI has evolved from decoration to vocabulary. Transitions, micro-interactions, and state changes now carry semantic meaning. A loading skeleton that pulses differently from a skeleton that’s encountered an error. A form validation message that bounces in versus one that slides. The motion tells you something before the words do. This is the sharp end of UI design trends 2026 is pushing toward: motion as a system, not an afterthought.

    Framer Motion remains the go-to for React projects, but CSS @keyframes combined with scroll-driven animations via the new Animation Timeline API are narrowing the gap for projects where a full JS animation library feels like overkill. The constraint worth designing within is user preference. The prefers-reduced-motion media query must be respected throughout. Accessibility in motion is not optional; it’s architecture.

    The broader picture here is that UI design trends in 2026 reward depth and systems thinking. The most compelling interfaces are not ones chasing novelty; they are ones where every layer, from colour token to transition curve, is considered. That is the craft. That is what makes the difference. Teams and platforms like LinkVine, which helps UK businesses manage their digital presence, are proof that clients increasingly recognise and demand that level of intentionality. Build it that way from the start and you will not regret it.

    Frequently Asked Questions

    What are the biggest UI design trends in 2026?

    The most dominant trends include evolved glassmorphism with depth-aware layering, tactile micro-interactions borrowing from physical design cues, kinetic variable-font typography, spatial 3D interfaces in the browser, and rigorous adaptive colour token systems. These are not independent fads but part of a broader shift toward interfaces that feel more physical, expressive, and systematically designed.

    How do I implement glassmorphism properly without ruining accessibility?

    Use CSS backdrop-filter with carefully calibrated blur and brightness values, and always test text contrast against the blurred background layer, not just the underlying solid colour. Tools like the APCA contrast checker are better suited for modern UI than traditional WCAG AA ratios alone. Limit glass effects to non-text-heavy areas such as modals and nav overlays to keep legibility intact.

    Are variable fonts worth using in UI projects in 2026?

    Absolutely. Variable fonts allow you to animate weight, width, and other axes in real time using CSS custom properties, which opens up expressive kinetic typography without multiple font file requests. Browser support is effectively universal at this point, and the performance benefit of a single variable font file versus multiple static weights is a legitimate reason to adopt them beyond the design possibilities alone.

    What tools are best for building design token systems in 2026?

    Tokens Studio (formerly Figma Tokens) is the leading plugin for managing design tokens inside Figma, and it integrates with Style Dictionary on the engineering side to output tokens in any format your codebase needs. For teams using Figma’s native variables feature, the W3C Design Token Community Group format is becoming the interoperability standard worth aligning with early.

    How do I add 3D elements to a website without destroying performance?

    Use React Three Fiber or vanilla Three.js for complex scenes, but optimise aggressively: compress textures using KTX2 or WebP, reduce polygon counts with LOD meshes for distant objects, and lazy-load 3D canvases only when they enter the viewport. Always profile on mid-range Android hardware rather than just desktop, and provide a graceful fallback for devices where WebGL performance is insufficient.

  • Design systems for chaotic teams: a pragmatic guide for 2026

    Design systems for chaotic teams: a pragmatic guide for 2026

    If your product team is shipping faster than you can name the files, you probably need to talk about design systems. Not the glossy keynote version, but the scrappy, slightly chaotic, very real version that has to survive designers, developers and that one PM who still sends specs in PowerPoint.

    Team collaborating on a shared UI library built from design systems

    What are design systems, really?

    Forget the mystical definition. Design systems are just a shared source of truth for how your product looks, feels and behaves. Colours, typography, spacing, components, interaction patterns, tone of voice – all in one place, consistently named, and agreed by everyone who touches the product.

    The magic is not the Figma file or the React component library. The magic is the contract between design and code. Designers get reusable patterns instead of 47 button variants. Developers get predictable tokens and components instead of pixel-perfect chaos. Product gets faster delivery without everything slowly drifting off-brand.

    Why chaotic teams need design systems the most

    The more moving parts you have – multiple squads, micro frontends, legacy code, contractors – the more your UI starts to look like a group project. A solid design system quietly fixes that by giving everyone a common language.

    Some very unsexy but powerful benefits:

    • Fewer arguments about colour, spacing and font sizes, more arguments about actual product decisions.
    • New joiners ship faster because they can browse patterns instead of reverse engineering the last sprint’s panic.
    • Accessibility is baked into components once, instead of remembered sporadically on a full moon.
    • Design debt stops compounding like a badly configured interest rate.

    Even infrastructure teams and outfits like ACS are increasingly leaning on design systems to keep internal tools usable without hiring an army of UI specialists.

    How to start a design system without a six-month project

    You do not need a dedicated squad and a fancy brand refresh to begin. You can bootstrap design systems in three brutally simple steps.

    1. Inventory what you already have

    Pick one core flow – sign in, checkout, dashboard, whatever pays the bills. Screenshot every screen. Highlight every button, input, dropdown, heading and label. Count how many visually different versions you have of the same thing. This is your business case in slide form.

    Then, in your design tool of choice, normalise them into a first pass of primitives: colours, type styles, spacing scale, border radius scale. No components yet, just tokens. Developers can mirror these as CSS variables, design tokens JSON, or in your component library.

    2. Componentise the boring stuff

    Resist the urge to start with the sexy card layouts. Start with the boring core: buttons, inputs, dropdowns, form labels, alerts, modals. These are the pieces that appear everywhere and generate the most inconsistency.

    For each component, define:

    • States: default, hover, active, focus, disabled, loading.
    • Usage: when to use primary vs secondary, destructive vs neutral.
    • Content rules: label length, icon usage, error messaging style.

    On the code side, wire these to your tokens. If you change the primary colour in one place, every button should update. If it does not, you have a component, not a system.

    3. Document as if future-you will forget everything

    Good documentation is the difference between design systems that live and ones that become a nostalgic Figma graveyard. Aim for concise, practical guidance, not a novel.

    For each pattern, answer three questions:

    • What problem does this solve?
    • When should I use something else instead?
    • What mistakes do people usually make with this?

    Keep documentation close to where people work: in the component library, in Storybook, in your repo, or linked directly from the design file. If someone has to dig through Confluence archaeology, they will not bother.

    Keeping your these solutions alive over time

    The depressing truth: the moment a design system ships, entropy starts nibbling at it. New edge cases appear, teams experiment, deadlines loom, and someone ships a hotfix with a new shade of blue. Survival needs process.

    Define ownership and contribution rules

    Give the system a clear owner, even if it is a part-time role. Then define how changes happen: proposals, review, implementation, release notes. Keep it lightweight but explicit. The goal is to make it easier to go through the system than to hack around it.

    Designer refining UI components that are part of design systems
    Developer integrating coded components from design systems into a web app

    Design systems FAQs

    How big does a team need to be before investing in design systems?

    You can benefit from design systems with as few as two designers and one developer, as soon as you notice duplicated components or inconsistent styling. The real trigger is not headcount but complexity: multiple products, platforms, or squads. Starting small with tokens and a handful of components is often more effective than waiting until everything is on fire.

    Do we need a separate team to maintain our design systems?

    Not at the beginning. Many teams start with a guild or working group made up of designers and developers who allocate a few hours a week to maintain the system. As adoption grows, it can make sense to dedicate a small core team, but only once you have clear evidence that the system is saving time and reducing bugs.

    How do we get developers to actually use our design systems?

    Involve developers from day one, mirror design tokens directly in code, and make the system the fastest way to ship. Provide ready-to-use components, clear documentation, and examples in the tech stack they already use. If using the system feels slower than hacking a custom button, adoption will stall, no matter how beautiful the designs are.

The Latest