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

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

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

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

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

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

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.

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.

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.

What does PECR require for cookie consent in the UK?

PECR requires that you obtain prior, informed, and freely given consent before setting any non-strictly-necessary cookies. This means no pre-ticked boxes, no dark patterns that push users towards acceptance, and the ability to withdraw consent as easily as it was given. Strictly necessary cookies, session management, shopping baskets, are exempt.

Is a cookie banner enough to be ICO-compliant, or do I need a full consent management platform?

A banner alone is not sufficient; what matters is that non-essential scripts are genuinely blocked until consent is given, that preferences are recorded with a timestamp, and that users can change their choice later. A consent management platform (CMP) handles most of this, but you can build a compliant system from scratch if you implement the technical requirements correctly. The ICO does not mandate any specific tooling.

Are dark patterns in cookie consent actually enforced in the UK?

Yes. The ICO issued enforcement notices against major UK publishers in 2024 specifically citing non-compliant consent interfaces, including asymmetric button styling and buried reject options. Fines under PECR can reach £500,000, and the ICO has stated publicly that enforcement in this area is ongoing.

Can I style my accept button differently from the reject button?

Using different colours is acceptable provided there is no significant difference in prominence, size, font weight, and placement should be equal. The ICO's guidance specifically flags making the reject option visually subordinate as a dark pattern. Monochrome, equal-weight button pairs are the safest approach.

Does a cookie consent modal affect page load performance or Core Web Vitals?

It can, but the impact is manageable. Using a system font stack in your consent modal avoids any additional font-loading overhead. The modal itself should be lightweight HTML and CSS, ideally inlined, so it renders before external scripts fire. Blocking non-essential third-party scripts until consent is given can actually improve your initial load performance, as those scripts are often the heaviest assets on the page.

Category: Design

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

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

Photo by Lukas Blazek on Pexels

The default chart is almost never the right chart

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

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

What Chart.js gets right and where it breaks down

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

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

Recharts: the React team’s comfort blanket

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

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

Observable Plot: the one serious developers should actually evaluate

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

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

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

The dashboard design mistakes that no library fixes on its own

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

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

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

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

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

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

Picking the right tool for real-world requirements

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

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

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

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

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

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

Photo by Matheus Bertelli on Pexels

The constraint-first philosophy that makes GDS components work

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

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

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

Typography choices that build trust at a cognitive level

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

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

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

Photo by cottonbro studio on Pexels

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

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

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

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

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

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

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

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

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

Spacing and layout: the 8px grid taken seriously

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

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

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

Making GDS constraints work outside a government context

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

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

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

Frequently Asked Questions

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

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

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

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

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

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

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

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

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

Photo by FOX ^.ᆽ.^= ∫ on Pexels

Why RTL is not just a text direction toggle

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

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

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

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

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

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

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

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

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

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

The mirroring rules most Western teams get wrong

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

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

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

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

Typographic considerations specific to Arabic and Urdu

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

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

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

Testing: you cannot eyeball RTL correctness

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

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

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

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

September 28, 2026
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.

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.
September 28, 2026
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.

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.

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.

September 23, 2026
Designing App Interfaces for the UK’s Ageing Population: What WCAG Doesn’t Tell You

WCAG compliance is the floor, not the ceiling. I’ve reviewed dozens of digital products built by UK teams who ticked every accessibility checkbox, shipped their app, and then watched users aged 60 and over abandon it within two minutes. The guidelines cover contrast ratios and keyboard navigation. They do not cover the lived reality of designing for someone who has never used a smartphone until their late fifties, has some degree of age-related macular degeneration, and finds most app navigation patterns genuinely baffling. App design for older users UK accessibility is a specialist discipline, and treating it as a WCAG checklist exercise is where most teams go wrong.

The UK’s Office for National Statistics puts the over-60 population at roughly 16 million, and that figure keeps climbing. NHS apps, council portals, financial tools, and retail platforms all need these users. They are not a niche edge case.

