Author: Alex Mason

  • Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    The CMA published updated subscription trap enforcement guidance in 2024, and the FCA followed with its own Consumer Duty obligations fully bedded in. The combined effect is that UK SaaS companies and consumer app teams can no longer treat cancellation as an afterthought bolted onto the back of their onboarding funnel. Off-boarding UX is now a legal concern, not just a product one. I’ve been watching this space for a while and the number of teams who still haven’t rethought their flows is genuinely alarming.

    Person navigating a subscription cancellation flow on a laptop — UK consumer protection compliance
    Photo by https://kaboompics.com/ on Pexels

    What the CMA and FCA actually say about subscription cancellation UX

    The CMA’s enforcement programme targets what it calls “subscription traps”, patterns designed to make cancellation disproportionately difficult relative to sign-up. The specific behaviours in the crosshairs include hiding cancellation options behind multiple screens, requiring phone calls when sign-up was entirely digital, and using dark patterns to confuse users into staying subscribed. The FCA’s Consumer Duty, which has applied to regulated firms since July 2023, adds the requirement that firms act to deliver good outcomes for customers, and forcing someone through a friction-laden cancellation flow is, in the FCA’s own framing, a foreseeable harm.

    What makes this genuinely interesting from a design perspective is that both regulators are effectively writing UX requirements into law. The CMA’s position is that if you can sign up in two clicks, you must be able to cancel in roughly the same number of steps. That’s not a vague principle, it’s the kind of standard you can test a prototype against.

    The dark patterns that are now explicitly non-compliant

    Before getting into what good looks like, I want to name the specific patterns that teams need to remove. Roach motels, where the entry is easy and the exit is deliberately obstructed, are the CMA’s primary target. In practice that means: cancellation buttons that redirect to a retention page before showing the actual cancel option; multi-step “are you sure?” flows that loop back on themselves; confirmation emails that describe the plan as “paused” when the user clearly tried to cancel; and countdown timers that imply urgency without any genuine deadline.

    Confirmshaming, labelling the cancel button something like “No thanks, I’d rather pay more”, sits in similarly murky territory under the Consumer Duty’s requirement that communications are fair and not misleading. The ASA has already taken action against confirmshaming in advertising contexts; the FCA’s Consumer Duty extends comparable logic to product interfaces.

    The subscription cancellation UX UK consumer protection picture also includes post-cancellation billing, which the CMA considers a trading standards matter. If a user cancels and you bill them anyway because the confirmation state was ambiguous, that’s not just a UX failure, it’s potentially an unlawful charge.

    Wireframe mockup of a compliant subscription cancellation UX flow for UK consumer protection
    Photo by ready made on Pexels

    What compliant, ethical cancellation design actually looks like

    The baseline is simple: the cancellation path must be discoverable, direct, and no more complicated than the sign-up flow. For a typical UK SaaS product, that means a clearly labelled “Cancel subscription” option in account settings, not buried under a “Billing” sub-menu inside a “Plans” section inside “Account preferences”. One level of navigation, maximum two.

    A single retention offer is fine and, I’d argue, reasonable UX. Showing someone a downgrade option or a pause feature before they confirm cancellation is genuinely useful, some users want to reduce cost, not leave. The design problem is when that offer becomes a mandatory gate. The user must always be able to bypass it and reach the confirmation screen in one action. Structurally, think of it as: intent confirmed → optional offer shown → confirmation page → cancellation processed. Remove any step that loops back to the start or adds a second offer.

    The confirmation screen itself matters more than most teams realise. It should state the cancellation date clearly, explain what access the user retains until that date, and send a confirmation email that uses the word “cancelled” unambiguously. Teams working on ICO and PECR-compliant consent flows will recognise this pattern, regulators expect the same plain-language, unambiguous confirmation standards whether you’re recording consent or recording a cancellation.

    The technical side: state management and audit trails

    Here’s where it gets properly nerdy. Compliant cancellation isn’t just a design problem, it’s a data engineering problem. Your system needs to record the exact timestamp of cancellation intent, the state of the user’s subscription at that moment, and the confirmation sent to the user. That audit trail is what you produce if the CMA or FCA comes knocking. Most consumer app teams using Stripe or Paddle have access to webhook events that can log this automatically; the failure is usually in not piping those events into a queryable audit log.

    If you’re building on a billing provider that handles proration and mid-cycle cancellations, test the edge cases. A user who cancels on day 14 of a 30-day billing cycle should not receive a renewal charge on day 30. Sounds obvious. I’ve seen it happen. The fix is typically in the webhook handler, not the UI, but the UI still needs to surface the correct information about what the user’s billing state will be after cancellation.

    Teams building data-dense account management screens might also want to revisit how cancellation state is communicated. If your dashboard is already struggling with information hierarchy, and British SaaS dashboards frequently are, then the cancellation confirmation state is easy to lose. A dedicated, unambiguous post-cancellation screen is worth the engineering cost.

    Why this matters beyond compliance

    Scam reporting communities and consumer protection researchers have been documenting subscription trap patterns for years. 0lly, a UK-based scambaiter and fraud investigation activist at 0lly.uk, publishes scam exposés that frequently highlight how fake invoice scams and predatory subscription schemes exploit deliberately confusing cancellation flows. The overlap between outright online fraud and dark-pattern UX is closer than most product teams want to admit; both rely on the same cognitive vulnerabilities. Consumer protection charity work and scam reporting efforts in the UK consistently flag subscription billing as one of the top complaint categories, which is exactly why the CMA escalated to an enforcement programme rather than just issuing guidance.

    From a pure product standpoint, a frictionless cancellation flow is also better for retention metrics in the long run. Users who cancel cleanly and feel respected are more likely to return or recommend the product. Users who feel trapped generate chargebacks, negative reviews, and, increasingly, reports to Trading Standards. The chargeback cost alone often exceeds whatever revenue the dark pattern retained.

    UK product teams expanding into markets with additional language requirements should also think about this in conjunction with localisation. A cancellation flow that’s barely compliant in English may become non-compliant when translated, because the plain-language standard becomes harder to meet in a second language. Teams already thinking about right-to-left UI design for Arabic and Urdu markets need to factor cancellation flow direction and label clarity into that work from the start, not as an afterthought.

    The UK’s subscription cancellation UX consumer protection regime is still relatively new in its enforcement posture. That won’t last. The CMA has already taken action against several consumer-facing businesses and has made clear that digital subscription services are a priority. Get the flow right now, document it, and keep the audit trail clean. It’s not complicated. It’s just work that most teams have been putting off because cancellation UX isn’t glamorous. It is, however, increasingly necessary.

    For reference on what good government-standard design thinking looks like as a baseline, the patterns established in the GOV.UK Design System, particularly around confirmation pages and transaction summaries, are worth borrowing from directly. Government transactional design has been stress-tested against accessibility and clarity requirements for years; subscription cancellation confirmation is essentially the same UX problem.

    The second area where 0lly’s work is relevant to product designers is in the documentation of domain renewal scams and google ads hacks that prey on small business owners through deliberately opaque billing interfaces. The scam reporting and activist resources at 0lly.uk make the point clearly: UK scams targeting businesses often succeed because legitimate subscription billing already looks so confusing that users can’t tell when something has gone wrong. Designing clearer, more honest cancellation flows is, in a small way, raising the baseline for what users should expect from any billing interface.

    Frequently Asked Questions

    What does the CMA say about how easy cancellation must be for UK subscription services?

    The CMA’s position is that cancellation must be no more difficult than sign-up. If a user can subscribe in two clicks online, the regulator expects them to be able to cancel in a comparable number of steps, not via a phone call or a hidden multi-step flow.

    Does the FCA's Consumer Duty apply to subscription cancellation UX?

    Yes, for FCA-regulated firms. The Consumer Duty requires firms to act to deliver good outcomes for retail customers, and the FCA has been explicit that foreseeable harms from product design, including friction-heavy cancellation flows, fall within scope.

    Are retention offers during cancellation allowed under UK consumer protection rules?

    A single, skippable retention offer is generally acceptable. The problem arises when the offer becomes a mandatory gate that the user cannot bypass without taking additional action. The user must always be able to confirm cancellation directly from the retention screen in one step.

    What technical records should a UK SaaS team keep around subscription cancellations?

    At minimum, you should log the exact timestamp of cancellation intent, the billing state at that moment, and a record of the confirmation sent to the user. Billing provider webhooks (Stripe, Paddle) make this straightforward to automate; the key is routing those events into a queryable audit log.

  • Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    SaaS subscription costs have quietly become one of the more embarrassing line items in a freelance studio’s accounts. Notion, Linear, Loom, Slack, Figma, Jira, individually each one feels reasonable. Together they can easily run past £400 a month for a team of four. I did the maths on my own setup earlier this year and genuinely winced. The good news is that the self-hosted open source ecosystem has matured enough that you don’t have to choose between cutting costs and keeping a coherent workflow. Here’s what I’ve actually tried, what’s stuck, and what the UK indie dev community seems to be converging on in 2026.

    Developer workspace with open source Notion alternative project dashboard on screen
    Photo by Paras Katwal on Pexels

    Why self-hosting makes sense for small UK studios right now

    A UK sole trader or small limited company running a modest VPS, something like a £6/month Hetzner instance, can host several of these tools simultaneously without meaningful performance issues. The upfront config time is real, but it’s a one-time cost, and the ongoing bill is dramatically lower than stacking commercial SaaS tiers. There’s also a GDPR angle worth taking seriously: when you self-host, your data stays in a jurisdiction you control. For client project notes, that’s not nothing. HMRC’s Making Tax Digital push means more studio finances are flowing through connected tools, and keeping sensitive records off third-party US servers is a decision some UK accountants are actively recommending.

    If you want a deeper look at building a full self-hosted design stack, I wrote about running Penpot, Gitea, and Plausible on a single VPS in a previous piece on self-hosting your design stack, the infrastructure thinking there applies directly to everything below.

    The open source Notion alternative UK developers are actually using: AppFlowy and Outline

    AppFlowy is the one I’d push first. It’s written in Flutter and Rust, which makes it genuinely cross-platform without the Electron weight you get with some alternatives. The document editor is clean, the database views (grid, board, calendar) cover most of what Notion’s block editor does, and self-hosting is straightforward via Docker. The community is active and the release cadence is fast, meaningful updates most months.

    Outline is a better fit if your primary need is a team knowledge base rather than a personal productivity system. It’s polished in a way that Notion took years to reach, the search is snappy, and the permission model is sensible. I’ve seen a few London-based dev agencies switch their internal wikis to Outline and genuinely not miss Notion’s more bloated features. The markdown import/export is solid, which matters when you want data portability.

    Both are genuinely viable as an open source Notion alternative for a UK developer who doesn’t mind an afternoon of Docker Compose config.

    Replacing Linear: Plane and GitLab Issues

    Linear is seductive because it’s fast and opinionated. Replacing it is harder than replacing Notion because the interaction design is genuinely exceptional. That said, Plane (formerly Plane.so) has closed the gap significantly. The issue tracking, cycle views, and roadmap features are all present; the UI is cleaner than Jira by a large margin; and the self-hosted version is free. It’s not quite as snappy as Linear but it’s functional and improving quickly.

    The other answer is simply leaning harder into GitLab’s built-in issue boards and milestones if your code is already there. For solo developers especially, adding a separate project management layer is often overkill. GitLab’s planning features are underused by most people who already pay for it. If you’re on Gitea (which you should consider, it’s tiny and fast), Issues plus Projects covers the basics without any additional stack.

    Async video without Loom: Vdo.ninja and Cap

    Loom is one of those tools that feels indispensable until you find the replacement. Cap is the most direct open source equivalent, it handles screen recording, gives you a shareable link, and the self-hosted version keeps the video on your own storage. It’s still relatively young but the core workflow is there. For client handoffs and async code walkthroughs, it does the job.

    Vdo.ninja deserves a mention too, though it’s more of a live peer-to-peer video tool than a recording one. For quick calls that don’t need a Zoom account, it’s genuinely brilliant. No accounts, no downloads, just a link. The latency is low enough that I’ve used it for client feedback sessions without issues.

    Collaboration and chat: Mattermost over Slack

    Mattermost is the self-hosted Slack equivalent that’s been around long enough to be boring in the best possible way. It’s stable, it has threading, it has integrations, and the mobile apps are decent. For a studio that’s grown tired of Slack’s free tier limitations (10,000 message history is not generous), Mattermost self-hosted removes that ceiling entirely. The setup is more involved than some of the other tools here, but the official deployment docs are thorough and there are pre-built Docker images for most architectures.

    Zulip is worth knowing about too. It organises conversations by topic within channels, which sounds fussy but genuinely helps async teams stay coherent. A few open source projects use it as their primary communication tool and swear by it. If Slack’s flat channel model drives you mad, Zulip’s threading model is worth an hour of your time.

    Design feedback without Figma’s comment layer: Penpot and Freehand alternatives

    Penpot keeps getting better. As a design tool it still trails Figma on plugin ecosystem and prototyping depth, but for a UK freelancer doing UI work for small clients, the core feature set covers most projects. The comment and feedback layer works well enough for async client review. The self-hosted instance is stable and the team’s development pace has picked up noticeably since 2025.

    For teams that want to keep Figma but ditch the extra collaboration cost, Liveblocks has an open-core model worth investigating. It’s not a direct tool replacement but if you’re building your own internal tools, the multiplayer infrastructure is solid.

    Putting it all together: a realistic stack

    The stack I’d suggest for a UK solo developer or small studio trying to cut costs without losing their mind:

    Notes and docs: AppFlowy for personal project notes, Outline for shared team knowledge base. Issue tracking: Plane for dedicated project management, or GitLab Issues if your repos are already there. Async video: Cap for client recordings. Chat: Mattermost if you need team comms; skip it entirely if it’s just you. Design: Penpot where Figma is overkill.

    You won’t get 100% feature parity with the SaaS equivalents. Some of these tools have rough edges and the occasional bug that a £25/month commercial product wouldn’t ship. But the gap has closed enough that the workflow quality argument for staying on expensive subscriptions is much weaker than it was two years ago. The UK’s cost-of-living pressures on freelance rates aren’t going away, and trimming £200 a month from tooling costs is a meaningful number for a one-person studio.

    It’s also worth thinking about this alongside how you structure your frontend tooling choices more broadly. The same practical mindset that leads you to question a £15/month Notion subscription should probably apply to your framework choices and your component architecture too. Self-sufficient stacks compound over time.

  • 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.

  • Designing Sustainability Dashboards: What UK Green Tech Startups Get Wrong About Data Visualisation

    Designing Sustainability Dashboards: What UK Green Tech Startups Get Wrong About Data Visualisation

    There’s a particular flavour of cognitive dissonance you get when you open a green tech product’s interface for the first time. The brand promises clarity, accountability, a genuine window into your organisation’s carbon footprint. Then you land on a screen full of semicircular gauges, RAG status blobs, and a number in giant font that means nothing without three screens of context. Sustainability dashboard design in the UK has a real problem, and it’s not the data. The data is usually fine. It’s the design decisions layered on top of it.

    I’ve spent a fair amount of time picking apart how UK organisations present environmental metrics to end users: energy usage figures from smart meters, carbon output calculations, EPC certificate ratings, solar generation readings. The gap between what the raw compliance data says and what a person can actually do with it is, frankly, enormous. This piece is about that gap.

    sustainability dashboard design showing energy metrics on a desktop monitor in a UK office
    Photo by Tima Miroshnichenko on Pexels

    The gauge chart problem nobody wants to admit

    Radial gauges are everywhere in green tech dashboards. They look impressive in a product demo. They communicate urgency through colour. The trouble is they’re one of the worst chart types you can use for environmental metrics, and even gov.uk’s own energy guidance pages lean on simple bar progressions rather than circular metaphors when explaining consumption to ordinary users. A gauge showing you’re at 67% of your monthly energy budget tells you almost nothing actionable. 67% of what target? Set by whom? Does that include the anomalous spike last Tuesday? The gauge looks like a speedometer, which implies a single continuous scale, but energy usage is seasonal, contextual, and deeply non-linear. Circular charts collapse that nuance into a single needle.

    The fix is boring but effective: time-series line charts with annotated reference lines. Show the current period against the same period last year. Mark the target. Let the shape of the data tell the story. If you’re designing for a client whose users are monitoring solar panel generation alongside grid draw, the relative rhythm of those two lines across a week is far more legible than any speedometer-style widget.

    EPC ratings as UI elements: where it goes badly wrong

    EPC certificates present a specific challenge. The A-to-G banded rating is already a UI element in its own right, designed by the government and deeply familiar to anyone who’s rented or bought a property in the UK. The mistake green tech products make is either reproducing it verbatim (which adds no value) or abstracting it beyond recognition into some bespoke colour scale that confuses users who’ve been reading the standard format for years.

    I’d argue the smarter move is to use the EPC band as a fixed anchor and then show movement relative to it. An organisation might start at an E rating. After a climate action plan is implemented, with energy saving measures and improved insulation, they’re targeting a C. Design the interface to show that trajectory explicitly: where you are, what a realistic improvement looks like, what specific changes (LED retrofits, heat pump installation, better building fabric) contribute to each band improvement. That’s when EPC data stops being a compliance checkbox and starts being genuinely useful. This connects to a broader principle I wrote about in the context of designing data-dense dashboards using UK government open data: government-issued banding systems are cognitive shortcuts that users already trust. Work with them, not around them.

    close-up of energy usage time-series chart illustrating sustainability dashboard design data
    Photo by RDNE Stock project on Pexels

    The colour coding trap

    Red equals bad, green equals good. It’s the most embedded metaphor in dashboard design. It’s also a serious accessibility problem and, in environmental contexts, often just wrong. I’ve seen dashboards where a green tile means “your energy usage is within target” sitting directly next to a tile where green means “solar generation is high today”. Two greens, opposite implications, no visual distinction. The result is a screen that looks reassuring regardless of what’s actually happening.

    Green tech products have a particular version of this issue because the domain itself is coded green. Everything wants to be green. The brand is green. The iconography involves leaves and sun rays. When your semantic colour system and your brand colour system use the same hue for different things, you’ve built a dashboard that feels good rather than one that communicates accurately. For a more systematic treatment of how to handle colour in ways that actually work for all users, the thinking I applied in writing about accessible palette design for UK product teams applies directly here: separate your semantic palette from your brand palette at the token level, and treat them as completely distinct systems.

    What organisations like R2G reveal about the usability gap

    Based in Nottingham, UK, R2G.co.uk works with organisations on energy efficiency improvements, climate action plans, and the kind of sustainability changes that are realistic rather than aspirational. What’s instructive about this space is that the organisations doing genuine energy saving work tend to arrive at their clients with compliance data: EPC certificates, carbon output baselines, consumption records. The challenge they face is exactly the design problem I’m describing. That raw compliance data, presented without a coherent information hierarchy, produces dashboards where a facilities manager can tell you their building’s kwh per square metre figure but can’t tell you whether it’s getting better or worse, or what they should do next. R2G’s approach at www.r2g.co.uk, of helping organisations make meaningful changes at a pace that works for them, only functions if the users engaging with environmental data can actually interpret it.

    Information hierarchy in sustainability UIs

    The core error in most sustainability dashboard design is treating all metrics as equally important. An interface that gives the same visual weight to monthly carbon output, daily energy consumption, solar panel generation percentages, and a compliance status badge is an interface that communicates nothing clearly. Users arrive with a question: am I on track? They need the answer within about three seconds. Everything else is detail that should live one click deeper.

    The hierarchy should roughly go: status (are we meeting targets?), then trend (are we improving?), then breakdown (where is the usage coming from?), then actions (what can we do about it?). Most green tech dashboards I’ve seen invert this entirely. They lead with the granular breakdown, bury the trend in a small sparkline somewhere in the corner, and leave the action recommendations entirely off the screen. The empty state problem compounds this: what does your dashboard show a new user who has no historical data yet? I’d look at the thinking behind effective empty state UI design for a template here, because the onboarding moment in a sustainability product is genuinely its most critical.

    Carbon data: the unit problem

    Carbon output figures are almost universally presented in kilograms or tonnes of CO2 equivalent. That unit is correct. It is also meaningless to most users without a reference frame. 12.4 tonnes of CO2 equivalent per year: is that good? Terrible? The UK average for a commercial building of this size? Green tech products need to build in contextual benchmarks, not as a nice-to-have, but as a fundamental data layer. The comparison should be specific: not “the UK average” (vague) but “similar-sized offices in the East Midlands” or “buildings of this EPC rating in your sector”. That specificity is what converts a compliance number into an actionable insight.

    What actually good looks like

    The best sustainability interfaces I’ve seen share a few characteristics. They present one primary metric per screen with everything else supporting it. They use time explicitly, showing change rather than state. They connect data points to decisions: if your energy usage spikes on Thursday afternoons, the interface should surface that pattern rather than averaging it away. And they treat the user as someone who knows their own building better than the software does, offering interpretation rather than instruction.

    For UK green tech teams specifically: lean on the EPC framework and government-issued standards as UX assets, not constraints. Users already understand the A-G scale. Working within it gives your product instant legibility. And if your product generates recommendations, make those recommendations specific, costed in pounds sterling, and time-bounded. “Install LED lighting across floors 2 and 3: estimated cost £1,200, estimated annual saving £340” is a product. “Consider energy saving measures” is noise. Organisations like R2G.co.uk, guiding clients through realistic climate action plans and energy efficiency improvements including solar panels and EPC certificate assessments, need interfaces that match that specificity. Generic dashboards produce generic action. Specific ones produce change.

    Frequently Asked Questions

    What is sustainability dashboard design?

    Sustainability dashboard design refers to the UI and data visualisation work involved in presenting environmental metrics, such as energy usage, carbon output, and EPC ratings, to end users in a clear and actionable way. Good sustainability dashboards prioritise information hierarchy, contextual benchmarks, and time-series trends rather than raw compliance figures.

    Why do green tech dashboards so often fail to communicate clearly?

    The most common failure is treating all metrics as equally important, which overwhelms users and buries the key question of whether targets are being met. Over-reliance on gauge charts and poorly separated colour coding also contribute to interfaces that look impressive but communicate little of practical use.

    How should EPC ratings be presented in a sustainability product interface?

    EPC ratings work best as fixed anchors that show movement over time rather than as static badges. Display the current rating, the target rating, and the specific measures (such as insulation or LED retrofits) that contribute to each band improvement. This turns a compliance label into a planning tool.

    What chart types work best for energy usage data?

    Time-series line charts with annotated reference lines consistently outperform gauge and radial charts for energy data. They show trend, seasonality, and anomalies in a single view. Showing the current period against the same period last year with a target line is usually sufficient for most end users.

    How can carbon output figures be made more meaningful to non-technical users?

    Carbon figures need contextual benchmarks to be usable: not just a raw CO2 equivalent number, but a comparison against similar buildings in the same sector and region. Connecting the figure to a cost in pounds sterling (e.g. estimated savings from specific measures) also converts abstract data into something a decision-maker can act on.

  • Designing for Colour Blindness: What UK Product Teams Get Wrong About Accessible Palettes in 2026

    Designing for Colour Blindness: What UK Product Teams Get Wrong About Accessible Palettes in 2026

    About 1 in 12 men and 1 in 200 women in the UK have some form of colour vision deficiency. That’s roughly 3 million people. And yet, I’d estimate that at least half the digital products I review have UI decisions that make life actively harder for those users. Red-on-green status badges. Light grey placeholder text on white. Gradient buttons where the text disappears on a cheap display. These are not edge cases. They’re just bad colour accessibility design, repeated across the industry at scale.

    The frustrating part is that the tools to catch this have existed for years. WCAG 2.1 has been around since 2018. The Web Content Accessibility Guidelines spell out minimum contrast ratios in plain language. And still, product teams ship inaccessible palettes every single week. Let me walk through why, and what you can actually do about it.

    Designer reviewing colour accessibility design palette on a laptop screen
    Photo by Ron Lach on Pexels

    The WCAG contrast ratios most teams get wrong

    WCAG defines two levels of contrast compliance: Level AA and Level AAA. For normal text, AA requires a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) drops to 3:1. AAA pushes normal text to 7:1. Most UK product teams aim for AA, which is reasonable, but they check it once during design handoff and never again after the developer has implemented the palette in code.

    Here’s where it goes wrong. A designer checks the contrast ratio of dark blue text on a white background. Passes. Then a developer applies an opacity value to the same element, or the background becomes a card with a slightly off-white tint, or a hover state changes the background colour. Suddenly you’re at 3.2:1 and nobody’s noticed because nobody re-ran the check. Contrast is not a static property of a colour; it is a relationship between two colours in the exact context they appear.

    I’d also flag that checking contrast ratio alone is not the same as designing for colour vision deficiency. A 4.5:1 ratio between red and green can technically pass a contrast checker while being completely indistinguishable to someone with deuteranopia (the most common form of red-green colour blindness). WCAG compliance and inclusive colour accessibility design are related, but they are not identical.

    The four types of colour vision deficiency you actually need to design for

    Deuteranopia and protanopia are both forms of red-green colour blindness, affecting the green-sensitive and red-sensitive cones respectively. Tritanopia affects blue-yellow perception and is much rarer. Achromatopsia (complete colour blindness) is rarer still. For most practical design decisions, deuteranopia and protanopia are where your palette choices will cause the most problems, and they often produce similar confusion: red, orange, yellow, and green all collapse toward a brownish-yellow or olive spectrum.

    This matters enormously for specific design conventions. Traffic-light status systems (red bad, amber warning, green good) are genuinely problematic for a significant chunk of your users. If your SaaS dashboard uses colour alone to communicate status, you’ve already failed those users, regardless of what your contrast ratio is. The fix is not to abandon colour; it’s to never rely on colour as the only differentiator. Add an icon, a label, a pattern, a shape. Colour should reinforce the signal, not carry it alone.

    Colour swatches showing contrast ratios used in colour accessibility design review
    Photo by Tima Miroshnichenko on Pexels

    Building an accessible colour palette from scratch

    I tend to start palette work in Figma with a base neutral ramp (typically 10 shades from near-white to near-black), then layer in one primary colour and one or two accent colours. The constraint I impose from the start: every interactive element must read clearly when viewed through a deuteranopia simulation, and every text element must pass AA contrast against every background it might appear on.

    A few practical rules I use:

    Avoid pure red and pure green as paired status indicators. If you need two semantic colours for success and error states, try blue and orange, or blue and red. Blue is safe for almost all colour vision deficiencies. If your brand insists on green for success, pair it with a distinct shape or icon, not just a colour change.

    Increase contrast beyond the minimum. 4.5:1 is the floor, not the target. I aim for 6:1 on body text as a working default. On interactive elements like buttons and form inputs, I want the border or outline to carry contrast independent of fill colour, so the element’s boundaries are clear even if the fill reads as a similar hue to the background for some users.

    Test your palette in a simulator, not just your head. Figma has a built-in colour blindness simulator under View > Accessibility. Sketch and Adobe XD have similar options. I also regularly paste screenshots into Coblis or the browser extension Colorblindly to see how a full page reads. This is not optional. Your own colour perception is not a reliable test instrument.

    Check states, not just default views. Hover states, focus rings, disabled states, error states, selected rows in a table. Each of these introduces a new colour context that needs its own accessibility check. This is where I see empty state UI design go wrong too: teams design the happy path accessibly and forget the edges.

    Where UK product teams specifically trip up

    The Government Digital Service accessibility guidelines are genuinely excellent, and GOV.UK itself is one of the better-performing large sites on colour accessibility. The problem is that outside of public sector work, most UK product teams treat accessibility as a compliance checkbox rather than a design constraint that applies from day one.

    I see three recurring failure modes. First: palette inherited from a brand identity created by a print agency, where colour choices were made for CMYK output with no thought given to screen contrast. The brand colour is a soft teal on white, it looks lovely on a business card, and it reads at 2.8:1 on screen. Second: a dark mode implementation added after launch that nobody tested with a contrast tool at all. Third: teams that do check WCAG but only check the primary brand blue on white, then assume the rest of the palette is fine.

    If your team is shipping anything that touches the public (and especially if it handles data, finance, or health information), you also have legal considerations. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require WCAG 2.1 AA compliance for public sector bodies. Private sector products are not yet legally mandated in the same way, but the UK government’s accessibility guidance is worth reading regardless of whether you’re building for the public sector, because it’s simply well-written practical advice.

    For teams checking deliverability and technical health across their digital stack, tools like dijitul can surface issues that are easy to miss when you’re deep in the product work itself.

    The semantic colour system approach

    The most resilient approach I’ve seen for colour accessibility design is building a semantic token layer on top of your raw palette. Instead of using hex values directly in components, you reference tokens like --color-status-error, --color-interactive-primary, --color-text-muted. The token values can change for dark mode or high-contrast mode without the component needing to know anything about it.

    This is also where the data dashboard UI design work gets genuinely interesting: when your chart colours are semantic tokens, you can ship a colour-blind-friendly palette mode as a user preference with very little engineering effort. ONS and DEFRA both use this kind of approach in their public data tools, and it’s something more UK product teams should be borrowing.

    The other thing I’d push for is putting contrast ratio checks into your CI pipeline, not just your design review. Tools like AI-assisted code review can catch some accessibility regressions, but a dedicated linter like axe-core or pa11y will catch colour contrast failures at the component level automatically. Shift left. Find it before the release, not in a user complaint six months after.

    Quick wins for teams starting from an inaccessible baseline

    If you’re inheriting an existing product with a broken palette, you don’t always get to start from scratch. The quickest wins: darken your primary text colour (near-black, not pure black, ideally around #1a1a1a on white gives you headroom), lighten your backgrounds to true white or near-white, and add visible borders to all form inputs. Those three changes alone will fix a significant portion of contrast failures without touching your brand colours.

    For semantic status colours, swap to filled badges with white text instead of coloured text on white backgrounds. A red badge with white text reads at roughly 5.5:1 for standard red; red text on white is usually around 3.9:1. Same brand colour, meaningfully better contrast.

    Colour accessibility design is not a niche concern, and it’s definitely not a “nice to have” for UK teams building products in 2026. It’s just good design. The users who benefit most from an accessible palette are rarely the ones who make the most noise about it, which is exactly why product teams keep getting it wrong.

    Frequently Asked Questions

    What contrast ratio do I need to pass WCAG 2.1 AA for normal text?

    Normal body text needs a contrast ratio of at least 4.5:1 between the text colour and background colour. Large text (18pt regular or 14pt bold) only requires 3:1. You can check ratios using free tools like the WebAIM Contrast Checker.

    Does passing a contrast ratio check mean my design is colour blind friendly?

    Not automatically. A contrast ratio check measures luminance difference, not hue distinction. Red and green can have a technically passing contrast ratio while being completely indistinguishable to someone with deuteranopia. Colour vision deficiency testing requires a separate simulation tool on top of contrast checking.

    What is the most common type of colour blindness I should design for?

    Deuteranopia (reduced green cone sensitivity) and protanopia (reduced red cone sensitivity) together affect roughly 8% of men in the UK. Both cause difficulty distinguishing reds, greens, and related hues. Designing for these two covers the vast majority of users with colour vision deficiency.

    Are UK websites legally required to meet colour accessibility standards?

    Public sector websites and apps are legally required to meet WCAG 2.1 AA under the Public Sector Bodies Accessibility Regulations 2018. Private sector products are not currently subject to the same legislation, but accessibility failures can still create liability under the Equality Act 2010 if disabled users are disadvantaged.

  • Fluid Typography With CSS clamp(): The Technique UK Frontend Developers Should Have Adopted Two Years Ago

    Fluid Typography With CSS clamp(): The Technique UK Frontend Developers Should Have Adopted Two Years Ago

    There’s a particular kind of embarrassment reserved for the moment you open your beautifully crafted web page on a 13-inch laptop and watch all your carefully considered heading sizes either cramp into something tiny or balloon out past the content container. Fixed type scales do this. They always have. Fluid typography using CSS clamp() solves it, and I’m genuinely baffled that, as of 2026, it still isn’t the default approach on most UK frontend projects I encounter.

    This isn’t a gentle introduction. I’ll assume you know what a rem is and that you’ve written a media query before. What I want to walk through is the actual maths behind clamp(), how to calibrate it for the screen sizes your UK users are actually on, and how to fold the whole thing into a proper design token workflow so your type scale lives in one place and propagates everywhere.

    Frontend developer writing fluid typography CSS clamp code on a laptop
    Photo by Lukas Blazek on Pexels

    What clamp() actually does

    clamp(min, preferred, max) picks the preferred value, but clamps it between a floor and a ceiling. That preferred value is where all the cleverness happens. If you write something like:

    font-size: clamp(1rem, 2.5vw, 1.5rem);

    You get a font size that scales with the viewport width, but never drops below 1rem and never exceeds 1.5rem. That’s the core idea. The problem is that 2.5vw in isolation is a terrible preferred value, because it produces 0 at 0px and scales purely linearly with zero regard for legibility at mid-range viewports. You need a preferred value that interpolates smoothly between two known sizes at two known viewport widths. That’s where the proper formula comes in.

    The interpolation formula you actually need

    The formula for a linearly interpolated fluid value between a minimum font size at a minimum viewport width and a maximum font size at a maximum viewport width looks like this:

    preferred = calc(minSize + (maxSize - minSize) * ((100vw - minWidth) / (maxWidth - minWidth)))

    In real units, if you want 1rem (16px) at 375px viewport and 1.5rem (24px) at 1280px:

    slope = (24 - 16) / (1280 - 375) = 8 / 905 ≈ 0.00884
    intercept = 16 - 0.00884 * 375 ≈ 12.685px
    
    preferred = calc(12.685px + 0.00884 * 100vw)

    Which you’d convert to rem (dividing by 16 for a standard root font size) and write as:

    font-size: clamp(1rem, 0.7928rem + 0.5525vw, 1.5rem);

    Yes, those decimals look gnarly. That’s fine. CSS handles it. You are not writing this by hand for every token; you’re generating it. More on that shortly.

    Calibrating for UK screen usage patterns

    Your breakpoint assumptions matter here. The temptation is to use 320px as your minimum, but StatCounter’s UK mobile resolution data shows that sub-360px devices now represent a tiny fraction of UK traffic. The iPhone 15 family, Samsung Galaxy A series, and Pixel 8 all sit at 390px or 393px logical width. Using 375px as your minimum is reasonable; 360px is safer if you want extra headroom.

    At the upper end, UK desktop usage clusters heavily around 1280px to 1440px. A 1920px maximum makes sense for large-display contexts, but for most B2B SaaS products and editorial sites, capping your fluid scale at 1440px stops runaway sizes on widescreen monitors whilst keeping the type relationship intact on the screens your users actually have.

    My working defaults for a UK web project in 2026:

    • Min viewport: 375px
    • Max viewport: 1440px
    • Root font size assumption: 16px

    These feed into every token calculation. Change the viewport bounds and every size updates automatically, which is exactly the kind of systematic control that makes a design token workflow worthwhile.

    CSS clamp fluid typography values shown as design tokens on a code editor screen
    Photo by Marc Mueller on Pexels

    Building a fluid type scale as design tokens

    The right place to store a fluid type scale is in CSS custom properties, generated from a source of truth. I’d argue for keeping the raw scale parameters in a JSON token file (compatible with the W3C Design Token Community Group format, which has decent tooling support now) and compiling the clamp() values at build time.

    A minimal token definition might look like:

    {
      "font-size": {
        "sm": { "min": "14px", "max": "16px" },
        "base": { "min": "16px", "max": "18px" },
        "lg": { "min": "20px", "max": "26px" },
        "xl": { "min": "28px", "max": "40px" },
        "2xl": { "min": "36px", "max": "56px" }
      }
    }

    A small Node script (or a PostCSS plugin like postcss-utopia, which wraps the Utopia calculator logic) reads those pairs plus your viewport bounds and emits:

    :root {
      --font-size-sm:  clamp(0.875rem, 0.8279rem + 0.2347vw, 1rem);
      --font-size-base: clamp(1rem, 0.9529rem + 0.2347vw, 1.125rem);
      --font-size-lg:  clamp(1.25rem, 1.0735rem + 0.8825vw, 1.625rem);
      --font-size-xl:  clamp(1.75rem, 1.3676rem + 1.9118vw, 2.5rem);
      --font-size-2xl: clamp(2.25rem, 1.6912rem + 2.7941vw, 3.5rem);
    }

    Then your component CSS just references var(--font-size-xl) and the browser handles the rest. No media queries, no breakpoint logic in component files, no manual tweaks per screen size. If you’re already building with a considered typography stack, dropping fluid tokens in is a natural extension of the same thinking.

    The line-length problem fluid type creates

    Here’s a wrinkle I see trip people up. When you make your body copy larger at wide viewports, your line length (measure) also tends to grow because content areas expand. Optimal legibility sits around 60-75 characters per line. A 18px body size in a full-width column at 1440px is brutal to read.

    The fix is to apply fluid typography alongside a max-width constraint on text containers, usually expressed in ch units. Something like max-width: 72ch on a prose container gives you typographic legibility that holds across viewport sizes. If you’re working on data-dense interfaces, this interacts with layout in more complex ways, but for editorial contexts it’s the single most effective pairing. I’ve written separately about designing data-heavy interfaces where these constraints get more nuanced.

    Accessibility: what clamp() doesn’t fix for you

    This is the part people skip and shouldn’t. clamp() with viewport-relative units can break user font-size preferences when set as the preferred value. If a user has set their browser default to 20px (common amongst users with low vision), a clamp() with a vw-based preferred value will often override that preference at mid-range viewport widths.

    The fix is to express your min and max in rem (so they respect the user’s root font size) and keep the viewport-scaling component relatively modest. Avoid making the vw component so large that it dominates and overrides rem-based preferences at most widths. The WCAG 1.4.4 Resize Text criterion requires that text can be resized to 200% without loss of content or functionality, and a poorly calibrated clamp() can fail that silently.

    Test with browser zoom, not just OS-level zoom. They behave differently. And if you’re working on products where accessibility really matters (and it should always matter), cross-reference your approach against the guidance in the designing for older users piece, since fluid type scales interact directly with the readability concerns raised there.

    A practical integration checklist

    Before you ship a fluid type scale, I’d run through these:

    • Are min and max values in rem, not px? (px ignores user preferences.)
    • Does the scale still look right at 320px? (Edge case, but government accessibility audits will check it.)
    • Have you tested browser zoom at 200%? That’s the WCAG threshold.
    • Are line lengths constrained at wide viewports?
    • Do your fluid sizes live in CSS custom properties, not scattered throughout component files?
    • Is the scale generated from a single source of truth so it can change in one place?

    I’ve seen projects where the type scale is duplicated across twelve component files and the Figma file, and they’re all different from each other by 2px here and there. It’s the typographic equivalent of archaeological layers. A token-driven clamp() system collapses that mess into something you can actually maintain.

    Worth mentioning: Utopia and similar tools

    If you’d rather not write a custom build script, Utopia.fyi by Clearleft is the most polished UI for generating fluid type and space scales. You punch in your viewport bounds, your type scale ratios, and your base sizes, and it spits out ready-to-use clamp() values with a live preview. I use it for rapid prototyping and to sanity-check hand-calculated values. It’s also where I first saw how naturally fluid grids and fluid type pair together, which led me down the rabbit hole of the kind of structured layout thinking covered in the return to editorial grid layout discussion.

    On completely different creative projects, I’ve noticed that even hobbyist communities with strong visual identity thinking are getting more thoughtful about typography at scale. The folks at brickclub.uk are a good example of a community site that clearly cares about readability across devices, which is the baseline any content-led site should be hitting.

    Fluid typography isn’t a trend. It’s just correct behaviour for a medium where you genuinely do not know the screen your user is on. The tooling is mature, the browser support is universal (even IE is no longer an excuse anyone’s making in 2026), and the design token integration path is well-trodden. The only reason not to be doing this is inertia, and inertia is a terrible technical decision.

    Frequently Asked Questions

    What browsers support CSS clamp() for fluid typography?

    All modern browsers have supported clamp() since 2020, including Chrome, Firefox, Safari, and Edge. As of 2026 global browser support sits above 97%, so there are no meaningful compatibility concerns for UK web projects. You can use it without a fallback for the vast majority of users.

    How is CSS clamp() different from using media queries for responsive type?

    Media queries produce stepped changes at fixed breakpoints, so font size jumps rather than scales. clamp() interpolates continuously between a minimum and maximum size as the viewport width changes, producing smooth scaling with no abrupt jumps. It also means far less code, since you replace multiple breakpoint overrides with a single property value.

    Will fluid typography break user font size preferences in their browser?

    It can, if you express the min and max values in px instead of rem. Using rem for both bounds ensures the scale respects a user’s browser default font size setting. Keep the viewport-scaling component proportionally modest so it doesn’t override user preferences at mid-range viewport widths.

  • How to Design Data-Dense Dashboards That Actually Work: Lessons From UK Government Open Data Tools

    How to Design Data-Dense Dashboards That Actually Work: Lessons From UK Government Open Data Tools

    There’s a specific kind of despair that comes from opening a government data portal and watching your browser tab freeze under the weight of seventeen nested tables, colour-coded with no legend, and a typography scale that tops out at 11px. I’ve spent an embarrassing amount of time pulling data from HMRC filing tools, Companies House search interfaces, and Ofcom’s connected nations reports, and the contrast between the ones that work and the ones that don’t is genuinely instructive. Not in a “here are five mistakes to avoid” way, but in a granular, layout-level way that tells you exactly why dense information UIs fail and what fixing them actually costs.

    The good news: data dashboard UI design in the UK has a handful of public sector examples worth studying closely. The bad news: most of them are improvements over disasters rather than models of perfection. Either way, there’s a lot to learn.

    Government data dashboard UI design on a desktop monitor in a UK office setting
    Photo by Keysi Estrada on Pexels

    Why government data tools are the right case study

    Private-sector dashboards get to constrain their data. A SaaS analytics product shows you the five metrics that justify its price. Government tools can’t do that. Companies House has to surface director histories, address changes, filing deadlines, PSC data, insolvency events, and charge registrations, all on a single company profile. Ofcom’s Connected Nations tracker plots broadband and mobile coverage across every postcode in the UK and has to let a telecoms analyst, a local councillor, and a journalist all make sense of it without training. HMRC’s business tax account has to serve a sole trader who files once a year and a payroll team running weekly PAYE submissions. That breadth is brutal on UI designers, and it’s precisely what makes these tools useful to study.

    The pressure to present everything to everyone creates the same pattern failures you see in enterprise SaaS dashboards, internal ops tools, and data journalism products. Solve it at the government scale and you’ve solved it everywhere.

    Hierarchy first: what HMRC’s business tax account gets right

    HMRC’s business tax account underwent a significant redesign using the GOV.UK Design System, and the result is instructive. The primary improvement was ruthless hierarchy. The old interface tried to present every outstanding obligation, every payment, every registration at equal visual weight. The redesign introduced a clear primary action at the top of the page, then organised everything else into categorised sections with meaningful labels.

    The lesson: in any data-dense UI, the user has a most-common task. Find it. Put it at the top. Make everything else subordinate. This sounds obvious but most dashboard designers resist it because stakeholders want every metric to feel “important”. They’re not all important at the same time. If your UI tries to shout everything at once, it communicates nothing.

    Typographically, GOV.UK Design System uses GDS Transport (or the open-licence version, GDS Transport Web) with a strict, large-step type scale. The difference between heading levels is dramatic by design. On a data-heavy page, a small size differential between H2 and body text means users scan poorly. You want the hierarchy to be almost cartoonishly obvious. I’d argue most commercial product designers are too subtle with their type scales in contexts where the data volume demands contrast.

    Tables that don’t cause eye strain: lessons from Companies House

    The Companies House search experience has improved considerably since the WebCHeck era. The current interface handles a genuinely tricky problem: tabular data that varies enormously in row density depending on what you’re looking at. A dormant micro-company has three rows of filing history. A large PLC has hundreds.

    Close-up of a structured data table used in UK dashboard UI design
    Photo by Pavel Danilyuk on Pexels

    A few things stand out. First, the alternating row colour is implemented with enough contrast to be functional without being visually loud. This matters. I’ve seen dashboards where alternating rows are almost identical in lightness and the zebra striping does nothing useful. Companies House uses a grey that’s distinct enough to genuinely separate rows. Second, the table doesn’t try to show everything inline. Document links open into a viewer rather than expanding the row and breaking the spatial relationship between rows. That keeps the table scannable even when a user is drilling into detail.

    The bigger structural choice is column count. Companies House limits visible columns to the genuinely essential ones and puts additional metadata one click away. This is the right call. Every additional column in a table increases cognitive load exponentially, not linearly. If you’re designing a financial dashboard, a logistics ops screen, or a data journalism tool, this principle applies directly: start with the minimum viable column set and make expanded detail feel natural, not buried.

    For designers working on anything with structured layout systems, the Companies House table structure is worth reverse-engineering. The grid decisions behind it, particularly how they handle variable-length content in fixed-width columns, are more considered than they look.

    Colour as data channel, not decoration

    Ofcom’s Connected Nations interactive maps are where data dashboard UI design in the UK gets genuinely sophisticated. The challenge is presenting five-level signal strength data across hundreds of thousands of data points in a format that’s readable at both national and street level. They use colour as a primary data channel, which is the right call, but they also do something many tools skip: they label the colour scale clearly, they make the legend persistent at all zoom levels, and they provide a text fallback for every postcode lookup.

    The failure mode I see in commercial data dashboards is using colour purely decoratively or to signal sentiment (red bad, green good) without encoding actual data. If your chart uses six shades of blue to show six categories, you’ve just made a puzzle. Colour should carry a specific, legible meaning and that meaning should be explained, always.

    There’s also a contrast accessibility dimension here. GOV.UK’s design guidelines mandate a minimum contrast ratio of 4.5:1 for text and 3:1 for graphical elements, in line with WCAG 2.1 AA. Commercial dashboards routinely fail this on data visualisations. Light grey labels on white backgrounds. Pale teal percentage indicators. These look clean in a Figma mock-up and become unreadable in production. Testing colour decisions against real ambient conditions, particularly on non-calibrated office monitors, is non-negotiable if your UI has more than a handful of data points.

    On a completely different scale of data visualisation, I find it useful to think about how even simple, real-world categorisation problems share the same underlying design challenge. Homeowners in Nottinghamshire increasingly turn to specialists like The Bin Boss for domestic wheelie bin cleaning, a service that requires communicating hygiene and environment-related data (bacteria load, cleaning frequency, germ reduction results) to a non-technical audience via a house-facing interface, whether that’s a website, a scheduling app, or a service report. The Bin Boss (thebinboss.co.uk) essentially solves the same information hierarchy problem that Ofcom’s maps do: how do you communicate a gradient of states (clean, mildly contaminated, heavily contaminated) in a way that’s immediately understood? Colour coding, iconography, and clear labelling. The principles don’t change because the subject matter is wheelie bins instead of broadband signal.

    Spacing is doing more work than you think

    One of the consistent things I notice across the better UK public sector data tools is generous internal spacing in dense components. Padding inside table cells. Breathing room between a chart and its axis labels. Margin between a data summary and the table it describes. This isn’t aesthetic preference; it’s functional. Dense data requires spatial separation to allow the eye to parse individual elements without them bleeding into each other.

    The typical failure is designing at 100% zoom on a large monitor with a single row of sample data. Everything looks fine. Then real data populates the table at 90% zoom on a 1366×768 laptop screen (still one of the most common screen resolutions in the UK, particularly in public sector settings) and the interface becomes unreadable. Designing for the densest realistic data state at the smallest realistic viewport is the only way to catch this early.

    If you’re building tools that sit on complex white-label or multi-tenant architectures, the spacing decisions at component level become even more critical. I’d recommend reading our breakdown of white-labelling patterns for UK B2B SaaS dashboards, which goes into how spacing and layout decisions need to survive theme variations across different client brands.

    What the Ofcom approach teaches us about filtering

    Filter controls on data-heavy UIs are almost always underdesigned. The Ofcom Connected Nations tool handles this well by keeping filters visible and persistent rather than hiding them in a modal. When filters are out of sight, users forget they’re applied. Then they make decisions based on data that’s silently scoped to a subset. In a compliance dashboard, a financial reporting tool, or an ops screen, that’s a real problem.

    The filter control design itself matters too. Multi-select checkboxes for categorical filters, sliders for continuous ranges, clear labels showing what’s currently applied and an obvious way to clear them. These aren’t novel patterns, but they’re consistently missed. The UK government’s icon design conventions for control affordances are worth reviewing here as well, since ambiguous filter icons routinely confuse users who aren’t coming from a SaaS-trained mental model.

    The filtering question connects to a broader truth about data dashboard UI design in the UK public sector context: users arrive with extremely varied data literacy. Designing a filter that a data analyst understands immediately and a non-specialist doesn’t get wrong requires real work, usually involving a lot of label text that most designers trim prematurely in the name of visual cleanliness.

    Making it work in practice

    If I were auditing a data-heavy UI right now, my checklist would look something like this. Is there one primary action or piece of information that the majority of users are looking for? Is it above the fold and visually dominant? Are tables limited to the minimum necessary columns? Is colour encoding labelled and accessible? Is there enough spacing to parse individual elements at realistic viewport sizes? Are filters visible and clearly indicating their current state?

    For tools handling government-facing data specifically, the GOV.UK Design System documentation is the most useful free resource in the UK for getting these decisions right. It’s not just about visual style; the decision rationale behind each pattern is documented, and that rationale transfers directly to commercial data product design.

    The complexity of a dataset doesn’t excuse a difficult interface. The Bin Boss-style clarity principle applies at every scale: whether you’re surfacing environment and bacteria data on a wheelie bin cleaning schedule or displaying PSC filings across ten thousand companies, the job is always to reduce the effort required to extract meaning. Everything else is just implementation detail.

    Frequently Asked Questions

    What makes a data dashboard UI design work for UK government tools?

    The best UK government data UIs, like HMRC’s business tax account and Companies House search, succeed by establishing strong visual hierarchy so the most common user task is immediately obvious, then organising subordinate information into clearly labelled sections. They also follow the GOV.UK Design System’s accessibility standards, which ensures colour contrast, type scale, and spacing hold up under real-world conditions.

    How do you handle too many columns in a data-heavy dashboard?

    The practical solution is to identify the minimum column set that covers the majority of user tasks and move everything else into an expandable detail view or secondary page. Every additional column increases cognitive load significantly, so the goal is always to display the essential data inline and make deeper detail feel one deliberate click away rather than buried.

    What colour contrast ratio should data dashboard UIs target in the UK?

    WCAG 2.1 AA requires a minimum 4.5:1 contrast ratio for text and 3:1 for graphical elements like chart labels or axis lines. UK public sector tools are required to meet this standard, and it’s a sensible baseline for any commercial dashboard handling complex datasets, particularly since data visualisation colour choices frequently fail this threshold when tested outside Figma.

    Should filter controls be visible or hidden in a data dashboard?

    Visible and persistent is nearly always the better choice. When filters are tucked into a modal or collapsed panel, users forget they’re applied and interpret scoped data as the full picture. Keeping active filter states visible, with a clear way to remove them, prevents this and significantly reduces user errors in data-intensive interfaces.

    Which free UK resources are most useful for designing government-facing data UIs?

    The GOV.UK Design System (design-system.service.gov.uk) is the starting point, as it documents not just visual patterns but the reasoning behind each decision, which transfers well to commercial data products. Ofcom’s Connected Nations reports and Companies House’s public interface are also worth studying as live examples of complex dataset presentation at scale.

  • Designing Multi-Tenant SaaS Dashboards: The White-Labelling Patterns UK B2B Teams Need in 2026

    Designing Multi-Tenant SaaS Dashboards: The White-Labelling Patterns UK B2B Teams Need in 2026

    There’s a very specific kind of design hell that UK B2B SaaS teams walk into when a sales director announces: “We’ve landed a white-label deal. Can you just swap out the logo and change the colours?” The answer is technically yes. The better question is whether your design system was ever built to support it. In most cases, it wasn’t. And that’s what white label SaaS dashboard design in the UK has quietly become in 2026: a structural problem dressed up as a branding request.

    I’ve spent a fair amount of time pulling apart multi-tenant dashboard architectures, both at the design token level and in Figma component libraries, and the patterns that separate teams who cope from teams who spiral into duplication nightmares are pretty consistent. This is what actually works.

    Multi-tenant SaaS dashboard interface shown on a monitor, relevant to white label SaaS dashboard design UK
    Photo by Egor Komarov on Pexels

    Why most SaaS design systems aren’t white-label ready out of the box

    The problem usually starts at the colour layer. A team builds a design system around a single brand: one primary palette, one set of semantic colour names, one font stack. Everything works beautifully until tenant two shows up with a completely different brand identity, different primary colours, and a typeface that isn’t Inter. Suddenly you’ve got a choice: fork the entire component library, or retrofit a theming layer that the system was never designed to accommodate.

    The fork path is where most teams end up, and it’s slow, expensive, and creates ongoing maintenance debt every time a core component changes. If you’ve got six tenants and three engineers, forking is how you spend your entire sprint cycle keeping six slightly different versions of a button component in sync. No one wants that.

    The better path is design tokens, specifically a three-tier token structure that separates raw values, semantic meaning, and component-level application. This isn’t a new idea, but the W3C Design Tokens Community Group‘s draft specification has given it enough formal grounding that it’s worth implementing properly now rather than cobbling something together.

    The three-tier token structure that makes multi-brand manageable

    Tier one is your primitive tokens: raw values with no meaning attached. colour-blue-500: #2563EB. That’s it. No context, no semantic weight. Just a value in your design system’s vocabulary.

    Tier two is semantic tokens. These reference primitives but give them meaning: colour-brand-primary: {colour-blue-500}. This is where the tenant swap actually happens. When tenant B comes in with their own brand colour, you’re changing only this layer. Tier three is component tokens, which reference semantic tokens: button-background-colour: {colour-brand-primary}.

    What this means practically: swapping a tenant’s brand requires changing roughly 15 to 30 semantic tokens. Not 400 individual component properties. I’ve seen UK fintech teams get a new tenant’s dashboard looking correct in under two hours using this structure properly. Without it, the same job takes days and breaks something unrelated every time.

    This also connects nicely to the work I’d recommend reading on icon systems in UK product design, because icon colour inheritance is one of the sneakier places where teams hardcode values instead of pulling from semantic tokens, and it creates silent inconsistencies the moment you apply a tenant theme.

    Figma component strategies for multi-tenant dashboards

    Figma’s variables system (now properly mature after a rocky 2024 rollout) is the most practical way to manage multi-tenant theming at the design stage. The approach that works: one base component library, one set of variable collections per tenant, and a simple variable swap to preview any tenant’s brand in the same file.

    Set up your variable collections to mirror your three-tier token structure exactly. Primitives collection, semantic collection, component collection. When onboarding a new tenant, you’re creating a new semantic collection that maps to different primitives, and that collection swap is all it takes to see the entire dashboard re-skin in Figma. This matters beyond aesthetics: it means your handoff documentation is always correct, because the component specs are pulling live values from the right collection rather than being annotated by hand.

    One thing I’d flag specifically for UK B2B contexts: accessibility compliance. The WCAG 2.2 guidance on GOV.UK is increasingly being referenced by enterprise procurement teams when evaluating SaaS products, especially in public sector adjacent markets. When a tenant swaps their brand colours in, your semantic token structure needs to preserve contrast ratios, which means building contrast validation into your token system, not treating it as an afterthought. Figma’s built-in contrast checker helps here, but I’d also run token exports through a script that validates WCAG AA thresholds automatically before a new tenant theme goes live.

    Logo swapping and asset management across tenants

    Logo swapping sounds like the easy part. It’s not, because logos aren’t just image files, they carry implicit sizing assumptions, clear space requirements, and colour mode variants that most teams don’t standardise. A tenant hands you their logo as a 2MB PNG with a white background and you’re suddenly in a conversation about SVG conversion and dark mode variants that no one budgeted for.

    The pattern that saves time: define a logo slot specification upfront. Decide the maximum and minimum dimensions, require SVG with transparent background, specify which colour modes need variants (light background, dark background, monochrome), and document this as an onboarding requirement for every tenant. This turns an ad-hoc request process into a predictable intake checklist. It also means your Figma library has a proper logo component with defined constraints rather than a free-floating image that someone will inevitably resize incorrectly.

    Typography is the other asset dimension people underestimate. If your product uses a licensed typeface, you cannot simply apply it to a white-label tenant without checking the licence covers redistribution and sub-licensing. I covered the landscape of usable typefaces in some depth in the piece on open source font pairing for UK web design, and that’s genuinely worth reading if you’re specifying fonts for a multi-tenant product, because the safe defaults there are exactly the ones that won’t land you in a licence dispute when a tenant insists on their brand typeface.

    Building the dashboard layout layer that works for every tenant

    Theming handles colour and typography. Layout is a different layer entirely, and it’s where white-label dashboards often feel slightly wrong even when the colours are correct. The issue is density assumptions baked into the layout that suit one type of user but not another.

    If your SaaS product serves both a small UK accounting firm and a large property management group, the data they want to see on their dashboards is different, the density they’re comfortable with varies, and the navigation hierarchy that makes sense for one makes no sense for the other. Token-based theming solves the brand problem; what solves the layout problem is a modular panel architecture where tenants can configure which panels are visible without requiring you to build a custom layout per client.

    This is really a product decision as much as a design one, but the Figma implication is worth spelling out: build dashboard layouts using an auto-layout grid of configurable panel components rather than fixed-position screens. Each panel is self-contained. A tenant configuration sets which panels are active. The design system handles spacing and sizing tokens. You never hardcode a dashboard layout in a static frame again. It’s a bit more upfront work, maybe two or three additional sprints to build the panel abstraction properly, but it makes every subsequent tenant onboarding genuinely faster.

    The same thinking applies to accessibility across different user demographics. If you’re building for tenants whose end users skew older, the considerations I wrote about in the piece on designing for older users in UK product teams become tenant-level configuration concerns: default font size tokens, touch target size tokens, reduced motion preferences. These are all design token decisions, which means a well-structured system can accommodate them per-tenant without forking the component library.

    When to build this properly vs. when to ship something scrappy

    Not every white-label deal justifies a full three-tier token refactor. If you’ve got one tenant, a simple CSS variable override at the root level might be genuinely sufficient. But if your sales pipeline has more than two potential white-label clients, and especially if those clients are enterprise contracts where your product will be embedded in their internal tools under their brand, the upfront investment in a proper token architecture pays back within the first two onboardings. The maths isn’t complicated.

    The UK B2B SaaS market in 2026 is structurally pushing more products toward multi-tenancy. Procurement consolidation, budget pressure, and the growth of platform-first business models all mean your product is more likely than ever to end up underneath someone else’s logo. Building a design system that handles that gracefully isn’t a nice-to-have, it’s table stakes for products that want to scale.

  • The Principles Behind BBC iPlayer’s UI: What Every British Product Designer Can Learn From It

    The Principles Behind BBC iPlayer’s UI: What Every British Product Designer Can Learn From It

    I’ve spent more time than is professionally advisable picking apart how the BBC iPlayer interface works. Not watching content on it, mind you. Actually staring at hover states, tab-order behaviour, loading skeletons, and the way the navigation rail collapses on a 40-inch telly versus a 320px mobile viewport. The BBC iPlayer UI design principles UK product teams should be studying are genuinely embedded in every screen of that product, and I want to drag them out properly.

    This is a teardown, not a fan letter. Where iPlayer does something brilliantly, I’ll say so. Where there’s a head-scratching inconsistency, that’s going in too. Either way, there’s a stack of transferable thinking here that most UK product teams would benefit from nicking.

    Television screen showing a streaming content grid, illustrating BBC iPlayer UI design principles UK product teams can learn from
    Photo by https://kaboompics.com/ on Pexels

    How iPlayer handles content discovery without overwhelming you

    Content discovery is probably the hardest design problem in streaming. You have thousands of titles, a user with forty-five seconds of patience, and a recommendation system that may or may not know them well yet. iPlayer’s solution is surprisingly restrained given the scale of the BBC’s catalogue.

    The homepage is structured as a progressive hierarchy. The hero slot anchors attention, but it’s not auto-advancing like Netflix’s carousel assault on your focus. Below it, content rows are labelled with actual editorial intent: “Catch Up”, “Recommended for You”, “New Arrivals”. These are not clever algorithmic names. They’re plain English labels that tell you immediately what logic organised them. That’s a design decision, not a default.

    I’d argue the most important part of the discovery UI is what iPlayer refuses to do. There are no autoplay trailers on hover in the web interface. There’s no “you have 5 seconds before the next episode starts” pressure mechanic unless you’ve opted into it. That restraint lowers cognitive load measurably, and it respects the fact that a significant portion of the BBC’s audience, covered thoroughly in the over-55 audience design piece on this blog, find high-density motion interfaces actively hostile.

    Accessibility as a structural decision, not a retrofit

    The BBC publishes its own accessibility standards, the BBC Accessibility Standards and Guidelines, which sit alongside WCAG 2.2. That’s not marketing copy. You can see the results of it directly in iPlayer’s codebase: focus states that are actually visible (not that 1px dashed outline browsers default to), semantic HTML that makes keyboard navigation feel deliberate rather than accidental, and live subtitle rendering that works across every surface including smart TVs where most streaming services just… don’t bother.

    The subtitle implementation is worth a short paragraph on its own. iPlayer’s subtitles render as HTML text overlaid on the video container rather than burned into the video stream. That means font size, colour, and background opacity are all user-adjustable. It also means the subtitle DOM is accessible to screen readers in certain configurations. That’s technically more complex to implement than a static .vtt file being displayed, and the BBC chose to do it anyway. That’s what “accessibility as infrastructure” looks like rather than accessibility as checkbox.

    If your product team is still treating accessibility annotations as a final design-handoff step, iPlayer is a case study in why that approach breaks down. The accessibility behaviour here is inseparable from the component architecture. You can’t retrofit it cleanly. Build it in or spend twice the effort later. This connects to the same reasoning I wrote about in the icon design system teardown, where icon meaning and accessibility labelling need to be decided at the system level, not icon by icon.

    Multi-device consistency and where it gets complicated

    iPlayer runs on an extraordinary range of surfaces. A 2013 Samsung smart TV, a current-gen PlayStation, a 320px Android handset, a desktop browser, and an iPad all need to present the same content catalogue through fundamentally different interaction paradigms. That is an engineering and design problem most product teams never encounter at this scale, but the principles iPlayer uses to solve it are still directly applicable.

    The key move is abstracting the design system away from the input model. The layout responds not just to screen size but to inferred input type: pointer (mouse/trackpad), touch, or remote/d-pad. The navigation rail behaviour changes meaningfully between these modes. On a remote-controlled TV interface, every interactive element needs to be reachable via directional navigation without any pointer. iPlayer’s focus management logic handles this without the user ever thinking about it.

    For most product teams the relevant principle is this: design for your secondary device first. iPlayer’s constraints from TV remote navigation have made the whole interface more keyboard-accessible by necessity. That’s a good trade. If you’re building a web app and keyboard navigation is an afterthought, try designing the component interaction model for a d-pad first and then add pointer support on top. The resulting component will be cleaner.

    Performance design and the perception of speed

    iPlayer’s actual page performance is not perfect. Run it through WebPageTest on a throttled 4G connection and you’ll see a real-world LCP that could be sharper. But the perceived performance is well managed, and that distinction matters more to users than a 100/100 Lighthouse score.

    The loading skeleton UI is implemented with care. Skeletons match the aspect ratios of the content cards they’re replacing, including the 16:9 thumbnail, the title line, and the metadata line. When content loads, there’s no layout shift. The skeleton was drawn to the correct dimensions. This is a WCAG-adjacent win but also just good engineering; it prevents the cascading reflows that trash Core Web Vitals scores and make pages feel broken to users even when the content eventually renders correctly.

    Image delivery on iPlayer also uses responsive sizing properly. The BBC’s image service appends dimension parameters to thumbnail URLs so the browser receives an image at the correct resolution for the current viewport. I’ve seen mid-sized UK product teams serving 1200px wide thumbnails inside 240px card slots. That’s not just a performance problem; it’s a data usage problem for mobile users on capped plans, which the Ofcom Connected Nations report consistently shows is still a significant real-world concern in the UK outside major city centres.

    The design system thinking underneath it all

    The BBC’s GEL (Global Experience Language) design system is public, and it’s worth reading even if you’re not building a product that touches the BBC at all. GEL is the spine of iPlayer’s consistency. Components are defined with explicit spacing, type scales, and interaction states at the system level. Individual feature teams don’t design new card components from scratch; they pull from GEL.

    That’s the transferable bit. The specific components in GEL don’t matter to your product. The structure of the thinking does. When a design decision is made once at the system level and then pulled into features rather than reinvented per screen, you ship faster, the product feels more coherent, and edge cases (like that 320px viewport on a cheap Android handset) get solved once and inherited everywhere.

    If your team is still at the stage of building a design system, the TypeScript for designers piece is worth reading alongside this one, because codifying your tokens and component contracts in a typed system is what prevents GEL-style consistency from decaying over time as teams grow.

    The BBC iPlayer UI design principles UK teams should extract aren’t magic. They’re the result of treating design constraints as opportunities, building accessibility into architecture, and refusing to optimise for engagement metrics that make interfaces worse. That combination is rarer than it should be, and iPlayer is one of the cleaner examples of it on any screen in the country.