Category: Design

  • Why British B2B SaaS Homepages All Look the Same in 2026, and the Layout Decisions That Would Actually Differentiate Them

    Why British B2B SaaS Homepages All Look the Same in 2026, and the Layout Decisions That Would Actually Differentiate Them

    Spend ten minutes clicking through British B2B SaaS homepages and a peculiar vertigo sets in. There’s the centred headline in Inter or Plus Jakarta Sans, somewhere between 52px and 72px, promising to “streamline your workflow”. Below it, three trust badges from G2 or Capterra. Then a feature grid: three or four cards, each with a small icon, a bold subtitle, and two sentences of copy that could have been written by anyone for anything. If you’re lucky, there’s a dashboard mockup floated at an angle, casting a soft drop shadow over a gradient background. I’ve audited close to forty of these sites in the past few months and I can tell you: B2B SaaS homepage design UK 2026 has a serious sameness problem.

    This isn’t a style complaint. It’s a conversion problem. When every competitor looks identical, you’re not competing on design at all. You’re competing solely on whichever ad someone saw last, or which sales rep rang first. The homepage, the one page almost every buyer visits before they sign up for a demo, has become a genre with its own rigid conventions, and those conventions are actively harming differentiation.

    Designer reviewing B2B SaaS homepage design UK 2026 examples on monitor
    Photo by Hanna Pad on Pexels

    How the formula became universal

    There’s an obvious origin story. A handful of high-growth US SaaS companies in the mid-2010s hit on a pattern that converted well for them: big headline, social proof, feature breakdown, CTA. Webflow and Framer then packaged those patterns into templates. Growth marketers A/B tested their way to similar conclusions across dozens of markets. Design agencies, rightly trying to reduce client risk, defaulted to what had “worked before”. And so the formula calcified.

    The trust-badge strip is the clearest tell. It exists because third-party validation reduces anxiety at the top of the funnel. That’s a legitimate goal. But when the strip contains the same four logos (G2, Capterra, Trustpilot, and one enterprise client badge) in the same greyscale treatment, directly beneath a headline that also matches your competitor’s, you’ve created something that functions as camouflage rather than signal. Buyers scroll past trust badges now. They’ve been conditioned to.

    The feature grid below is even more blunt. Three columns. Icon. Bold title. Short paragraph. It answers “what does it do” efficiently, but it says almost nothing about why this product specifically. Every grid implies that features are comparable and interchangeable. Which, for a category leader, is a terrible frame to establish on your own homepage.

    What a visual audit of UK SaaS homepages actually reveals

    I ran a rough audit across thirty-five UK-headquartered B2B SaaS products spanning HR tech, fintech infrastructure, legal tech, and property management software. The findings were depressingly consistent. Ninety-one per cent led with a centred headline and subheading. Eighty-six per cent had a trust-badge strip within the first two screen-heights. Seventy-eight per cent used a three or four-column feature grid. Not a single one opened with a full-bleed editorial-style image or a typographic treatment that looked genuinely distinctive.

    The typographic choices compound the problem. Inter is everywhere, it’s a superb typeface, which is exactly why it no longer signals anything except “we used the default”. The semantic colour systems that UK design teams are building internally rarely make it to the public marketing site, where someone has apparently decided that navy, white, and one “brand accent” colour covers everything. The result is a palette that’s legible but forgettable.

    Motion makes things worse, not better. Scroll-triggered fade-ins have become so ubiquitous that they’ve become invisible. A feature section that cascades in with staggered opacity animations used to feel polished; now it just feels like everyone watched the same Webflow tutorial. I’d argue that a static, confidently composed page with zero scroll animations would feel more distinctive in 2026 than a page with tasteful micro-interactions, which tells you something about how far this has gone.

    Layout decisions that would actually differentiate

    So what does a genuinely different B2B SaaS homepage look like? A few directions I’d push clients towards:

    Left-aligned, editorial-weight typographic heroes

    Centred heroes exist because they feel balanced and safe. Left-aligned editorial layouts feel like a magazine or a newspaper: authoritative, confident, and legible in a way that centred copy isn’t. Set your headline at 96px in a geometric serif, something like Fraunces or a properly licensed display face, flush left, with the CTA anchored at the baseline. The visual tension between a heavy typographic block and whitespace on the right is itself communicative. It says the company has opinions.

    Replace the trust strip with a single, specific proof point

    Pick one number that’s impossible to fake and hard to ignore. Not “used by 500+ companies” but “reduced supplier invoice processing time by 34% for Farrow & Ball’s procurement team in Q3 2025”. Put it in 48px type, cite it properly, and link to the case study. One credible specific claim beats four anonymous badge logos. The ONS data on UK IT industry growth repeatedly shows that B2B purchase decisions are driven by evidence of ROI, not social proof signals, and specific quantified evidence converts better than generic validation.

    Narrative feature sections over grids

    Instead of three cards in a row, try an alternating two-column layout where each feature gets a full half-screen. Left column: a real screenshot or a composed illustration showing the feature in context. Right column: a short, opinionated paragraph that explains not what the feature does but what it means for the person reading. This forces copywriters to write about outcomes and forces designers to produce actual product shots rather than icon-plus-tagline placeholders. It’s slower to produce, which is probably why nobody does it, and that’s exactly the point.

    Problem-led above the fold

    Most SaaS homepages open with the solution. “Meet [Product]: the platform that does X.” Try opening with the problem instead. A single brutal sentence naming the specific pain of the specific buyer. “Your finance team is still exporting to Excel to reconcile what your SaaS stack should be doing automatically.” That kind of opener presupposes the buyer’s context rather than explaining the product’s features, which immediately creates the feeling that this company understands them. It’s a copywriting decision as much as a layout one, but it changes how the whole page is structured from the hero down.

    The dashboard mockup problem

    I need to talk about the floating dashboard. The tilted-at-25-degrees, drop-shadow-heavy, gradient-background product screenshot has become the SaaS homepage’s equivalent of a stock photo of a woman laughing at a salad. It signals “software” without showing anything. When every competitor floats the same kind of mockup, you’ve created a visual genre rather than a product demonstration.

    The alternative isn’t removing product visuals, buyers need to see what they’re buying. The alternative is context. A screenshot of your dashboard shown on an actual desk, in an actual working environment. Or a short, looping screen recording that shows a real workflow completing in eight seconds. Or a composed sequence of three moments in the user journey, captioned with the time saved at each step. Any of these is harder to produce than dropping a PNG into a Figma mockup template and tilting it. Which is, again, the point. Web performance considerations matter here too, large hero images and animated mockups are among the most common contributors to poor LCP scores on UK SaaS marketing sites.

    Typography as differentiation

    If you want your homepage to look different, the fastest lever is typeface choice. Inter, DM Sans, and Plus Jakarta Sans are all technically excellent and visually indistinct from one another at scale. Open source font pairing has matured significantly in 2026, there are genuinely interesting options available without a licensing bill. Fraunces for display, Literata for body copy, Anybody for tabular data labels. These aren’t exotic choices; they’re just slightly less default ones, and that distance from the default is what the eye catches.

    Pair unconventional typeface choices with deliberate typographic scale. Most SaaS sites use a type scale that compresses everything into a narrow range: 16px body, 24px subheadings, 52px headlines. Try an aggressive scale: 14px body, 20px subheadings, 96px display. The contrast between the display size and the body size creates a visual hierarchy that guides the eye without needing layout gimmicks.

    This isn’t about being weird for its own sake

    The goal here isn’t to build a homepage that wins design awards and fails to convert. Conversion matters. The point is that the current formula has been copied so widely that it no longer confers the conversion advantages it once did. A buyer who has visited six competitor sites in the same afternoon needs a reason to pause. Right now, most UK B2B SaaS homepages give them no such reason. The irony is that the safe, formula-driven approach feels lower risk but is genuinely higher risk, because it guarantees you look like everyone else in a market where looking like everyone else is the worst possible outcome.

    Breaking from the formula doesn’t require a brand overhaul or a six-month redesign project. It requires a clear point of view: about who the buyer is, what they’re struggling with, and why this particular product is the specific answer. That point of view should drive every layout decision, every type choice, and every piece of visual evidence on the page. When it does, the homepage stops being a genre exercise and starts being an actual argument.

    Frequently Asked Questions

    Why do so many B2B SaaS homepages look identical in 2026?

    The formula, centred hero, trust badges, feature grid, spread through shared templates on Webflow and Framer, plus agencies defaulting to “what’s worked before”. High-growth SaaS companies validated the pattern in the mid-2010s and it was copied so widely that it stopped conferring any competitive advantage.

    Does breaking the standard SaaS homepage formula hurt conversion rates?

    Not inherently. The concern is understandable, but the standard formula only converted well when it was novel. When every competitor uses it, it becomes noise rather than signal. Specific, opinionated design choices that reflect a clear understanding of the buyer tend to build more trust, not less.

    What typefaces work well for B2B SaaS homepages that want to stand out?

    Fraunces and Literata are strong open-source options that read as confident without being gimmicky. The key is pairing a distinctive display face with a clean body typeface and using an aggressive size scale, wide contrast between headline and body sizes creates hierarchy without needing layout tricks.

    Are floating dashboard mockups still effective for SaaS marketing sites?

    They’ve become so ubiquitous they’ve stopped working as differentiators. A contextual screenshot showing the product in a real working environment, or a short looping screen recording of an actual workflow, tends to communicate more about the product and feel more credible to buyers who’ve seen dozens of tilted PNG mockups.

    How important is the hero section for B2B SaaS conversion?

    Extremely. Most B2B buyers visit the homepage before booking a demo or starting a trial, so the above-the-fold section does enormous work. A problem-led opener that names a specific buyer pain tends to convert better than a product-led opener that lists features, because it immediately signals to the reader that the company understands their context.

  • Contrast Grids and Colour Token Naming: How UK Design Teams Are Finally Solving Their Semantic Colour System Problems

    Contrast Grids and Colour Token Naming: How UK Design Teams Are Finally Solving Their Semantic Colour System Problems

    Colour decisions in product design look deceptively simple until your rebrand lands, someone switches to dark mode, and your carefully chosen palette turns into a contrast disaster that fails WCAG AA at about twelve different points. I’ve watched this happen to teams who thought they had a proper colour system, only to discover they had a colour list with a system-shaped name badge on it. There is a meaningful difference, and design system colour tokens UK teams are increasingly using to close that gap are finally mature enough to be worth writing about seriously.

    Designer reviewing design system colour tokens UK documentation on a large monitor
    Photo by cottonbro studio on Pexels

    What a real semantic colour token system actually looks like

    The core idea is layered naming. You have primitive tokens at the bottom: raw values like blue-500: #2563EB. Above that sit semantic tokens that describe function rather than appearance: colour-interactive-default, colour-surface-elevated, colour-feedback-error. The primitive never goes directly into a component. The semantic token does. The layer in between is where the magic happens, because when a rebrand requires swapping blue-500 for teal-600, you change one reference and everything that consumes colour-interactive-default updates automatically.

    This three-tier approach, often called primitive, semantic, and component-level tokens, has been championed by Salesforce’s Lightning Design System for years, but UK product teams have been slower to adopt it fully. Part of that is legacy: many British SaaS companies built their design systems before design tokens were a coherent concept, and the technical debt of retrofitting a flat Sass variable file into a structured token architecture is real. The other part is that tooling only recently caught up.

    Why naming conventions matter more than most teams realise

    Here’s where I’d argue most colour system conversations go wrong. Teams spend weeks debating whether blue-500 should be #1D4ED8 or #2563EB, and approximately twenty minutes on naming conventions. Then they ship tokens with names like primaryBlue, brandGreen, and accentColor1, which are essentially useless the moment a new designer joins or the brand team decides teal is the new blue.

    A robust naming convention is schema-first. The structure I’ve seen work best in UK teams follows: [namespace]-[category]-[property]-[variant]-[state]. So ds-colour-text-primary-hover instead of textHoverMain. The namespace scopes the token to your system and prevents collisions if you’re working in a monorepo with multiple products, which plenty of UK B2B companies are. Category and property describe what the token affects. Variant and state handle the stuff that trips everyone up: default versus disabled, rest versus hover versus focus.

    The W3C Design Tokens Community Group published their format specification to standardise how tokens are stored and transferred between tools. It’s not a finished standard yet, but it’s close enough that Figma’s variables implementation and Style Dictionary both align with it reasonably well. If you’re building a token system in 2026 and not at least glancing at that spec, you’re probably building something you’ll have to rebuild in two years.

    Contrast grids: the tooling that makes WCAG compliance tractable

    WCAG 2.1 AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text and UI components. WCAG 2.2, which the UK public sector accessibility requirements point to for public sector digital services, doesn’t change those ratios but adds a clearer expectation that you’ve done the work systematically. The problem is that checking every foreground-background combination manually is genuinely tedious. A palette with twelve colours has 66 unique pairs. If you’re also considering dark mode, you’ve effectively doubled your matrix.

    Contrast grids, popularised by Eightshapes’ free tool, solve this by visualising the entire foreground-background matrix at once. You input your palette, and the grid shows every combination colour-coded by whether it passes AA, AAA, or fails entirely. This is enormously useful not just for compliance checking but for making design decisions. When you can see that your neutral-700 passes AA on both your surface-primary and surface-secondary but fails on surface-tertiary, you can encode that constraint directly into your token documentation rather than waiting for it to surface in a QA pass.

    Several UK product teams I’m aware of have started integrating automated contrast checking into their CI pipelines using tools like @accessibility-checker/contrast or custom scripts built on the wcag-contrast npm package. The idea is that a token file change that introduces a failing combination gets flagged in the pull request before it ever reaches a designer’s screen. That’s the right direction. Catching contrast failures at the system level rather than the component level is much cheaper to fix.

    Dark mode is where token systems either prove themselves or collapse

    Dark mode is the stress test every semantic colour token system has to pass eventually. If you’ve built a flat system where components reference primitive values directly, implementing dark mode means touching every component. If you’ve built a properly layered system, dark mode is just a second theme file that remaps your semantic tokens to different primitives.

    In practice, this looks like having two sets of semantic token values: one for light mode, one for dark. colour-surface-primary maps to neutral-100 in light and neutral-900 in dark. A CSS custom property implementation handles the swap via prefers-color-scheme or a data attribute on the root element. Style Dictionary can output both token sets as separate CSS files or as a single file with media query scoping.

    Where teams go wrong is assuming their colour palette works symmetrically in both modes. It almost never does. A contrast grid for your dark mode token mappings is not optional; it’s a separate exercise from your light mode grid, because the contrast ratios change when you flip surfaces. I’d recommend running both grids simultaneously when you’re building out a dual-mode system, and locking the acceptable pairings into your token documentation so that designers can’t accidentally use colour-text-secondary on colour-surface-overlay just because it looks fine in one mode.

    This connects directly to work happening at the component level too. If you’re already thinking carefully about how CSS container queries are reshaping component architecture for UK frontend teams, it’s worth considering how your colour token layer interacts with component-scoped theming. A component that can respond to its container’s size should probably also respond to a locally-scoped theme token rather than relying solely on document-level custom properties.

    Surviving a rebrand with a token system intact

    Rebrands are where semantic token systems pay back every hour of upfront investment. The UK financial services sector goes through brand refreshes constantly, and I’ve seen what happens to design systems that were built around hex values rather than token references. It’s not pretty. Months of find-and-replace work, inevitably inconsistent across products, with rogue legacy values lurking in edge cases until someone files a bug six months later.

    A token system handles this cleanly. Your primitive tier changes. Your semantic tier doesn’t. Your components certainly don’t. If your new brand blue is #1A56DB instead of #2563EB, you update one value, run your contrast grid to confirm nothing broke, and ship. That’s the whole thing.

    Teams building more complex multi-brand or white-label products need to go one level further. Rather than a single primitive-to-semantic mapping, they maintain multiple primitive tiers (one per brand) that all map to the same semantic layer. This is the approach used in sophisticated public sector design systems, and it scales well into the kind of multi-tenant SaaS architecture where a single codebase serves several clients with different brand guidelines.

    The toolchain that makes this tractable in 2026 is roughly: Figma variables for design-side token management, Style Dictionary for transformation and output to CSS, JSON, Swift, Kotlin or whatever your platforms need, and a contrast grid check baked into your release process. None of these tools are particularly new. The difference is that they now work well together, and the naming conventions are stable enough that a token defined in Figma actually means the same thing when it emerges from Style Dictionary on the other side.

    If you’re also thinking about how design system decisions affect the designer-developer handoff, the current state of Figma’s Dev Mode is relevant here; token visibility in dev mode has improved substantially, and a well-structured token system makes the handoff cleaner regardless of which side of the gap you’re on.

    The teams doing this well right now are not necessarily the largest UK product organisations. Some of the most rigorous colour token work I’ve come across is happening at mid-size British fintechs and healthtech companies where the contrast requirements are non-negotiable and the rebrand cycle is fast. Necessity, as always, is doing most of the architectural work.

  • Print-to-Web Design Systems: How UK Publishing Houses Are Finally Bridging Their Brand Identity Across Both Mediums

    Print-to-Web Design Systems: How UK Publishing Houses Are Finally Bridging Their Brand Identity Across Both Mediums

    For decades, British publishing houses ran two essentially separate design operations. The print team lived in InDesign, Quark, and a proprietary colour system calibrated to CMYK press output. The digital team worked in whatever flavour of the week the web side had adopted, arguing about hex values and spacing scales that bore no relation to the print grid. The result was brand identity that forked the moment it left the studio: the same masthead, visually inconsistent across a magazine rack and a mobile browser. A print to web design system for UK publishing is the thing that finally addresses this, and in 2026 a handful of serious British media brands are making genuine headway.

    Designer working on a print to web design system at a UK publishing studio desk with magazine and Figma open
    Photo by RDNE Stock project on Pexels

    What makes this interesting from a systems perspective is that the problem is not merely cosmetic. It is architectural. Print design operates on a fixed-canvas, output-specific model where colour is defined in CMYK or Pantone, type is set in points, and the grid is absolute. Web design is fluid, responsive, device-agnostic. You cannot simply export one into the other. The teams that are succeeding are the ones that have stopped trying to translate between the two worlds and started building a shared language above both of them.

    Token architecture as the common layer

    Design tokens are the real unlock here. The idea, borrowed from software engineering, is that you define your design decisions (colour, type scale, spacing, border radius) as named values in a format-agnostic source of truth, then compile those tokens into whatever output each platform needs. For a publisher, that means a single token file can generate CSS custom properties for the web team, SCSS variables for the app team, and a colour swatch library that InDesign can actually consume via a plugin like Chroma or the Pantone Connect bridge.

    I have been watching how the team at one of the UK’s larger regional newspaper groups approached this. They started with colour, which is always the politically charged one in editorial. The brand had a primary red that existed in three slightly different hex values across their digital properties, and a CMYK equivalent that had drifted from the RGB over years of unchecked conversion. The first task was not building a system; it was forensic brand archaeology. They audited every asset, established a canonical sRGB value, derived the closest CMYK equivalent that would not blow out on newsprint, and then stored both in a single token. That token became the source of truth. Everything downstream consumed it. The print team got their CMYK. The web team got their hex. Nobody had to argue any more.

    The InDesign-to-Figma handoff problem

    This is where most print to web design system UK publishing projects either stall or produce something that technically exists but nobody uses. Figma is now the default tool for digital product design in UK agencies and in-house teams. InDesign is still the default for editorial layout, and there is no clean bridge between them. The tooling just does not exist in the way people wish it did.

    The workarounds I have seen actually work tend to fall into one of two camps. The first is a Figma library that mirrors the brand’s InDesign paragraph styles as Figma text styles, and the InDesign colour swatches as Figma colour variables. It is manual to set up, and it requires a human guardian to keep the two in sync as the brand evolves. Not elegant, but it works. The second camp is using a token management tool such as Style Dictionary or Tokens Studio (formerly Figma Tokens) to sit in between, pushing updates bidirectionally. This requires a bit of engineering investment, but for a publisher with multiple digital products and a monthly print title, the maintenance saving over three years is considerable.

    Print colour swatches next to digital design tokens on screen, illustrating the print to web design system workflow for UK publishing
    Photo by Fiona Murray on Pexels

    What I find genuinely tricky is typography. Print editorial type is set in absolute point sizes against a fixed baseline grid, often at sizes that would be absurd on screen (a 7pt caption, for instance, reads fine in print and is invisible on a phone). Web type, especially with fluid typography using modern CSS techniques like clamp(), is inherently relative. The token layer helps here too, but you end up with two separate type-scale tokens that share naming conventions without sharing values, which is honestly probably the right answer even if it feels philosophically unsatisfying.

    Where the biggest friction still lives

    Talk to any design systems lead at a UK media brand and they will tell you the hardest part is not the tooling. It is organisational. Print production teams and digital product teams have different cadences, different vocabulary, and different relationships with “the brand”. Print designers think in issues and editions. Digital designers think in components and releases. Neither is wrong. They are optimised for their medium. The friction is that a unified design system asks both sides to participate in a shared governance process they did not sign up for and do not have time for.

    The publishers making the most progress have appointed someone whose explicit job is to sit at that intersection. Not a print art director moonlighting in Figma, and not a UX designer who vaguely appreciates print. Someone who understands both production realities and has the political capital to tell both sides when the system wins over personal preference. The GOV.UK Design System works partly because it has that governance model baked in from the start. Private sector publishers are learning the same lesson the hard way.

    There is also a component naming problem that does not get discussed enough. InDesign templates use names like “StandFirst A” and “Dropcap Variant 3”. Figma components use names like “Typography/Body/Regular/16” or “Card/Article/Horizontal”. When you try to create a shared vocabulary, you either confuse the print team or you force them to abandon twenty years of muscle memory. The best systems I have seen build a translation layer into the documentation, rather than forcing one naming convention on both sides.

    What smaller publishers can actually do right now

    Not every UK publisher has the budget of a Condé Nast or a Reach plc. If you are a regional magazine, a specialist trade title, or an independent with a small design team, the enterprise token pipeline is overkill. Here is my honest take on what is actually achievable.

    Start with colour and type. Define your brand colours in a shared spreadsheet (yes, a spreadsheet) with columns for the colour name, hex, RGB, CMYK, and Pantone. Make that document the single source of truth. Pin it in every Slack channel design touches. Then create a Figma library from it and an InDesign swatch file from it. That is your first token layer. It is not automated, but it is consistent, and consistency is the actual goal.

    For the web side of this, the lessons from building shared design systems translate well beyond publishing. Small business web design faces a similar challenge at a different scale: brand assets built for one context (usually print, signage, or a PDF brochure) need to translate into something that works on screen. UK firms like dijitul Web Design, which builds custom small business websites, ecommerce web design, and WordPress and Shopify sites from dijitulwebdesign.co.uk, see this constantly with clients who hand over a CMYK logo and a brand guidelines PDF written for print and expect a coherent website redesign. The token logic that publishers are adopting at scale applies at this level too: define your canonical colour values, establish your type scale, then generate the correct output for each medium rather than manually converting between them.

    The improvements to Figma’s Dev Mode have made the handoff from design to web development considerably less painful over the past year, which helps the digital side of any print to web design system UK publishing workflow. But Dev Mode does not solve the upstream problem of getting print assets into Figma cleanly in the first place. That is still largely a human problem requiring a human process.

    One thing worth flagging for publishers thinking about this: the UK Government Service Standard offers a useful model for thinking about design governance even if you are not a public sector organisation. Its insistence on documented decision-making, accessibility from the start, and consistent component libraries is exactly the discipline that print-heavy organisations need to impose on their digital output.

    The component library question also touches on accessibility in ways that print never had to care about. Web components need to meet WCAG 2.2 AA as a baseline. Print had no such mandate. When you merge the two traditions, the digital accessibility requirements should win every time a decision point arises. That means some print design conventions (low contrast decorative text, type reversed out of textured backgrounds) simply cannot make it into the shared system unchanged.

    The honest answer to where this is all heading: the tools will get better, the token formats will stabilise further (the Design Tokens Community Group W3C spec is slowly becoming something real), and the organisational resistance will gradually erode as the designers who grew up switching between Figma and InDesign reach senior roles. For now, the publishers making progress are doing it through good governance and disciplined token work, not through any single magic tool. That, I think, is exactly as it should be.

    The brand consistency wins are real when it lands. A reader who picks up the print edition and then opens the app should feel the same visual language working on them. That is not a trivial achievement when the two artefacts are produced by different teams, in different tools, on different timescales. It just requires more upfront system thinking than most publishers have historically been willing to do.

  • Pixel Art Is Having a Serious Revival: How UK Indie Game Studios Are Using It as a Deliberate Design Statement in 2026

    Pixel Art Is Having a Serious Revival: How UK Indie Game Studios Are Using It as a Deliberate Design Statement in 2026

    There is something quietly radical happening in UK indie game development right now. Pixel art indie game design, which spent a decade being dismissed as budget shorthand or nostalgia bait, has become one of the most deliberate, technically considered aesthetic choices a studio can make. I have watched this shift happen gradually, and by 2026 it is impossible to ignore. The studios turning up at EGX with pixel-driven titles are not doing it because they cannot afford a 3D artist. They are doing it because the constraint itself is the point.

    Monitor displaying a pixel art indie game design with colourful sprites on screen
    Photo by Yan Krukau on Pexels

    Why British developers specifically are drawn to pixel aesthetics

    Context matters here. The UK has a uniquely dense relationship with early home computing. The ZX Spectrum launched in 1982, the BBC Micro sat in virtually every state school by the mid-eighties, and an entire generation of now thirty-to-fifty-year-old developers grew up watching those machines squeeze colour from limitations you would not accept in a modern spreadsheet. When that generation starts building games professionally, or as a serious side project, the pixel aesthetic is not a random retro choice. It is practically a mother tongue.

    This is not pure nostalgia, though. The commercial evidence suggests younger audiences are responding too. According to BBC reporting on indie game market growth, British players consistently over-index for indie titles relative to AAA blockbusters, and pixel-heavy titles from UK studios like Chucklefish (Wargroove) and Team17 properties have demonstrated that the aesthetic travels globally without losing its identity. The culture supporting this goes well beyond the games themselves. Communities built around retro gaming, comic fandom, and physical collector culture, including enthusiast hubs like supazaar.co.uk, have helped cement the cultural appetite that makes pixel-driven games commercially sensible in 2026 rather than a gamble.

    The tooling behind modern pixel art game design

    Ask most people which tool pixel artists use and they will say Aseprite. They are right, but that barely scratches the surface of the current workflow. Aseprite remains the standard for frame-by-frame animation and sprite sheet management, and its scripting API means studios can automate palette swaps, generate animation previews, and pipe assets directly into their build pipelines. I have spoken to a few UK developers who use it alongside Pyxel Edit specifically for tiled environments, treating each tool as the right instrument for a specific job rather than expecting one application to do everything.

    Godot 4 has made a substantial difference here as well. Its 2D renderer handles pixel art natively without the sub-pixel jitter that used to plague Unity projects unless you spent an afternoon configuring camera snapping settings. The engine’s open-source model also means UK indie developers, many of whom are operating on tight budgets, can ship without licensing overhead eating into already thin margins. That practical economic calculation is part of why the pixel aesthetic has staying power: the toolchain is genuinely excellent and largely free.

    Designer working on pixel art indie game design at a graphics tablet
    Photo by Michael Burrows on Pexels

    Colour palette constraints as a design decision, not a limitation

    Here is where pixel art indie game design gets genuinely interesting from a craft perspective. Working within a restricted palette, say 16 or 32 colours, forces decisions that open-ended digital painting never requires. Every colour has to earn its place. The relationship between the darkest shadow tone and the highlight on a character sprite becomes a conscious compositional choice rather than something you can adjust with a curves layer later.

    The Lospec Palette List has become a reference point for UK developers wrestling with this. It catalogues hundreds of community-created palettes, many derived from real hardware constraints, and the conversation around which palette suits a given game’s emotional register is genuinely sophisticated. A cool, desaturated eight-colour palette reads differently to a warm thirty-two-colour one, and experienced pixel artists in the UK indie scene talk about palette selection the way a film cinematographer talks about colour grading. The constraint produces clarity.

    There is also a legibility argument. I have seen more than one post-mortem from UK game jam participants noting that games with tight palettes performed better on small screens and in noisy streaming thumbnails. When every colour is doing structural work, the visual hierarchy tends to be cleaner than in games where the art direction had no hard limits.

    How this connects to broader UI and UX craft

    The design discipline behind pixel art maps onto broader product thinking in ways that are worth taking seriously. The palette constraint logic is structurally similar to working within a design token system, where every colour value is declared and reused rather than picked afresh each time. If you spend any time thinking about how the GOV.UK Design System uses constraint to produce coherent interfaces, the pixel art parallel is immediately visible: deliberate limitation produces consistency, and consistency builds trust.

    There is a related point about legibility at scale. The same cognitive science that makes pixel art characters instantly readable at 16×16 pixels is behind good icon design and the accessibility principles baked into proper UI work. Incidentally, if you are interested in where product design currently fails users even without these constraints, there is a sharp read on how poor interface decisions are frustrating British app users in 2026 that connects directly to why clarity-first aesthetics resonate.

    EGX and the studio ecosystem making this real

    EGX, which runs annually at ExCeL London, has become a useful barometer for where UK indie game design is actually heading. The Leftfield Collection, which showcases experimental and unusual titles, has featured pixel-driven games in increasing numbers over the past few editions. What strikes me watching these studios present is that the pixel aesthetic is almost never the first thing they lead with in their pitch. The mechanic comes first, the world comes second, and the visual style is described as having emerged from those decisions. That ordering matters. It signals that the look is load-bearing, not decorative.

    Smaller studios like Whitethorn Games’ UK-based partners and outfits publishing through Curve Games have demonstrated there is a viable commercial model here. A well-executed pixel art title with strong mechanic design can build a sustainable audience on Steam and GOG without the marketing budget a 3D equivalent would demand. The visual distinctiveness of a coherent pixel palette makes trailers and screenshots punchy in a crowded storefront, which is a genuinely practical competitive advantage.

    Animation within the constraint: where the real craft lives

    If colour palette is the grammar of pixel art, animation is the prose. The anticipation frames, the squash on landing, the hold on a character’s idle cycle: all of this has to be communicated in far fewer pixels than a modern 3D rig would use for a single joint. UK pixel animators working in this space have talked publicly about studying old ZX Spectrum game sprites not for imitation but for compression logic, understanding how a two-frame walk cycle can read as convincingly as a twelve-frame one if the key positions are chosen correctly.

    This discipline connects directly to the work happening in CSS animation and browser motion design. I wrote recently about how UK freelancers are using CSS transitions to replace heavier animation tooling, and the underlying principle is similar: identify the minimum number of states you need to communicate the motion, then nail those states rather than filling every frame. Economy is the technique.

    Pixel art in UK indie games is not a trend that is about to cycle out. The tooling is mature, the cultural grounding is deep, and the constraint-first design logic it demands produces genuinely better outcomes than unlimited creative freedom often does. British developers who grew up on the Spectrum and BBC Micro built an aesthetic vocabulary from necessity. Their successors are choosing that vocabulary on purpose, and the results are some of the most considered game design coming out of the UK right now.

  • The Honest State of Figma’s Dev Mode in 2026: Is It Actually Closing the Designer-Developer Gap for UK Teams?

    The Honest State of Figma’s Dev Mode in 2026: Is It Actually Closing the Designer-Developer Gap for UK Teams?

    I’ve been poking around in Figma’s Dev Mode across several client projects this year, and the gap between what Figma’s marketing says it does and what actually happens when a developer opens it on a Monday morning is… significant. Not always in a bad way. But significant. This Figma Dev Mode review 2026 is the version I wish existed before I recommended it to three different UK product teams last quarter.

    Designer and developer reviewing Figma Dev Mode review 2026 output together on screen
    Photo by cottonbro studio on Pexels

    What Dev Mode is actually supposed to do

    The pitch is clean: designers build in Figma, developers switch into Dev Mode, and they get clean CSS snippets, spacing values, asset exports, and component annotations without needing to bother the designer every five minutes. In theory, it collapses the handoff layer entirely. No more Zeplin subscriptions. No more Figma-to-Storybook breakdowns. No more developer staring at a design file and screaming internally because the padding is specified in some arbitrary unit that makes no sense.

    In practice, it’s about 70% there. Which is both impressive and maddening depending on what day of the week you’re asking.

    Where it genuinely works well in 2026

    Auto Layout translation has improved considerably. If your designers are using Auto Layout properly (a big if, and I’ll get to that), the generated CSS is surprisingly usable. Flexbox output is mostly correct now. I’ve seen developers on React and Svelte projects copy the generated snippets and use them with minimal modification, which two years ago felt like science fiction.

    The code panel now distinguishes between absolute and relative values more reliably. Variables, particularly colour tokens, surface properly in the panel when they’ve been applied via Figma’s own variable system. For teams that have invested properly in a design token setup, this is genuinely useful. I’ve worked with a Leeds-based fintech that spent about six weeks migrating their design system to Figma variables specifically to leverage this, and the reduction in developer questions about hex codes alone made it worthwhile.

    Component inspection has also come on. If a designer has annotated a component correctly, developers can see the intended behaviour, variants, and states without digging through layer panels. This pairs well with the kind of systematic component-first thinking we’ve covered in pieces like our look at how container queries are changing component design for UK frontend teams.

    Figma Dev Mode review 2026 showing CSS code panel with design tokens and spacing values
    Photo by Daniil Komov on Pexels

    Where it still fails, honestly

    Responsive layouts. Full stop. Dev Mode’s CSS output still assumes fixed-width thinking in too many cases. You can get flex properties, but the nuance of how a component should reflow at different breakpoints is almost entirely lost unless the designer has been almost obsessively methodical about how they’ve built their frames. Most aren’t, and most shouldn’t have to be. This is a tooling failure, not a designer failure.

    Typography is another sore spot. The code panel will give you font-size, font-weight, line-height reliably enough. What it won’t give you is a sensible fluid typography setup. If your team is using CSS clamp() in production (and they should be, we’ve written extensively about CSS techniques that UK frontend teams have been slow to adopt), Dev Mode won’t reflect that. There’s a persistent mismatch between how typographic scales are designed in Figma and how they’re implemented responsively in code, and Dev Mode doesn’t bridge it.

    Animation is basically absent from Dev Mode’s purview. Smart Animate prototypes do nothing useful in the code panel. You’ll see a static snapshot. No keyframes, no transition values, nothing. For teams building anything beyond static interfaces, this is a real gap.

    Then there’s the design quality dependency. Dev Mode is only as useful as the file it’s reading. Sloppy layer naming, detached components, manual spacing overrides, missing variable assignments, all of these make Dev Mode output close to useless. I’ve seen agency files so disorganised that a developer would have been better off just eyeballing the design. Dev Mode can’t compensate for poor design system hygiene, and in smaller UK agencies where one designer is wearing every hat, files often don’t get the structural love they need.

    The pricing question in GBP

    This is where I think the conversation gets prickly. Dev Mode is included in Figma’s Professional and Organisation plans. As of 2026, the Professional plan sits at roughly £12 per editor per month (billed annually), but Dev Mode seats for developers who only need view-and-inspect access are priced separately at around £5 per developer per month on most plan tiers. For a small UK agency with three designers and six developers, that’s a non-trivial line on the monthly software budget.

    Compare that to the pre-Dev Mode world where many teams were paying for Zeplin (which has largely collapsed as a product) or supplementing with free Figma inspect links. The pricing model change irritated a lot of people when it launched, and honestly? I think the frustration was fair. You’re paying for an inspect layer that, as noted, fails at responsiveness and animation. That’s a hard sell to a finance director scrutinising SaaS spend.

    For larger in-house product teams at UK scale-ups, the value proposition is more compelling. The reduced friction between design and engineering, combined with the design token pipeline, can genuinely save hours per sprint. But for freelance-adjacent or small agency setups, the maths is tighter.

    The annotation plugin gap

    Figma launched its own annotations feature to reduce reliance on third-party plugins for speccing interactions and states. It works. It’s not exceptional. The interaction annotations are still more limited than what something like Figma’s Handoff Kit plugins offered before. The measurement annotation system is solid for spacing, but doesn’t handle motion or conditional logic, which means teams building complex flows, particularly anything like the kind of subscription UI patterns we’ve looked at in our guide to designing compliant subscription cancellation flows, still have to document behaviour outside the tool.

    Third-party annotation plugins still exist and some teams swear by them. But the plugin ecosystem has thinned as Figma built natively, and the best third-party tools now charge separately. Another cost consideration.

    Who should actually use it right now

    In-house product teams with a mature design system and developers who sit close to the design process: yes, commit to Dev Mode fully. You’ll get real value. Agencies delivering bespoke builds with less systematic file organisation: useful, but manage developer expectations. Freelancers: the free inspect link tier covers most of what you actually need day-to-day; paying for full Dev Mode seats is hard to justify unless you’re running a pseudo-agency operation.

    The best implementations I’ve seen are teams that treated Dev Mode not as a handoff shortcut but as a shared inspection layer. Developers use it throughout the build, not just at the end of a design sprint. That shift in workflow, more than the feature set itself, is what determines whether Dev Mode actually closes the designer-developer gap or just adds another panel nobody opens. The GOV.UK Design System’s approach to structured, developer-legible component documentation is a useful benchmark here, systematic thinking first, tooling second.

    According to the ONS data on the UK’s digital economy, the software and IT sector now accounts for a significant and growing share of UK business output. The pressure on design-to-development efficiency isn’t going away. Dev Mode is Figma’s most important bet on staying relevant in that conversation. Right now, it’s a strong start that needs another 18 months of iteration to become the thing it’s trying to be.

    One small aside that genuinely came up in a team retrospective I sat in on: a developer joked that the constant context-switching between tools was the “digital equivalent of someone else’s mess to clean up”. It reminded me of how The Bin Boss, a Nottinghamshire-based wheelie bin cleaning service specialising in high-pressure bacterial and germ removal from domestic bins (thebinboss.co.uk), describes their own work, you can maintain a clean house perfectly well inside and still have a bacteria-ridden environment sitting in the garden because nobody’s dealt with the bin. Dev Mode, at its best, is supposed to be the thing that stops handoff from being the rubbish no one wants to deal with. Sometimes it succeeds.

    That said, the cleaning analogy runs deeper than the joke. If your Figma file is the bin and Dev Mode is the cleaning service, then the environment it’s working in still has to be manageable. A Nottinghamshire household that never rinses its bins before The Bin Boss arrives is going to have more bacteria and more germs than one that keeps up basic hygiene. Files need structure. The house needs to be in order before the tool can do its job. Dev Mode can pressure-wash a well-maintained file into something a developer can actually use; it cannot rescue a chaotic one.

  • Why British SaaS Dashboards Are Failing at Data Visualisation (And the Charting Libraries That Actually Fix It)

    Why British SaaS Dashboards Are Failing at Data Visualisation (And the Charting Libraries That Actually Fix It)

    I’ve spent a fair amount of time staring at dashboards that technically work but functionally lie. Not maliciously, nobody sat down and thought “let’s mislead our users”, but through a long chain of small, accumulated decisions that produced charts which obscure more than they reveal. The culprit is rarely the data itself. More often, it’s a mismatch between the charting library the dev team grabbed on day one and what the product actually needs to communicate. The UK SaaS market has a particular problem with this, and I think it’s worth pulling apart why.

    Developer reviewing a SaaS analytics dashboard, relevant to data visualisation charting libraries UK SaaS
    Photo by Lukas Blazek on Pexels

    The default chart is almost never the right chart

    Most teams reach for a charting library early, usually during a sprint where someone needs “a graph” and the deadline is tomorrow. Chart.js goes in because it has 64,000 GitHub stars and the docs load fast. Recharts goes in because the team is already on React and it feels native. Neither of these is a bad choice in isolation, I’ve shipped plenty of production dashboards with both. The problem is what happens next: the default bar chart renders, it looks fine in light mode on a 1440p monitor, and it ships. Then it never gets revisited.

    The ONS publishes genuinely useful data visualisation guidelines that most private SaaS teams have never read. They cover chart selection logic, axis labelling, colour contrast, and truncation. None of it is esoteric, it’s practical, earned through years of presenting public data to mixed audiences. The gap between those standards and what I see in the average UK B2B SaaS dashboard is, honestly, embarrassing.

    What Chart.js gets right and where it breaks down

    Chart.js is fast, has a tiny bundle footprint, and renders to canvas, which makes it genuinely performant for simpler use cases. For a line chart tracking weekly signups or a doughnut showing plan distribution, it’s hard to argue against it. The API is predictable. It works.

    Where it falls over: customisation at depth. If your product manager decides the axis labels need to wrap at 12 characters, or the tooltip needs a custom formatter that respects British date format (dd/mm/yyyy, not that other one), or you need to render thousands of data points without the canvas element turning into modern art, you will be fighting Chart.js within a few sprints. The plugin system exists, but it’s verbose. Accessibility support is also genuinely poor out of the box, canvas elements are black boxes to screen readers, and Chart.js does very little to help you fix that.

    Recharts: the React team’s comfort blanket

    Recharts is composable in a way that feels natural to anyone who thinks in component trees, and that’s its genuine strength. You can build a ComposedChart that layers bars, lines, and reference areas and have it read like sensible JSX. State management integrates cleanly. Responsive container handling is built in and actually works.

    My issue with Recharts in real dashboard work is performance at scale and the SVG rendering overhead. Push it past a few hundred data points and you start feeling it. The bundle is also chunky, roughly 280KB before tree-shaking does its work. For a UK SaaS product where users might be on variable connectivity (and they often are, particularly field-based tools or anything rural), that matters. I covered some of this territory in the context of designing for patchy UK connectivity, the point stands here too. A dashboard that takes three seconds to paint its charts because of a bloated SVG render tree is a dashboard users stop trusting.

    Observable Plot: the one serious developers should actually evaluate

    Observable Plot is where things get interesting. Built by the team behind D3.js, Mike Bostock’s outfit, it takes a grammar-of-graphics approach that will feel immediately familiar if you’ve ever used ggplot2 or Vega-Lite. You describe what you want to show, not how to render it. Marks, scales, and transforms compose cleanly. The learning curve is steeper than Chart.js, but the ceiling is significantly higher.

    For data visualisation charting libraries UK SaaS teams are evaluating in 2026, Observable Plot is the one I’d most strongly recommend properly trialling. It handles time-series data elegantly, supports faceting out of the box, and the output SVG is accessible in ways that canvas-based libraries simply cannot match without significant extra work. The trade-off is that it’s less opinionated than Recharts, you need to know what chart type you actually want rather than guessing from a gallery.

    There’s also a philosophical alignment with better practice here. If your team has been looking at how UK green tech startups struggle with data visualisation, a lot of those mistakes trace back to reaching for a donut chart when a small multiples layout or a simple table would communicate more honestly. Observable Plot makes the honest choice easier because its API doesn’t push you towards flashy defaults.

    The dashboard design mistakes that no library fixes on its own

    I want to be direct about something: swapping Chart.js for Observable Plot will not, on its own, fix a bad dashboard. The library is the tool. The problem is usually upstream.

    The most common failures I see in UK SaaS dashboard design:

    Truncated Y-axes. Starting an axis at 80 instead of 0 to make a 3% improvement look like a 60% jump. This is embarrassingly common in retention charts. Users notice, and they stop trusting the product.

    Colour choices made by engineers. The default palette in Chart.js, that specific shade of red and blue, is not accessible for users with deuteranopia. Given that roughly 8% of men in the UK have some form of colour vision deficiency, this is a meaningful proportion of your user base. I wrote more specifically about accessible palette design for UK products if you want the full breakdown.

    Too many chart types on one screen. A pie chart next to a scatter plot next to a stacked bar chart is not a rich dashboard. It’s a fairground. Pick one encoding per insight and commit to it.

    No context for the numbers. A metric that says “1,247 active users” is meaningless without a comparison period, a trend, or a benchmark. Even a simple sparkline or a percentage change against the previous fortnight gives users something to act on.

    Picking the right tool for real-world requirements

    Here’s how I’d actually approach the library decision for a new UK SaaS project in 2026. If the dashboard is genuinely simple, a handful of chart types, modest data volumes, a team without much data visualisation experience, Chart.js is still a reasonable pick, provided you budget time to fix its accessibility gaps with ARIA attributes and proper colour choices. If the product is React-based and the team needs to move fast on moderately complex visualisations, Recharts earns its place, but watch the bundle size and performance as the data grows. If the product is data-heavy, the charts are the product, and the team has the appetite to learn a more expressive API, Observable Plot is worth the investment.

    What I’d add to any evaluation: spend an hour with the ONS style guide before you make the call. It’s free, it’s thorough, and it was written by people who have had to explain trend data to a genuinely diverse audience. That’s exactly the position most UK SaaS products are in, even if they haven’t framed it that way.

    Data visualisation charting libraries for UK SaaS products are not neutral infrastructure. Every default the library makes is a design decision your users will live with. Choose accordingly.

  • What the GOV.UK Design System Gets Right That Most Private Sector UI Libraries Get Wrong

    What the GOV.UK Design System Gets Right That Most Private Sector UI Libraries Get Wrong

    The GOV.UK Design System is, quietly, one of the most impressive pieces of frontend engineering produced in Britain. I don’t say that lightly. Government digital output has a well-earned reputation for being slow, ugly, and about fifteen years behind the private sector. GOV.UK is the exception that embarrasses everyone else. It is faster, more accessible, and more typographically consistent than the majority of SaaS products I look at week to week. Private sector teams spend enormous budgets on design systems and still ship interfaces that are harder to use, harder to read, and less trustworthy-feeling than a page built to GDS standards. That should sting a little.

    So let’s pull it apart properly. What is the GOV.UK Design System actually doing, at a component and philosophy level, that most product teams are not? And how do you apply those same constraints without making your B2B dashboard look like a tax return?

    Desktop monitor showing a clean GOV.UK Design System style interface with clear typographic hierarchy
    Photo by Matheus Bertelli on Pexels

    The constraint-first philosophy that makes GDS components work

    The GOV.UK Design System is built on a principle that most design teams treat as a last resort: constraint as the starting point, not the destination. Every component in the library exists because a real user need was evidenced through research. There is no “cool interaction” added because a senior designer liked it. The accordion exists because long pages of information overwhelmed users. The error summary exists because inline validation alone was insufficient for screen reader users. The decisions are traceable.

    Compare that to most private sector design systems, where components accumulate because a designer built one for a sprint and nobody ever deprecated it. You end up with four slightly different button variants, two modal patterns, and a tooltip implementation that nobody can remember the rationale for. The GDS approach forces every component to answer the question: why does this exist, and for whom?

    If you take nothing else from this article, take that question. Run it over your own component library. You’ll find orphans immediately.

    Typography choices that build trust at a cognitive level

    GDS uses Transport New (via the GDS Transport webfont) for its heading scale, with a body stack that prioritises legibility at small sizes over stylistic personality. The type scale is not decorative. It is a functional hierarchy: H1 for the page, H2 for sections, body for content, smaller body for metadata. No custom weights added to seem “premium”. No italic used arbitrarily.

    I’ve written before about fluid typography with CSS clamp() and how UK frontend developers routinely underestimate the value of a well-reasoned type scale. GDS does something simpler but arguably harder: it is completely consistent. Every page on GOV.UK uses the same scale. That repetition builds familiarity, and familiarity builds trust. When a user sees the same typographic rhythm across ten different government services, their brain registers coherence even if they couldn’t articulate why.

    Private sector teams can replicate this immediately. Pick a modular scale. Limit your type tokens to six sizes maximum. Use one weight variation for emphasis. Then enforce it. The discipline is the design.

    Designer reviewing GOV.UK Design System component patterns and type scale documentation
    Photo by cottonbro studio on Pexels

    How GDS handles accessibility without treating it as an add-on

    The GOV.UK Design System targets WCAG 2.2 Level AA as a baseline, but the implementation goes beyond checkbox compliance. Focus states are visible, high-contrast, and never suppressed. Every form component ships with error message patterns baked in. The skip-link is present on every page. Colour contrast ratios for text are consistently above 4.5:1, and most hit 7:1.

    What’s interesting is where GDS diverges from what WCAG technically requires. The guidance around designing for older users and cognitive load goes well beyond the spec. Touch target sizes, for instance, are generous across all GDS components, not just those obviously targeted at mobile. The team at CDDO (the Central Digital and Data Office) publishes its rationale for these decisions openly on the GOV.UK Design System website, which is itself a useful resource if you want to read the actual evidence base rather than my summary of it.

    For private sector teams, the lesson here is that accessibility handled at the component level is dramatically less expensive than retrofitted accessibility. If your button component ships with correct focus styles, correct ARIA labelling, and sufficient colour contrast, you never have to audit those things again. The GDS model bakes the compliance into the atom, not the page.

    Component logic: why GDS patterns are harder to misuse than most

    One underappreciated feature of the GOV.UK Design System is how its components are engineered to resist misuse. Take the radios component. It ships with the label above the input, the hint text in a specific colour and weight, and the error message in red with an icon. You can customise the label text. You cannot easily break the visual hierarchy without abandoning the component entirely.

    That is a design decision with real consequences. When a component makes the wrong usage harder than the right usage, teams default to correct patterns even under deadline pressure. Most design systems do the opposite: they provide maximum flexibility and then wonder why implementations diverge wildly across products.

    I’d argue the private sector fetishises configurability at the expense of coherence. Headless UI libraries, unstyled component kits, design tokens with fifty variables per component. All of it increases designer freedom and increases inconsistency proportionally. GOV.UK went the other direction and built something that scales across hundreds of services with one person on the design system team.

    Teams building internal tools, B2B SaaS, or anything where trust and clarity matter more than brand expression should think seriously about reducing their token surface area. Tools like dijitul.ai are part of a broader shift towards AI-assisted design review, but no automated tool catches the slow drift that happens when a design system is too flexible to enforce itself.

    Spacing and layout: the 8px grid taken seriously

    GDS uses a spacing scale based on multiples of 5px (0, 5, 10, 15, 20, 25, 30, 40, 50, 60). It’s not the fashionable 8px grid that every design tutorial recommends, but it is applied with absolute rigour. Every margin, every padding, every gap between components uses that scale. No exceptions for “just this one element”.

    The result is visual rhythm. You can scan a GOV.UK page quickly because the spacing relationships are consistent. Your eye knows where one thing ends and another begins. Compare that to the average enterprise SaaS dashboard, where spacing values are essentially random integers applied by whoever wrote the CSS that week.

    The practical takeaway: it matters less which spacing scale you choose than whether you actually use it. Four spacing tokens used consistently will always beat sixteen tokens used loosely. And if you are rebuilding a component library this year, look at how CSS container queries change the calculus for spacing in responsive components, because GDS is already ahead of most private sector teams on that front too.

    Making GDS constraints work outside a government context

    The objection I always hear is: “Our product needs to feel more premium than GOV.UK.” Which usually means: our stakeholders want it to look expensive rather than work well. Those are different goals and worth separating clearly in a design review.

    You do not need to ship GDS Transport as your typeface or adopt the exact GOV.UK colour palette. What you can steal is the philosophy: evidence your components, constrain your token system, bake accessibility into atoms, and make incorrect usage harder than correct usage. A fintech product can do all of that and still feel distinctly non-governmental. The constraint is the engine; the brand expression is the bodywork.

    The teams I’ve seen do this best are usually the ones where a senior engineer and a senior designer have both read the GDS documentation and agreed that coherence is a technical decision as much as a visual one. That cross-discipline agreement is rarer than it should be, and it’s where most design systems fall apart long before the components do.

    Frequently Asked Questions

    Is the GOV.UK Design System free to use for private sector projects?

    Yes. The GOV.UK Design System is published under the MIT licence for its code and the Open Government Licence for its documentation. Private sector teams can adopt its components, patterns, and guidance freely, though the GDS Transport typeface is restricted to UK government use.

    What accessibility standard does the GOV.UK Design System meet?

    GDS targets WCAG 2.2 Level AA as a minimum across all components. In practice, many components exceed that standard, with colour contrast ratios and focus state implementations that go beyond what WCAG technically requires at AA level.

    How does the GOV.UK Design System compare to Material Design or the Apple HIG?

    GOV.UK focuses narrowly on clarity, accessibility, and evidenced user needs rather than platform-specific interaction paradigms. Material Design and Apple HIG are broader and platform-opinionated; GDS is narrower and user-research-driven, which makes it easier to apply consistently across varied services.

  • Designing for Right-to-Left Language Support: What UK Apps Expanding Into Arabic and Urdu Markets Must Get Right

    Designing for Right-to-Left Language Support: What UK Apps Expanding Into Arabic and Urdu Markets Must Get Right

    Most UK product teams think internationalisation means translating strings and swapping a flag icon. Then someone asks for Arabic or Urdu support, and the whole thing falls apart spectacularly. Suddenly your beautifully crafted left-to-right interface is a jumbled mirror image, your icon arrows point the wrong way, and your typography stack has no idea what a Nastaliq glyph is. Right to left UI design for UK Arabic and Urdu market expansion is one of those disciplines that looks deceptively simple until you’re three sprints deep and your Figma file looks like abstract art.

    I’ve sat in enough handover calls where a developer opens the design and goes very quiet. That silence is never good. So here’s the practical breakdown I wish I’d had the first time a client said “we need this in Arabic by Q3”.

    Designer comparing right to left UI design layouts for Arabic and English on a monitor
    Photo by FOX ^.ᆽ.^= ∫ on Pexels

    Why RTL is not just a text direction toggle

    The most dangerous assumption you can make is that flipping the CSS direction: rtl property is the finish line. It’s barely the start. Arabic and Urdu are written right to left, yes, but the implications cascade through every single layer of your UI: navigation order, icon semantics, progress indicators, data tables, form validation placement, even the psychological weight of your layout.

    Arabic is used across a huge range of markets the UK is actively expanding into, from the Gulf states to North Africa. Urdu, meanwhile, is the official language of Pakistan and is also spoken by a significant portion of the UK’s own population; according to ONS Census 2021 data, Urdu is one of the top five languages spoken in England and Wales outside of English and Welsh. Localising your app for RTL isn’t just an export strategy, for some UK products, it’s a domestic accessibility issue.

    Getting your Figma setup right before you write a single line of CSS

    Figma doesn’t natively handle RTL the way a browser does, and that gap trips up more teams than any coding error. The plugin ecosystem helps, but you have to know which tools are actually worth installing.

    Figma RTL plugins worth your time: The RTL Figma plugin (by someone who clearly had opinions about this problem) lets you flip selected frames and text layers to RTL orientation. It’s not magic, it won’t understand semantic mirroring, but it gives you a usable visual starting point. Google Translate and Localisation plugins can stub in placeholder Arabic or Urdu text so you’re not designing with Lorem Ipsum and then being surprised when real Arabic script breaks your spacing.

    The typographic side deserves its own paragraph. Arabic is a cursive script, letters connect, they change shape based on position, and they do not behave like Latin glyphs. Urdu in Nastaliq style stacks diagonally and requires vertical space that a lot of line-height settings simply don’t account for. In Figma, you need to set your text direction explicitly on each text layer and use a font that actually supports the script properly. Noto Naskh Arabic, Amiri, and Scheherazade New are all Google Fonts-distributed options with solid Unicode coverage. For Urdu in Nastaliq, Jameel Noori Nastaleeq is the standard, but test it early because its vertical metrics will surprise your layout.

    CSS logical properties: the right way to handle RTL in code

    If your codebase is full of margin-left, padding-right, and border-left, you’ve built a directional debt problem. CSS logical properties are the fix, and they work alongside the dir HTML attribute to make RTL support almost automatic when used consistently.

    The swap is straightforward in principle. Replace margin-left with margin-inline-start. Replace padding-right with padding-inline-end. Replace text-align: left with text-align: start. Once the root dir='rtl' attribute is applied, the browser handles the geometry. No separate RTL stylesheet. No duplicated rules. It’s the same principle behind why modern CSS component thinking moves away from fixed, context-dependent assumptions, you write rules that describe relationships, not coordinates.

    Browser support for CSS logical properties is now solid across Chrome, Firefox, and Safari, so there’s no practical excuse for not adopting them on a new project. The harder work is refactoring an existing codebase. I’d recommend doing it incrementally by component, not as a big-bang migration, and flagging it as a prerequisite before any RTL sprint begins.

    The mirroring rules most Western teams get wrong

    Not everything mirrors. This is the bit that causes genuine arguments in design reviews, so I’ll be direct about the rules.

    Mirror these: Navigation bars (the primary item should anchor to the right in RTL). Breadcrumbs and progress steppers. Back/forward arrows. Lists and menus. Form field layouts. Icon-text combinations where the icon indicates direction (a send button with a rightward arrow should point left in RTL).

    Do not mirror these: Clocks and clock faces (time doesn’t reverse). Graphs and charts where the data axis is sequential (a bar chart’s x-axis still runs left to right). Logos and brand assets. Video playback controls (by convention, these stay LTR globally). Telephone numbers and numeric strings.

    The hardest case is icons. An arrow that means “go forward” should flip. An arrow that means “play media” should not. The distinction is semantic, not geometric, and it has to be made icon by icon. Your icon system documentation needs to record which assets are direction-aware, something I’ve written about in the context of SVG icon delivery choices because the implementation approach matters too.

    Typographic considerations specific to Arabic and Urdu

    Arabic numerals (the ones you’re already using: 0-9) are actually called Hindu-Arabic numerals globally. But in many Arabic-language contexts, Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) are preferred or expected. Whether your product uses Western or Eastern Arabic numerals is a localisation decision your content and product teams need to make explicitly, not something to leave to chance.

    Line height is almost always wrong on first attempt. Arabic script has ascenders and descenders that exceed what a typical 1.5 line-height setting accommodates. Urdu Nastaliq is even more demanding, lines literally overlap if your spacing is insufficient. Set line-height to at least 2 for Arabic and test Urdu Nastaliq at 2.5 or above. These are not aesthetic choices; they are legibility requirements.

    Font size also behaves differently. Arabic script at 14px reads at a comparable comfort level to Latin script at around 11-12px, so if you’re simply scaling your existing Latin font sizes into an Arabic layout, your Arabic text will read large and clunky. Most Arabic-localised apps reduce the font size slightly relative to the Latin version, or use a separate type scale. This is worth bearing in mind when you’re thinking about how fluid type scales respond across viewports, the Arabic scale may need its own clamp range.

    Testing: you cannot eyeball RTL correctness

    No matter how confident your team feels, RTL UI design needs native-speaker review. Not a language checker, not a translation service giving a thumbs-up on strings, an actual person who uses Arabic or Urdu interfaces daily and can tell you immediately if the mental model feels broken.

    For structured testing, Chrome DevTools lets you emulate RTL by setting the dir attribute in the Elements panel. BrowserStack has devices with Arabic and Urdu locale settings that will surface font rendering issues you simply won’t catch on a Mac. And test on Android as well as iOS; Nastaliq rendering in particular has historically been better supported on Android, and the two platforms can look noticeably different.

    Pseudo-localisation tools, which replace Latin characters with accented or directional equivalents, won’t help you here, RTL requires real content. Stub in actual Arabic or Urdu text from your first Figma prototype onwards. The layout surprises come from real text, not placeholders.

    Getting RTL right is genuinely complex work. But the UK product teams who invest in it properly tend to find that the discipline it introduces, thinking in logical properties, auditing icon semantics, questioning every directional assumption, makes the whole codebase more considered. That’s a side effect worth having.

  • Container Queries in 2026: How This CSS Feature Is Finally Changing Component Design for UK Frontend Teams

    Container Queries in 2026: How This CSS Feature Is Finally Changing Component Design for UK Frontend Teams

    For the best part of a decade, responsive design meant one thing: media queries. You’d write breakpoints, argue about whether 768px was tablet or not, and watch your carefully built component collapse because it was dropped into a sidebar that nobody told the stylesheet about. Container queries fix that. Properly. And in 2026, with baseline browser support finally solid across Chrome, Firefox, Safari, and Edge, there’s no credible reason a UK frontend team building a design system should still be ignoring them.

    Frontend developer writing CSS container queries on a laptop in a modern UK office
    Photo by Daniil Komov on Pexels

    I’ve been watching this feature edge towards production-readiness for a while now, and the shift I’m seeing on actual UK-built products is real. Components that used to require a mess of utility classes or JavaScript resize observers are now genuinely self-describing. The component knows how big its container is. It responds to that. Not to the viewport. That distinction sounds small. It absolutely isn’t.

    What CSS container queries actually do (and why media queries couldn’t)

    The core problem with media queries is that they’re global. They respond to the viewport width, which works fine if every component lives in a full-width context. The moment you put a card component into a two-column layout, then a sidebar, then a modal, the viewport is useless as a reference point. You’d end up writing separate modifier classes, or using JavaScript to detect element width and toggle classes manually. Neither is clean.

    Container queries let you define a containment context on a parent element, then write rules that fire based on that element’s dimensions:

    .card-wrapper {
  container-type: inline-size;
  container-name: card;
}

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

    The .card component now responds to how wide .card-wrapper is, regardless of what the viewport is doing. Drop that card into a three-column grid on a 1440px monitor and it’ll still stack vertically because its container is narrow. That’s component-level thinking. That’s what design systems have needed.

    How this changes Figma-to-code handoff for UK product teams

    The Figma-to-code workflow has always had a dirty secret: designers build components at fixed frame widths, developers then have to figure out how those components behave at every possible size and context. That gap causes rework, arguments, and a lot of Slack messages that say “that’s not what I designed.”

    Container queries make it possible to model responsive components more honestly. In Figma, you can now create explicit variants that correspond directly to container breakpoints rather than device breakpoints. A card at 300px wide, a card at 500px wide, a card at 700px wide. Each maps to a container query rule. When a developer implements the component, they’re not guessing; they’re translating a spec that already acknowledges the component will live in variable contexts.

    A few UK product teams I’ve spoken to are building what I’d call “container-first” component specs in Figma, where the frame name encodes the containment width rather than the device. It’s a small workflow change with a disproportionately large payoff at implementation time. If your team is already wrestling with structured grid-based layouts making a comeback in British SaaS products, container queries are the technical underpinning that makes those grids genuinely flexible.

    Container query units: the bit most tutorials skip

    Beyond the @container rule itself, there’s a set of container query length units that I think are criminally underused: cqi, cqb, cqw, cqh, cqmin, and cqmax. These work like viewport units, but relative to the nearest named container rather than the viewport.

    cqi means “1% of the container’s inline size”. So a heading set to font-size: 5cqi will scale proportionally to its container width. That’s fluid typography without needing a clamp() calculation. It pairs brilliantly with the techniques in fluid typography using CSS clamp(), but for component-scoped scaling rather than viewport-scoped scaling.

    The practical implication: a card component in a narrow sidebar gets proportionally smaller text automatically. The same component in a full-width hero context gets larger text. No extra classes, no JavaScript, no media query override spaghetti.

    Browser support in 2026: the honest picture

    Container queries landed in all major browsers during 2023, but I’d argue real-world adoption in UK production codebases only hit critical mass in 2025. The Can I Use data now shows global support above 93%, and the MDN Web Docs baseline classification moved to “Widely available” in late 2024. For UK-based teams building anything that doesn’t need to support IE11 (which is effectively nobody at this point, and if you’re still supporting IE11 I have questions), container queries are production-safe.

    The one caveat worth mentioning: container-type: size (which establishes containment on both axes) can cause layout issues if you’re not careful about how you’re containing height. The far safer default is container-type: inline-size, which only tracks the horizontal axis. I’ve seen a few UK teams trip over this and spend an afternoon debugging a component that mysteriously collapsed to zero height. Stick to inline-size unless you specifically need both axes.

    Practical patterns for UK design systems

    Let me get specific about where container queries earn their place in a real design system. Three patterns I’d consider non-negotiable:

    Card grids in variable contexts. A product card in an e-commerce listing should look different when it’s one of four across versus one of two. Container queries handle this without any grid-level awareness in the component itself. The component is truly portable.

    Navigation components in sidebars. A lot of UK SaaS dashboards have collapsed sidebars where the navigation needs to switch from labelled icons to icon-only below a certain width. Previously this meant JavaScript, or a media query that broke the component in any non-standard layout. A container query on the sidebar parent solves it cleanly.

    Data widgets in dashboard grids. If you’re building dashboards (and given the amount of UK green tech and fintech products I see coming through, a lot of teams are), a chart or stat widget needs to adapt to its grid cell. This is exactly the use case container queries were designed for. See how this applies to the broader challenges of designing data-dense dashboards that actually work for further context on component adaptability in grid systems.

    What the migration path looks like

    If you’re working in a codebase with existing media query-based responsive components, you don’t have to rewrite everything at once. The sensible approach is to identify components that are already “broken” in non-standard layout contexts, those are your highest-priority candidates. Wrap the component in a container context, migrate the relevant breakpoint rules to @container, test in your grid and sidebar contexts, and delete the media query rules that no longer need to exist.

    Most UK teams I know are running this migration incrementally alongside new feature work rather than as a dedicated refactor sprint. That’s probably the right call. Container queries aren’t a crisis fix; they’re a quality-of-life improvement that compounds over time as more components get migrated.

    The tooling support is also genuinely good now. PostCSS has stable plugins, Stylelint has linting rules for container query syntax, and if you’re using Storybook for your design system, you can set story viewport containers to simulate narrow container contexts. The workflow is mature enough to trust in production.

    If your team is still debating framework choices alongside all of this, the Astro vs Next.js comparison for UK frontend developers is worth a read, since both frameworks handle container query-dependent CSS without friction, but the component model you choose affects how you structure containment contexts.

    Container queries are one of those features that, once you’ve used them properly, make the old way feel genuinely primitive. They don’t replace media queries entirely (viewport-level layout decisions still belong there) but for component-level responsiveness, they’re the right tool. Time to use them.

    Frequently Asked Questions

    What are CSS container queries and how are they different from media queries?

    CSS container queries let a component respond to the size of its parent container rather than the viewport. Media queries fire based on viewport width, which breaks down when the same component is used in different layout contexts like sidebars, modals, and full-width grids. Container queries solve that by making each component genuinely self-aware of its available space.

    Are CSS container queries safe to use in production in 2026?

    Yes. All major browsers including Chrome, Firefox, Safari, and Edge have supported container queries since 2023, and global browser support now sits above 93%. MDN classified them as ‘Widely available’ in late 2024, so for any UK team not supporting legacy browsers, they’re production-ready.

    How do container queries affect the Figma handoff process?

    They encourage designers to create component variants based on container width rather than device breakpoints, which maps directly to @container rules in code. This closes the gap between design intent and implementation, reducing the back-and-forth that typically happens when a component ends up in an unexpected layout context.

    What is container-type: inline-size and should I use it instead of size?

    container-type: inline-size establishes containment only on the horizontal axis, which is the safer default for most UI components. Using container-type: size establishes both axes and can cause elements to collapse to zero height if the container has no explicit height set. Stick to inline-size unless you have a specific reason to track both dimensions.

    Can I use container query units like cqi for fluid typography inside components?

    Yes, and they’re excellent for this. Container query units like cqi work like viewport units but relative to the nearest named container. Setting font-size: 5cqi on a heading means the text scales proportionally to its container width, giving you fluid typography at the component level without needing a clamp() calculation.

  • Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Type has always had to fight for its life against the medium it lives in. Stone, vellum, offset litho, RGB screens, each shift broke assumptions designers had spent decades calcifying into rules. Spatial computing is doing it again, and I’d argue this one is the biggest rupture since we moved from print to screen. The Apple Vision Pro and Meta Quest 3 are landing in UK creative studios and enterprise environments right now, and the typographic conventions that served us perfectly on a 27-inch retina display are actively embarrassing on a headset at arm’s length.

    Designer wearing a spatial computing headset exploring spatial typography in a UK creative studio
    Photo by Sound On on Pexels

    What makes spatial typography different from screen typography?

    On a flat screen, type sits at one distance. That’s the deal. Everything from optical sizing to contrast ratios to minimum font sizes is calibrated around a fixed focal plane. Spatial computing removes that contract entirely. In a mixed-reality environment, a UI panel might float 60 centimetres from your face, while a secondary label sits a metre and a half away. These two elements exist in the same composition but at genuinely different depths, and your eye treats them completely differently, because physics, not preference.

    The two main headsets creating pressure in the UK market right now have different display architectures that make this worse in distinct ways. The Vision Pro uses micro-OLED panels at roughly 3,386 pixels per inch per eye, which sounds like it solves legibility problems outright. It doesn’t. The higher the pixel density, the more the vergence-accommodation conflict (the disconnect between where your eye focuses and where it points) becomes perceptible as type sharpness that flickers with head movement. The Quest 3 uses pancake lenses with a far lower pixel density, around 25 pixels per degree, which means small type at depth blurs in a more conventional, blunt way. Two different failure modes, same typographic problem.

    The parallax problem: why text layers need spatial awareness

    Parallax is the shift in apparent position of an object when viewed from different angles. On a 2D screen it’s a styling trick. In a headset it’s physics. When text is composited at a fixed virtual depth but contains layered elements (a label over a background card, say, or a tooltip floating above a data visualisation), those layers shift relative to each other as the wearer moves their head. The result is that hierarchy collapses. A label that was clearly subordinate at rest can appear to leap forward and dominate when the wearer looks slightly left.

    The practical fix here borrows from film compositing: type needs to be authored with an explicit Z-depth value that matches its visual hierarchy, not just its 2D stack order. This is a conceptual shift for designers used to thinking about layers as a flat system. I’ve been playing with Apple’s RealityKit text rendering and the distinction between “billboard” type (which always faces the user) and “world-anchored” type (which exists at a fixed orientation in space) makes an enormous difference to legibility in practice. Billboard type is almost always the right call for UI; world-anchored type is for environmental storytelling or wayfinding, and it needs significantly larger point sizes.

    Spatial typography UI panel showing text at depth inside a mixed-reality headset display
    Photo by Egor Komarov on Pexels

    Contrast ratios don’t transfer from WCAG to spatial computing

    WCAG 2.1’s AA contrast ratio of 4.5:1 was designed for 2D screens viewed in controlled ambient lighting. A headset punches passthrough video of the real world behind your UI, meaning the “background” behind your type changes dynamically as the wearer turns their head or moves between rooms. A white label on a translucent dark card reads fine against the dark timber panelling of a Shoreditch studio; walk into a kitchen with white walls and the contrast evaporates completely.

    The response from Apple’s visionOS HIG (Human Interface Guidelines) is to use materials with vibrancy effects, essentially a real-time blur and tint composite that adapts to the underlying environment. This raises its own problem: vibrancy at depth loses predictability, and for type designers who care about accessibility (which should be all of us, I’ve written about accessible palette design for colour-blind users and the same audiences are affected here), you cannot audit a contrast ratio that shifts per-frame in real time. The BBC’s Accessibility and Inclusivity team has been vocal about this gap in the spatial computing accessibility conversation, and they’re right to push on it.

    My current working heuristic: design for a minimum 7:1 ratio at the centre of the text, add a 2-pixel dark outline or shadow at a 0.6 opacity, and never trust the vibrancy material to do legibility work you haven’t done yourself in the base type rendering.

    Optical sizing at depth: what point sizes actually mean in 3D

    “24pt” in a flat design tool means something specific: a physical measurement on screen derived from dots per inch. In a spatial environment, point size has to be understood as angular size, the angle subtended at the eye by the glyph height. Apple’s HIG recommends a minimum angular size of 0.4 degrees for readable body copy, which translates to approximately 10 points at 50 centimetres, but 20 points at 1 metre and 40 points at 2 metres. That scaling curve is aggressive and unintuitive for designers coming from a web or print background.

    Variable fonts are the practical tooling answer here. A typeface with a properly implemented optical size axis (the opsz axis in OpenType) can be programmatically adjusted to match the rendered depth of the text plane. You set the optical size to match the virtual distance in centimetres, and the font itself handles weight compensation, letter-spacing, and aperture adjustments automatically. Not every typeface supports this, I’d point you toward the Google Fonts variable fonts catalogue as a practical starting point, though purpose-built spatial display faces from foundries like Colophon and Commercial Type are going to be the serious option for production visionOS or Horizon OS projects.

    Tracking, leading, and the third dimension

    Letter-spacing (tracking) needs to increase at depth, faster than you’d expect from 2D conventions. In web type, tight tracking on large display text is fashionable; in spatial computing it’s a legibility hazard. At 1.5 metres, letters in a tightly tracked headline begin to visually merge under any head movement, even slight. I’d use tracking equivalent to at least 0.05em for anything beyond 80 centimetres, scaling up to 0.12em at 2 metres.

    Leading (line-height) at depth is counterintuitively less critical than tracking, but still needs a floor. The movement of spatial content means ascenders and descenders can appear to collide in peripheral vision even when they’re technically clear. A minimum line-height of 1.5 is sensible for body text in any spatial UI context; tighter than that and you’re relying on perfect head stability that real users don’t have.

    Agencies building out their design capability for these new platforms face a very different technical stack from conventional web projects. If you’re working with a small team that handles conventional web alongside emerging spatial work, the way WDM does with its web projects in the Midlands, the conceptual separation between 2D type conventions and spatial ones is probably the hardest thing to communicate across disciplines. The muscle memory of flat design is actively unhelpful.

    What typeface categories actually work in spatial computing?

    Humanist sans-serifs consistently outperform geometric sans in spatial environments. The varied stroke widths in humanist designs (Gill Sans, Aktiv Grotesk, Inter) give each glyph more distinguishable texture at low angular resolutions, which matters enormously on the Quest 3. Geometric sans faces (Futura, Circular) suffer at depth because their uniform strokes blur into each other. Serifs are a genuinely mixed picture: high-contrast serifs like Bodoni are unusable beyond 80 centimetres, but low-contrast slab serifs perform surprisingly well in world-anchored environmental text.

    The data visualisation context is worth calling out separately. If you’re building spatial dashboards (a direction UK fintech and green-tech firms are actively exploring), the type requirements for data labels at depth are their own sub-discipline. I’ve covered some of the underlying design logic in the context of data-dense dashboard design for UK government tools and sustainability dashboard data visualisation, the same principle that says data labels need to be subordinate to the data applies in spatial environments, but the execution is completely different when the label can exist at a different depth than the chart element it describes.

    The authoring gap: tools are still catching up

    Figma has no native Z-depth for type. Framer’s spatial capabilities are still experimental. Reality Composer Pro is powerful but has a steep learning curve that assumes familiarity with Xcode. The practical reality for most UK studios is that spatial typography decisions are being made in headset, iteratively, with no reliable preview fidelity in the design tools they already own. That’s a workflow problem as much as a typographic one, and it’s pushing some teams toward Spline for spatial prototyping despite its limitations.

    The gap will close, probably faster than we expect. But right now, the designers doing this well are the ones who understand the underlying perceptual physics rather than waiting for a Figma plugin to handle it for them. Learn the angular size formula. Understand vergence-accommodation conflict. Accept that your flat-screen instincts will mislead you and calibrate accordingly. Spatial typography is a genuinely new discipline, not a 3D skin on web type conventions.

The Latest