Photo by Teona Swift on Pexels

Cognitive load is the real killer, not contrast

Working memory declines with age. That is not a controversial claim; it is well-documented cognitive science. What it means for interface design is that the number of simultaneous choices, the density of options on a screen, and the length of multi-step flows all need to come down significantly compared to what you’d ship for a general adult audience.

I tend to think about it like this: if a 35-year-old can hold four things in their head while navigating your onboarding flow, design as if your 68-year-old user can hold two. That means progressive disclosure is not just a nice UX pattern, it is load-bearing. Break multi-step processes into single-question screens. Put one primary action per view. Cut every secondary option that does not absolutely need to exist on that particular screen.

The NHS App is a reasonable reference point here. Its appointment booking flow keeps each step minimal, labels are plain English, and the confirmation screen repeats key information rather than assuming users retained it from two screens back. That repetition feels redundant to a younger user and essential to an older one. You cannot design for both with the same screen, and that is fine. Design for the user who needs the most support and you will not alienate the one who needs less.

Touch target sizing: the WCAG minimum is not enough

WCAG 2.5.5 recommends a 44×44 CSS pixel minimum for touch targets. In practice, for users over 60, particularly those with any degree of tremor, reduced fine motor control, or arthritis, 44px is still small. Research from the Nielsen Norman Group puts comfortable touch target size for older users closer to 60x60px, with generous spacing between adjacent targets to reduce mis-taps.

Mis-taps are a huge source of frustration. When a user taps the wrong button repeatedly, they lose confidence in the interface and in themselves. That confidence collapse is much harder to recover from in an older user than a younger one. I’d argue the emotional cost of a mis-tap is asymmetric across age groups, and that asymmetry should drive your sizing decisions.

Some practical rules I use: make primary call-to-action buttons at least 56px tall, keep destructive actions (delete, log out, cancel) physically separated from confirmatory ones, and never place two tappable elements closer than 12px apart. On a related note, the accessible palette decisions UK product teams often get wrong apply doubly here, older users have reduced contrast sensitivity that compounds the touch accuracy problem when buttons are poorly differentiated visually.

Font legibility goes further than size

The standard recommendation is 16px body text minimum. For interfaces targeting users over 60, I’d go to 18px as a floor, with headings at 24px or above. But size is only part of font legibility. The typeface choice itself matters enormously.

Age-related changes to the lens of the eye reduce sensitivity to fine detail, which is why highly stylised typefaces, thin weights, and fonts with low x-heights become genuinely difficult to parse. Avoid any font weight below 400 for body copy. Prefer humanist sans-serifs, Inter, Atkinson Hyperlegible, or system UI fonts, over geometric ones. Atkinson Hyperlegible was specifically designed for users with low vision and performs exceptionally well in this context; the British Dyslexia Association also endorses it for overlapping reasons.

Line height matters too. Tight leading, common in sleek modern UI, forces the eye to work harder to track from one line to the next. Set line height at 1.6 or above for body text. And if you are using fluid typography with CSS clamp(), make sure your minimum clamp value never drops below 18px in older-user-facing contexts, even on small viewports.

NHS-informed interaction patterns worth stealing

The NHS design system is publicly available and genuinely excellent. The team that built it consulted heavily with patients across age groups, and the patterns reflect real-world usability testing rather than theoretical best practice. A few things in particular stand out.

First: plain English labels over clever microcopy. “Continue” beats “Let’s go.” “Your appointments” beats “My health hub.” Older users map UI labels directly to mental models formed outside digital contexts. The closer the label matches the real-world concept, the faster comprehension happens.

Second: explicit error messages that tell users exactly what to fix. “Invalid input” is useless. “Your date of birth should be entered as DD/MM/YYYY, for example, 15/03/1958” is useful. The NHS form patterns specify this level of specificity as standard, and it drastically reduces abandonment in older cohorts.

