Author: Alex Mason

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

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

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

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

    Why British developers specifically are drawn to pixel aesthetics

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

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

    The tooling behind modern pixel art game design

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

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

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

    Colour palette constraints as a design decision, not a limitation

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

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

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

    How this connects to broader UI and UX craft

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

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

    EGX and the studio ecosystem making this real

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

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

    Animation within the constraint: where the real craft lives

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

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

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

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

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

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

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

    What Dev Mode is actually supposed to do

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

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

    Where it genuinely works well in 2026

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

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

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

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

    Where it still fails, honestly

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

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

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

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

    The pricing question in GBP

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

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

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

    The annotation plugin gap

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

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

    Who should actually use it right now

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

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

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

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

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

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