Third: visible, persistent navigation. The hamburger menu is a learned pattern that many older users simply never learnt. If your app can run with a bottom tab bar or persistent side navigation rather than a hidden drawer, do it. The cognitive cost of remembering that the menu is behind a three-line icon is higher than it looks.

You can read more about how strong institutional UI work informs everyday product design in my piece on the design principles behind BBC iPlayer, a lot of the same “reduce ambiguity, increase predictability” logic applies across user groups.

Testing with real users, not assumptions

The single most common mistake I see is teams designing for the mythical “older user” based on assumptions rather than running sessions with actual people aged 60 and over. It is not the same thing. The variance within that group is enormous, a 62-year-old software developer has completely different needs from a 78-year-old who has owned a smartphone for six months.

Age UK runs digital skills programmes across the UK and has published research on common barriers older users face with digital services. Their findings consistently point to confidence and trust as primary blockers alongside the interaction design issues covered above. Users need to feel that the app will not do something unexpected, will not lose their data, and will always give them a clear way back. Irreversible actions without confirmation dialogs are particularly damaging to trust in this cohort.

Recruit test participants through local libraries, NHS patient groups, or organisations like Age UK. Run tasks, observe without prompting, and note every hesitation. Those hesitations are your redesign brief.

The data visualisation and information density decisions that come up in ageing-population app design also map directly onto the broader challenge of designing data-dense interfaces that actually work, the same principle of ruthless information hierarchy applies whether your user is 30 or 70.

WCAG is necessary. It is not sufficient. Get the cognitive load right, size your targets properly, pick legible type, borrow from the NHS design system, and test with real older users. That is the actual brief.

September 21, 2026
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.

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.

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.

September 19, 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.

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.

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.

September 17, 2026
Designing Cookie Consent Flows That Don’t Destroy Your Conversion Rate: A UK PECR and ICO Compliance Guide

Here is the uncomfortable truth about most cookie banners: they were designed by lawyers, not designers. You can tell. They sit there like a passive-aggressive sticky note, blocking your content, hiding the reject button in a font size that would strain the eyes of someone half my age, and generally making a first impression that screams “we don’t actually want you to say no.” That is not just aesthetically grim, it is increasingly illegal. The ICO’s 2024 enforcement push against non-compliant consent mechanisms made clear that cookie consent UI design UK ICO PECR compliance is not a technicality you can paper over with a barely-visible opt-out link.

This piece goes through what PECR actually demands, what the ICO’s published guidance says about interface design specifically, and how to build a consent flow that is both genuinely compliant and not a conversion catastrophe. Because those two things are not mutually exclusive, they just require some actual design thinking.

Photo by Pixabay on Pexels

What PECR actually requires (without the legalese)

The Privacy and Electronic Communications Regulations 2003, PECR, sit alongside the UK GDPR and are enforced by the ICO. For cookies specifically, PECR requires prior, informed, freely given consent before any non-strictly-necessary cookie is set. That is the short version. The full version has some sharp teeth.

“Freely given” is where most implementations fail. If you pre-tick boxes, if accepting is one click but rejecting requires three, if you grey out the reject button or bury it in a “Manage preferences” submenu that takes six taps to navigate, that is not freely given consent. The ICO has been explicit: consent obtained through designs that nudge users towards acceptance does not meet the standard. They call these dark patterns, and they have published specific examples of what counts as one.

Strictly necessary cookies, those needed to make the site function, like session cookies, do not need consent at all. Everything else does. Analytics, advertising pixels, A/B testing scripts, heat-mapping tools, embedded YouTube players: all of these require prior opt-in unless you are routing them through a proxy that strips identifiers. That last option is genuinely worth exploring if analytics are your only concern, but it is out of scope here.

The dark patterns the ICO specifically flags

I would recommend reading the ICO’s updated cookie guidance directly, because it is more specific than most designers expect. The patterns they name include:

Asymmetric prominence. The “accept all” button is large, colourful, and high-contrast. The “reject” or “manage” option is smaller, greyed out, or styled as a text link. This visual hierarchy communicates a preference, which means consent is not freely given.

Forced interaction. Making users click through multiple screens to reject, whilst acceptance is one button. If it takes three steps to say no and one step to say yes, you have built a funnel, not a consent flow.

Confusing language. “Allow partners to use personalised data” is not informed consent. People need to understand what they are agreeing to. Plain English is not optional.

Consent walls. Blocking content access unless the user accepts all cookies. The ICO’s position is that this can undermine the “freely given” requirement, particularly where genuine alternatives to the service do not exist.

UI patterns that work without being ugly

The good news is that compliant does not mean clunky. Here is how I would build this.

Symmetric button styling

Give “Accept all” and “Reject all” equal visual weight. Same button size, same border treatment, same font weight. The only permissible difference is colour, and even then, use brand colours rather than a bright green accept versus a faded grey reject. Monochrome button pairs work particularly well: both buttons outlined, no fill, identical typography. Clean, considered, legally sound.

Three-option layouts

The most practical pattern for most UK product teams is a three-button row: “Reject all”, “Manage preferences”, “Accept all”. This gives users the quick binary choice if they want it, whilst making granular control available without friction. Put “Reject all” on the left, counterintuitive, but it signals confidence rather than reluctance. Users who are privacy-conscious will find it immediately; users who genuinely want to accept everything will still accept.

The modal vs banner question

Banners (bottom or top strips) tend to generate higher interaction rates but lower comprehension. Modals with a backdrop generate better-informed choices but disrupt flow more severely. For most sites, a centre-screen modal on first visit is the right call, it signals that the choice matters without being dismissive. Avoid full-screen takeovers; they are aggressive and associate your brand with the very dark patterns you are trying to avoid.

Preference panels worth building

The preference panel (reached via “Manage preferences”) is where most implementations fall apart. I have seen panels that list seventeen toggle switches with descriptions like “Audience measurement partner 4”, completely useless to an ordinary person. Build category-level toggles: Analytics, Marketing, Personalisation. Describe each in one sentence of plain English. Show which third parties are involved, but summarise rather than enumerate. Make the panel closeable without forcing a decision, some users just want to read before choosing.

If you are building this in a component library, the preference panel is a good candidate for a compound component pattern: a top-level ConsentPanel that takes category configs as props, renders toggle groups with associated descriptions, and emits a structured consent object that your tag manager or consent management platform can consume. Keep the state management simple, a flat object keyed by category slug is all you need.

Colour, contrast and accessibility

This connects to accessibility work more broadly. If you have been following guidance on designing for older users and accessibility for the over-55 audience, most of it applies directly here. Consent flows need to meet WCAG 2.2 AA contrast ratios; the ICO’s own published guidance references accessibility standards. Minimum 4.5:1 for body text, 3:1 for large text. Focus states on all interactive elements. No relying on colour alone to distinguish accept from reject.

Typography matters here too. Do not use a font size below 14px in a consent banner. Sixteen is more defensible. If you have been thinking carefully about your typography stack and system fonts, a consent modal is a good place to use a system font stack, it loads instantly, which matters given that consent must be presented before non-essential scripts fire.

Technical implementation notes

A few things I see trip up developers who are building consent flows from scratch rather than using a consent management platform (CMP).

First, no cookies should be set before consent is given. This sounds obvious but is violated constantly. If your analytics script fires on page load regardless of consent state, you are non-compliant before the banner has even rendered. Consent must gate script execution, not just set a preference that is read later.

Second, consent must be recorded and reproducible. You need to store what the user consented to, when, and which version of your policy was active at the time. A UUID per consent event, stored server-side, is the clean solution. Storing consent state only in a cookie is weakly circular and difficult to audit.

Third, consent must be withdrawable as easily as it was given. If your site has a footer link labelled “Cookie settings” that opens your preference panel, which was the mechanism for giving consent, that satisfies this requirement neatly. Make sure it actually works, and make sure it re-presents the panel with the current state rather than defaulting to all-off.

If you are building empty states into your consent flow (think: the preference panel before any categories have been toggled), there is a nice pattern for communicating status clearly covered in the piece on designing effective empty states for UK SaaS onboarding, the principle of communicating what will happen next applies well here.

Does any of this actually hurt conversion?

The honest answer is: a well-designed compliant consent flow will reduce your analytics data compared to a dark-pattern banner that coerces acceptance. That data was always unreliable anyway, because coerced consent produces noise rather than signal, people who clicked accept reflexively are not the engaged users your analytics should be modelling.

What it will not do is hurt your conversion rate in the sales funnel sense, provided the consent flow does not block content access. A modal that appears, presents a genuine choice, and dismisses cleanly adds perhaps two seconds to a user’s first visit. That is negligible against the reputational and legal cost of an ICO enforcement notice, which can run to fines of up to £500,000 under PECR, or higher under the UK GDPR framework that sits alongside it.

Build the consent flow as a real UI component, not an afterthought. Treat it with the same design rigour you would give a checkout flow or an onboarding sequence. That is the entire argument.

Frequently Asked Questions

What does PECR require for cookie consent in the UK?

PECR requires that you obtain prior, informed, and freely given consent before setting any non-strictly-necessary cookies. This means no pre-ticked boxes, no dark patterns that push users towards acceptance, and the ability to withdraw consent as easily as it was given. Strictly necessary cookies, session management, shopping baskets, are exempt.

Is a cookie banner enough to be ICO-compliant, or do I need a full consent management platform?

A banner alone is not sufficient; what matters is that non-essential scripts are genuinely blocked until consent is given, that preferences are recorded with a timestamp, and that users can change their choice later. A consent management platform (CMP) handles most of this, but you can build a compliant system from scratch if you implement the technical requirements correctly. The ICO does not mandate any specific tooling.

Are dark patterns in cookie consent actually enforced in the UK?

Yes. The ICO issued enforcement notices against major UK publishers in 2024 specifically citing non-compliant consent interfaces, including asymmetric button styling and buried reject options. Fines under PECR can reach £500,000, and the ICO has stated publicly that enforcement in this area is ongoing.

Can I style my accept button differently from the reject button?

Using different colours is acceptable provided there is no significant difference in prominence, size, font weight, and placement should be equal. The ICO’s guidance specifically flags making the reject option visually subordinate as a dark pattern. Monochrome, equal-weight button pairs are the safest approach.

Does a cookie consent modal affect page load performance or Core Web Vitals?

It can, but the impact is manageable. Using a system font stack in your consent modal avoids any additional font-loading overhead. The modal itself should be lightweight HTML and CSS, ideally inlined, so it renders before external scripts fire. Blocking non-essential third-party scripts until consent is given can actually improve your initial load performance, as those scripts are often the heaviest assets on the page.

September 16, 2026
How to Design Effective Empty States: The UI Pattern UK SaaS Products Consistently Underestimate

Empty states are the screens nobody designs until the last sprint. You know the ones: the blank table with no rows, the notification panel with nothing in it, the inbox on day one. Most UK SaaS products treat these moments as edge cases. I’d argue they’re some of the most consequential screens in your entire product, and getting them wrong is quietly killing your activation rates.

The idea behind empty state UI design is simple enough. When a user has no data, no content, and no history in a given context, what do they see? If the answer is a white box and a sad little grey sentence reading “No items found”, you’ve essentially handed a new customer a locked room and no key.

Photo by Tima Miroshnichenko on Pexels

Why empty states matter more than your onboarding flow

There’s a tendency in UK SaaS product teams to spend weeks on the formal onboarding wizard, complete with progress bars and illustrated walkthroughs, and then dump the user into an empty dashboard with zero guidance. The problem is that onboarding ends. Empty states don’t. A user who creates a new project, a new workspace, a new report, or a new team will hit an empty state every single time they do something new. That’s not an edge case; it’s a recurring event across the entire user lifecycle.

Slack does this brilliantly. Every new channel you create opens with a short message explaining the channel’s purpose and what a first message might look like. It costs almost nothing to implement and transforms what would be a void into a prompt. Notion does something similar with placeholder text in empty databases. These aren’t accidents; they’re the result of product teams treating empty states as part of the core UX, not an afterthought.

The three types of empty state and how to handle each one

Not all empty states are the same, and designing a single generic treatment for all of them is a mistake. I tend to split them into three categories.

First-use empty states appear when someone uses a feature for the first time and has no data yet. This is prime onboarding real estate. The design should explain what the feature does, show the user what the filled state will look like (even if just as an illustration), and give them a single, clear call to action. One button. Not three. The copy should be active and encouraging without being patronising.

No-results empty states happen after a search or filter returns nothing. These are different because the user has intent. They were looking for something specific. The design here should acknowledge what they searched for, suggest alternatives (fix the filter, broaden the search, check the spelling), and avoid making the user feel like they’ve hit a wall. If your product is a UK-facing B2B tool and someone searches for an invoice that doesn’t exist, the worst possible response is just “No results”.

Cleared or completion states occur when a user has genuinely finished something: an empty inbox, a completed task list, a fully processed queue. These deserve a moment of positive reinforcement. Something brief that says “you’re done” works better than the same blank void that appears everywhere else. The tone should feel different to the first-use state, because the context is totally different.

Copy is doing 70% of the work

Most empty state design discussions focus heavily on the illustration. And look, a well-crafted illustration helps. But I’ve reviewed products where a decent illustration sat above catastrophically bad copy, and the screens were still useless. The copy is doing most of the heavy lifting.

A few principles I come back to repeatedly. First: lead with what the feature does, not with what’s missing. “You haven’t added any team members yet” is worse than “Invite your team to start collaborating on projects.” One focuses on absence; the other focuses on possibility. Second: keep the call to action on the screen and make it obvious. Users who hit a blank state shouldn’t have to navigate somewhere else to fix it. If the empty state is a contacts list, there should be an “Add contact” button right there on the screen. Third: match the tone of your product voice. A fintech product aimed at UK accountants shouldn’t suddenly go whimsical with a cartoon dog in the empty state. Consistency matters.

The GOV.UK Service Manual has good underlying principles about clarity and plain language that translate usefully into SaaS copy, even if the style is obviously different. The core idea, that users shouldn’t need to think hard about what to do next, applies everywhere.

Illustrations: useful tool or distraction?

The illustrated empty state became almost universal in SaaS products around 2019 and I’ve watched it calcify into a cliché. Teams reach for an undraw.co illustration, drop it above a heading and a button, and call it done. That’s not necessarily wrong, but it’s rarely right either.

An illustration earns its place when it genuinely communicates something: the nature of the feature, what the filled state might contain, or a sense of scale. It doesn’t earn its place when it’s decorative filler that adds loading weight without adding meaning. For mobile especially, an oversized illustration that pushes the call to action below the fold is doing active harm.

If you’re working on a product that needs to feel serious, like a compliance tool, a legal SaaS, or anything facing UK regulated industries, an illustrated empty state can actually undermine trust. A clean typographic treatment with precise copy often performs better than anything illustrated. Test it. Don’t assume.

Empty states in dashboards: the hardest case

Dashboard empty states are particularly awkward because dashboards are often module-based. You might have eight widgets and only three have data yet. The result is a patchy grid of partially populated information and multiple empty modules, each with their own small sad state. This fragments the experience badly.

There’s a strong argument for using a progressive disclosure approach here: show only the modules the user has data for, surface the others as locked or greyed-out with a prompt to set them up. This is the approach I’ve seen work well in UK SaaS products that handle analytics or project management. It’s related to a broader point about structured layout thinking; the article on why British editorial and SaaS sites are returning to structured grid layouts has some useful thinking about how composition affects perceived completeness.

For data-heavy dashboards specifically, there’s real value in pre-populating with sample data. Show the user what their dashboard could look like with placeholder numbers, labelled clearly as sample data, so they understand the value proposition before they’ve put any real information in. Notion does a version of this with their templates. It’s honest, it’s useful, and it turns what would be a confusing blank grid into an immediate demonstration of product value. More on designing those kinds of interfaces in the piece on designing data-dense dashboards that actually work.

Testing your empty states properly

Most teams test empty states by manually clearing their test account and looking at the screen. That’s better than nothing. But the real test is watching a real new user hit an empty state for the first time and seeing what they do. Do they understand what the feature is for? Do they know what to do next? Do they feel lost or do they feel guided?

User testing sessions with participants who are genuinely unfamiliar with the product are invaluable here. If your team is based in the UK and doing any kind of remote testing through tools like Maze or UserTesting, recruit participants who match your actual user profile, not just whoever is convenient. You’ll learn things from a 45-year-old accountant in Birmingham navigating your empty transaction list that you’d never catch internally.

Typography also matters on these screens more than people expect. A well-chosen typeface with the right weight and spacing can make empty state copy feel considered rather than thrown together. If you’re still using system defaults without thinking about hierarchy, the piece on building a proper typography stack in 2026 is worth your time.

The bottom line is that empty states are not maintenance work. They’re product design work. Every time a UK SaaS product ships a blank white screen with two words of placeholder text, it’s leaving activation, retention, and trust on the table. The fix isn’t expensive. It’s just attention, and a bit of craft applied to the moments most teams skip.

September 14, 2026

Category: Design

The default chart is almost never the right chart

What Chart.js gets right and where it breaks down

Recharts: the React team’s comfort blanket

Observable Plot: the one serious developers should actually evaluate

The dashboard design mistakes that no library fixes on its own

Picking the right tool for real-world requirements

The constraint-first philosophy that makes GDS components work

Typography choices that build trust at a cognitive level

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

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

Spacing and layout: the 8px grid taken seriously

Making GDS constraints work outside a government context

Frequently Asked Questions

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

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

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

Why RTL is not just a text direction toggle

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

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

The mirroring rules most Western teams get wrong

Typographic considerations specific to Arabic and Urdu

Testing: you cannot eyeball RTL correctness

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

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

Container query units: the bit most tutorials skip

Browser support in 2026: the honest picture

Practical patterns for UK design systems

What the migration path looks like

Frequently Asked Questions

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

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

How do container queries affect the Figma handoff process?

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

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

What makes spatial typography different from screen typography?

The parallax problem: why text layers need spatial awareness

Contrast ratios don’t transfer from WCAG to spatial computing

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

Tracking, leading, and the third dimension

What typeface categories actually work in spatial computing?

The authoring gap: tools are still catching up

Cognitive load is the real killer, not contrast

Touch target sizing: the WCAG minimum is not enough

Font legibility goes further than size

NHS-informed interaction patterns worth stealing

Testing with real users, not assumptions

The gauge chart problem nobody wants to admit

EPC ratings as UI elements: where it goes badly wrong

The colour coding trap

What organisations like R2G reveal about the usability gap

Information hierarchy in sustainability UIs

Carbon data: the unit problem

What actually good looks like

Frequently Asked Questions

What is sustainability dashboard design?

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

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

What chart types work best for energy usage data?

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

The WCAG contrast ratios most teams get wrong

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

Building an accessible colour palette from scratch

Where UK product teams specifically trip up

The semantic colour system approach

Quick wins for teams starting from an inaccessible baseline

Frequently Asked Questions

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

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

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

Are UK websites legally required to meet colour accessibility standards?

What PECR actually requires (without the legalese)

The dark patterns the ICO specifically flags

UI patterns that work without being ugly

Symmetric button styling

Three-option layouts

The modal vs banner question

Preference panels worth building

Colour, contrast and accessibility

Technical implementation notes