Category: Design

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

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

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

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

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

    The WCAG contrast ratios most teams get wrong

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

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

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

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

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

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

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

    Building an accessible colour palette from scratch

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

    A few practical rules I use:

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

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

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

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

    Where UK product teams specifically trip up

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

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

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

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

    The semantic colour system approach

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

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

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

    Quick wins for teams starting from an inaccessible baseline

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

    Are UK websites legally required to meet colour accessibility standards?

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

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

    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.

    Clean cookie consent UI design showing equal-weight accept and reject buttons for UK ICO PECR compliance
    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.

  • How to Design Effective Empty States: The UI Pattern UK SaaS Products Consistently Underestimate

    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.

    Smartphone displaying an empty state UI design example relevant to SaaS UK product teams
    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.

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

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

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

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

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

    What clamp() actually does

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

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

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

    The interpolation formula you actually need

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

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

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

    slope = (24 - 16) / (1280 - 375) = 8 / 905 ≈ 0.00884
intercept = 16 - 0.00884 * 375 ≈ 12.685px

preferred = calc(12.685px + 0.00884 * 100vw)

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

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

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

    Calibrating for UK screen usage patterns

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

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

    My working defaults for a UK web project in 2026:

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

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

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

    Building a fluid type scale as design tokens

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

    A minimal token definition might look like:

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

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

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

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

    The line-length problem fluid type creates

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

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

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

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

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

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

    A practical integration checklist

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

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

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

    Worth mentioning: Utopia and similar tools

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

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

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

    Frequently Asked Questions

    What browsers support CSS clamp() for fluid typography?

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

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

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

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

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

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

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

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

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

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

    Why government data tools are the right case study

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

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

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

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

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

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

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

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

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

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

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

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

    Colour as data channel, not decoration

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

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

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

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

    Spacing is doing more work than you think

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

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

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

    What the Ofcom approach teaches us about filtering

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

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

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

    Making it work in practice

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

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

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

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

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

  • The Grid Is Back: Why British Editorial and SaaS Sites Are Returning to Structured Layout in 2026

    The Grid Is Back: Why British Editorial and SaaS Sites Are Returning to Structured Layout in 2026

    There’s a pattern I keep noticing across British product and editorial sites this year. The scroll-jacking is gone. The parallax fever dream of overlapping sections, pinned heroes, and elements that drift sideways as you scroll has largely been replaced by something almost aggressively tidy: columns. Gutters. Baseline grids. Structure you can actually see the logic of. Editorial grid layout web design 2026 UK isn’t a niche trend, it’s quietly become the dominant aesthetic choice across everything from fintech dashboards to newspaper websites, and the reasons are both practical and, well, a bit nerdy.

    Web designer viewing an editorial grid layout on screen, illustrating structured web design in 2026
    Photo by Ann H on Pexels

    What killed scroll-jacking (finally)

    Scroll-jacking had a good run. Around 2018-2022, it was the go-to technique for agency portfolios and brand marketing sites that wanted to feel cinematic. You’d hijack the browser’s native scroll behaviour and use JavaScript to control the rate and direction of movement, triggering animations and section transitions at precise points. It looked impressive in a Behance mockup. In production, it was a mess.

    The Core Web Vitals hit landed hard. Google’s Interaction to Next Paint (INP) metric, which replaced First Input Delay in 2024, measures responsiveness across the full lifecycle of a page visit. Scroll-jacking is basically an INP torture device. Hijacking scroll events means running JavaScript on every frame, which competes directly with the main thread and produces the jank that INP penalises. Sites that relied heavily on scroll-controlled animations started seeing their performance scores crater, and with them, their organic visibility.

    There’s a broader accessibility argument too. The WCAG 2.2 guidelines make it increasingly uncomfortable to implement scroll-jacking in any context where you’re serving a broad audience. Users with vestibular disorders can experience genuine physical discomfort from non-standard scroll behaviour. If you’ve been thinking about your design approach for older or more diverse users, losing scroll-jacking isn’t just a trend, it’s the right call.

    What “the grid is back” actually means in practice

    The return to grids isn’t about making everything look like a 1980s newspaper. It’s about reintroducing constraint as a design tool. A 12-column grid with consistent gutters and a clear baseline creates a framework inside which you can be expressive without being chaotic. Elements snap. Hierarchy is legible. Whitespace is intentional rather than accidental.

    The Guardian’s web redesign, which quietly rolled out properly across desktop in late 2025, is the clearest UK editorial example. Their layout uses a strict 12-column grid with clear section breaks, typographic rhythm tied to a baseline, and almost zero decorative animation. The result is genuinely fast and very readable. The Financial Times has operated on similar principles for years, and their design team publishes openly about why performance and structure are inseparable concerns.

    On the product side, look at what’s happening in British SaaS. Monzo’s marketing site, Notion’s UK-facing landing pages, and several of the Gov.uk Design System derivatives all share a common visual grammar: restrained column layouts, strong typographic hierarchy, and interactions that are functional rather than theatrical. This is editorial grid layout web design 2026 UK in its most mature form, structure borrowed from print, filtered through web performance constraints.

    Close-up of editorial grid layout typography on a website, demonstrating UK web design structure in 2026
    Photo by Ann H on Pexels

    The CSS behind the comeback

    CSS Grid was always capable of this. The tooling just needed to catch up with the ambition. In 2026, sub-grid support is solid across all major browsers, Chrome, Firefox, and Safari all handle grid-template-rows: subgrid correctly, which means child elements can align to the parent grid without hacks. This was genuinely difficult before and explains why a lot of designers gave up on strict grids and reached for JavaScript-driven layout instead.

    The practical pattern I use most often looks something like this: a top-level grid-template-columns: repeat(12, 1fr) layout with a defined gap, and then individual sections that inherit from that grid via subgrid. Editorial content modules, article cards, feature blocks, image-caption pairs, all stay aligned to the same column lines regardless of how deeply they’re nested. It produces exactly the kind of locked-in visual rhythm you see in well-produced print layouts, without any layout JavaScript at all.

    If you’re already thinking about how this interacts with your framework choice, there’s a useful overlap with the Astro vs Next.js discussion, Astro’s islands architecture pairs particularly well with grid-heavy, largely static editorial layouts because you’re not shipping unnecessary client-side JavaScript just to paint a grid.

    Why SaaS product teams are converging on the same patterns

    SaaS dashboards and editorial sites look very different on the surface, but they share the same underlying problem: lots of information, limited screen space, users who are busy and slightly impatient. The grid solves this for both. A well-considered column structure makes data modules predictable, users learn where to look for certain types of content, and their eyes stop bouncing around looking for anchor points.

    British B2B software teams in particular seem to have latched onto this. The white-labelling constraints of multi-tenant SaaS dashboards push designers toward grids almost by necessity, a layout that needs to accommodate multiple brand skins can’t rely on pixel-specific quirks. Column grids with semantic spacing tokens adapt cleanly across themes in a way that freeform layouts simply don’t.

    Agencies that work at the intersection of web design and business software are noticing the same convergence. Based in Mansfield, Nottinghamshire, dijitul, a digital agency with a focus on web design, SEO, and software-driven business efficiency, has seen client briefs shift markedly toward structured, grid-first layouts over the past 18 months. The reasoning their clients give tends to be practical: structured layouts are faster to build, easier to maintain, and perform better in marketing contexts where page speed directly affects conversion. You can find more about their approach at dijitul.uk.

    Grids, typography, and the system-font connection

    You can’t really talk about editorial grid layout web design 2026 UK without touching on typography, because the two are inseparable. A grid that isn’t tied to a typographic baseline is just a set of invisible lines. The real magic happens when your type sizes, line heights, and spacing units all derive from a common base unit, typically 4px or 8px, so that every element in the layout sits on a predictable rhythm.

    This is a big part of why the system font trend and the grid revival are happening simultaneously. System fonts have known metrics. You know Inter’s cap height, you know how SF Pro behaves at different weights, and you can build a baseline grid around those measurements with confidence. Custom web fonts introduce variables, FOUT, layout shift, inconsistent x-heights across weights, that make locking to a baseline harder. The typography stack choices you make in 2026 have direct implications for whether your grid actually holds at render time.

    What this means for performance budgets

    The performance case for structured grids is genuinely compelling, and I think it’s the argument that’s landed hardest with UK product teams who might otherwise have resisted the aesthetic shift. A CSS Grid layout with subgrid alignment replaces an enormous amount of JavaScript that was previously being used to calculate positions, trigger animations, and manage scroll states. Less JavaScript means smaller bundles, lower INP scores, faster Time to Interactive, and fewer opportunities for layout shift.

    For a typical UK editorial site serving, say, 500,000 sessions a month, a 15% improvement in INP (which is not an unrealistic gain from removing scroll-jacking JavaScript) translates to a measurable reduction in bounce rate and a modest but real improvement in Core Web Vitals scores. Those improvements compound into organic visibility gains over time. dijitul, whose web design work is closely tied to marketing performance and client business efficiency, makes exactly this point when positioning structured layouts to clients, the aesthetic choice and the commercial outcome are aligned, which is a rare and useful position to be in for any agency doing web design in a performance-conscious market.

    Is this a permanent shift or another cycle?

    Honestly, I think it sticks this time. Previous grid revivals in web design were often aesthetic statements, designers who’d grown tired of the dominant trend reaching for the opposite. This one has structural reasons behind it. WCAG compliance, Core Web Vitals, CSS subgrid maturity, and the operational reality of maintaining large design systems all point in the same direction. Structure wins on multiple fronts simultaneously.

    There’s also a generational factor. A lot of the designers now in senior positions at UK product companies trained on print or motion backgrounds where grids were non-negotiable. They always knew how to use them, they just needed the browser tooling to catch up. Now it has. The grid was never really gone. It was just waiting for CSS to be ready.

    Frequently Asked Questions

    What is an editorial grid layout in web design?

    An editorial grid layout is a structured design system based on columns and rows, typically 12 columns with consistent gutters, borrowed from print magazine and newspaper design. It gives every element on a page a logical position relative to a shared visual framework, creating predictable hierarchy and readable layouts.

    Why are websites moving away from scroll-jacking in 2026?

    Google’s Interaction to Next Paint (INP) metric penalises pages where JavaScript interferes with scroll and input response. Scroll-jacking relies heavily on main-thread JavaScript, which tanks INP scores and hurts search visibility. There are also accessibility concerns under WCAG 2.2, particularly for users with vestibular disorders who find non-standard scroll behaviour disorienting.

    How does CSS subgrid help with structured editorial layouts?

    CSS subgrid allows child elements to align to the parent grid’s column and row lines rather than creating an independent grid inside the component. This means nested modules, like article cards or media blocks, stay locked to the same column structure as the rest of the page, producing consistent typographic rhythm without any layout JavaScript.

    Are column-based grids better for performance than freeform layouts?

    Yes, in most practical cases. A CSS Grid layout replaces the JavaScript that scroll-jacking and animation-heavy layouts depend on. Removing that JavaScript reduces bundle size, lowers Interaction to Next Paint scores, and minimises Cumulative Layout Shift, all of which contribute to better Core Web Vitals and improved organic search performance.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Figma component strategies for multi-tenant dashboards

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

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

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

    Logo swapping and asset management across tenants

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

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

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

    Building the dashboard layout layer that works for every tenant

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

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

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

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

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

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

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

  • Open Source Font Pairing in 2026: The Combinations UK Designers Are Actually Using to Replace Paid Typefaces

    Open Source Font Pairing in 2026: The Combinations UK Designers Are Actually Using to Replace Paid Typefaces

    Adobe’s price hikes have focused a lot of minds. When Creative Cloud moved to a subscription model that charges separately for fonts, and when licensing costs for premium typefaces started appearing as actual line items in client budgets, designers started asking a question they’d previously avoided: what’s actually good in the free tier? The answer, in 2026, is: quite a lot. Open source font pairing for UK web design has moved well past the Roboto-and-Open-Sans era. The combinations available now are genuinely typographically interesting, and several of them are holding up at serious scale.

    I’ve spent a fair amount of time testing these in real projects, SaaS dashboards, brand identity work, high-traffic editorial sites, and the gap between paid and free has closed considerably. Not entirely. But enough that the default answer is no longer “just buy the licence.”

    Designer reviewing open source font pairing choices on screen for UK web design project
    Photo by cottonbro studio on Pexels

    Why open source typography is a serious option now

    The Google Fonts library has around 1,500 font families at this point, and the quality distribution has shifted. The bottom half is still mediocre. But the top tier, Inter, DM Sans, Fraunces, Instrument Sans, Hanken Grotesk, Be Vietnam Pro, these are professionally designed typefaces with full variable font support, extensive glyph coverage, and active maintenance. The Google Fonts Knowledge section has become a genuinely useful resource if you want to understand the design intent behind each family before you commit.

    Beyond Google Fonts, Fontshare (by Indian Type Foundry) is worth bookmarking. Their releases are fewer but consistently higher quality, Satoshi, Clash Display, Cabinet Grotesk. All free for commercial use. For UK SaaS teams that are burned out on Adobe dependencies, this is real breathing room.

    For the variable font angle specifically, I’d point you to the typography stack deep-dive already on this blog, it covers system font decisions and loading strategy in detail. This piece is specifically about pairing logic and which combinations are working in practice.

    Pairing one: Inter + Fraunces

    This is the one I keep coming back to for SaaS interfaces that want to feel considered rather than corporate. Inter handles everything at UI scale, labels, body copy, navigation, with the kind of legibility that makes it feel almost invisible in the right way. Fraunces is the contrast: a variable optical-size serif with a slightly quirky warmth to it, designed specifically to work at display sizes.

    The pairing works because they share nothing in common except quality. Inter is rational and neutral; Fraunces has personality. Use Fraunces for hero headings and pull quotes, Inter for everything functional. I’ve seen this combination in production at a Bristol-based HR tech firm and it reads as confident without trying too hard.

    Pairing two: DM Sans + DM Serif Display

    The DM family was designed by Colophon Foundry for DeepMind and then open-sourced, which is a remarkable bit of typographic history. DM Sans is clean and geometric; DM Serif Display is sharp, high-contrast, and genuinely elegant at large sizes. Because they share a design lineage, the pairing is almost unfairly harmonious.

    I’d use this for fintech or professional services interfaces, anywhere that needs to read as authoritative. If you’re building anything that touches financial regulation, the FCA compliance design guide here covers how typography choices intersect with readability requirements. DM Serif Display at the heading level passes contrast and legibility checks without needing tweaks.

    Printed font specimen showing open source font pairing options for web design
    Photo by Ann H on Pexels

    Pairing three: Instrument Sans + Playfair Display

    Instrument Sans came out of the Figma design team’s internal tooling and was released free on Google Fonts in 2023. It’s precise, slightly condensed, and works beautifully at smaller UI sizes. Playfair Display is the more established name here, it’s been around for over a decade, but it still delivers at hero scale, especially for editorial and media brands.

    A Manchester-based digital publisher I know switched to this combination after dropping their Adobe Fonts dependency, and the brand read as sharper afterwards. Sometimes the constraint forces the right decision.

    Pairing four: Hanken Grotesk + Lora

    Hanken Grotesk is underused. It’s a geometric sans with slightly softer terminals than Inter, which makes long-form body copy more comfortable to read. Lora is a well-kerned serif with roots in calligraphy, excellent for editorial pull quotes and subheadings in content-heavy interfaces.

    This combination suits content platforms, newsletter tools, and any interface where users are reading rather than scanning. The tonal warmth of both typefaces makes it feel less like software and more like a publication. For UK teams building for older demographics, pairing choices like this matter more than you’d expect, there’s a useful perspective on that in the guide on designing for over-55 users if that’s your audience.

    Pairing five: Cabinet Grotesk + Satoshi

    Both from Fontshare, both from the Indian Type Foundry. Cabinet Grotesk has a distinctive high-x-height and slightly retro feel at display sizes, good for startups that want personality. Satoshi is cleaner, more neutral, and handles UI body text comfortably.

    I’d use this for consumer apps and B2C SaaS where the brand is trying to feel approachable. It’s not a combination you’d reach for if you need to look like a bank. But for a fintech challenger brand, or a UK health app, the personality reads as intentional rather than accidental.

    What actually matters when testing pairings at scale

    Pairing lists are only useful if you test them in real conditions. A few things I’ve learnt from production use:

    Contrast ratio between the two typefaces needs to be perceptible but not jarring. If both fonts are grotesques, the pairing needs a clear size and weight differential or it collapses into sameness. Serif and sans combinations earn their contrast structurally, which is why they’re popular, but a poorly weighted serif at body size will destroy readability on mobile displays.

    Variable font axes matter more than you’d think. If both typefaces in your pairing support a weight axis, you can create a coherent weight scale across the whole interface. Fraunces, DM Sans, and Instrument Sans all support variable weight. Locking in a consistent optical weight across heading and body is the difference between a pairing that looks designed and one that looks assembled.

    Performance is the other variable. Google Fonts serves from a CDN and has good caching behaviour, but if you’re self-hosting (which you probably should be for GDPR compliance, UK ICO guidance on third-party font requests is worth reading), use font subsetting via tools like glyphhanger or the pyftsubset utility. Only serve the characters you actually need.

    Open source fonts and site visibility: a quick note

    Typography affects Core Web Vitals, and Core Web Vitals affect how Google ranks your pages. Font loading strategy, preconnect hints, font-display: swap, subsetting, directly impacts Largest Contentful Paint. If you’re doing solid typographic work but your site is still losing ground on search, it’s worth checking the technical side of your setup. Designers building sites for UK clients occasionally ask me whether there’s a quick way to audit the full picture without commissioning a formal technical SEO report. Search Engine Tuning, a UK-based free SEO check service, lets you run a check against your domains to see how Google is reading your site from a signals perspective, including page speed issues that font loading can trigger. The free SEO check at searchenginetuning.co.uk covers the fundamentals: Core Web Vitals, indexing status, and on-page signals that affect how your pages perform in search.

    It’s a useful sanity check, particularly if you’ve recently migrated fonts or restructured your type stack, and the result gives you something concrete to work from rather than guessing which change caused a rankings shift.

    On the topic of checking your SEO: if you’re using Google Fonts via the standard CDN import, you’re making a third-party request that can flag in an audit. Self-hosting your open source fonts and serving them from your own domain sidesteps that issue entirely, keeps your font loading predictable, and removes any ambiguity around data transfer to Google’s servers, which matters for UK clients operating under UK GDPR.

    A word on licensing confidence

    The SIL Open Font Licence (OFL) covers virtually everything in the Google Fonts library and all Fontshare releases. It’s permissive: you can use the typefaces commercially, embed them in products, and modify them (with some restrictions on reselling the fonts themselves). For UK agencies worried about client contracts, the OFL is clean, no per-seat restrictions, no web impression limits, none of the complexity that comes with commercial type licences. Check the licence file in the repository regardless, but in practice OFL is the safest free licence in the industry.

    The case for open source font pairing in UK web design has been building for years. In 2026, it’s no longer a compromise position. The pairings above hold up in production, pass accessibility checks, and carry none of the overhead that comes with managing a paid type licence across a client base. That’s not a small thing.

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

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

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

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

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

    How iPlayer handles content discovery without overwhelming you

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

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

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

    Accessibility as a structural decision, not a retrofit

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

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

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

    Multi-device consistency and where it gets complicated

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

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

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

    Performance design and the perception of speed

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

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

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

    The design system thinking underneath it all

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

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

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

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

  • How to Build a Freelance Design Portfolio That Ranks on Google in 2026: A UK-Specific SEO Breakdown

    How to Build a Freelance Design Portfolio That Ranks on Google in 2026: A UK-Specific SEO Breakdown

    Most freelance design portfolios are beautiful and invisible. The designer has spent weeks obsessing over the grid, the typeface, the hover states, and the case study photography, and then published it to a domain that Google has essentially never heard of. I’ve seen this pattern so many times it’s almost a genre. The portfolio exists; it just doesn’t rank. And if it doesn’t rank, UK clients pitching briefs into Google, which most of them are, will never find it.

    This guide is a proper technical walkthrough for getting your freelance design portfolio to show up in organic search in 2026. Not vague advice about “posting on LinkedIn”. Actual site architecture decisions, Core Web Vitals targets, schema markup you can implement today, and the local signals that genuinely differentiate you for UK clients. Let’s get into it.

    Freelance designer's workspace with portfolio site on screen, relevant to freelance design portfolio SEO UK 2026
    Photo by ready made on Pexels

    Why freelance design portfolio SEO UK 2026 is a different problem to generic SEO

    Portfolio SEO has a structural problem that most tutorials skip. You’re not an e-commerce site with thousands of product pages, and you’re not a blog with 200 posts. You have maybe six case studies, an about page, a contact page, and a services page if you’re organised. That’s a thin site, and Google treats thin sites with suspicion unless you compensate with strong signals elsewhere.

    The UK angle compounds this. If you’re a UX designer in Bristol or a brand identity designer in Leeds, you’re not trying to rank globally. You want to appear when someone in your target geography types “freelance UX designer Bristol” or “brand designer for fintech startups UK”. That’s local SEO intersecting with professional services SEO, and the signals that matter are slightly different from what a generic content-farm guide will tell you.

    The good news: the competition is weak. The overwhelming majority of freelance portfolios have no structured data, poor Core Web Vitals, zero local signals, and a flat site structure. Doing the basics well puts you ahead of most of the field.

    Site architecture: stop building a single-page portfolio

    Single-page portfolios are a death sentence for organic search. If everything lives on one URL, you have one chance to rank, and that one page has to fight for attention across every keyword simultaneously. Google can’t index what it can’t differentiate.

    The architecture I’d recommend is simple but specific. Give each major service its own page. If you do brand identity, UX design, and motion graphics, those are three pages with three distinct keyword opportunities. Give each case study its own URL, not a modal or a lightbox. Give your about page real content, not two sentences. And if you serve specific geographies or industries, build pages for those too: “UI design for fintech” or “brand identity for London startups” are genuinely searchable.

    Internal linking matters here. Each case study should link to the relevant service page. Your service pages should link to each other where they’re related. This is the same logic I covered in the piece on bento grid layouts for SaaS product pages, where the content hierarchy directly affects how users (and crawlers) understand what you do.

    Core Web Vitals targets for 2026

    Core Web Vitals are a confirmed ranking signal, and portfolio sites have an ironic tendency to fail them badly because designers love large images and JavaScript-heavy animations. Google’s PageSpeed Insights tool is free, takes thirty seconds, and will tell you exactly where you’re losing points. Run it on your homepage and every case study page.

    The three metrics to hit: Largest Contentful Paint (LCP) under 2.5 seconds, Cumulative Layout Shift (CLS) under 0.1, and Interaction to Next Paint (INP) under 200 milliseconds. LCP is usually your biggest problem because hero images and full-bleed case study photography are heavy. Fix it by serving images in WebP format, using loading="lazy" on below-the-fold images, and using fetchpriority="high" on your actual LCP element. CLS failures almost always come from images without explicit width and height attributes or from web fonts loading late and shifting text. Fix the first with explicit dimensions; fix the second with font-display: swap and preloading your critical fonts.

    INP is newer and measures responsiveness. If you’re running a React or Next.js portfolio (which many developers do after reading our Astro vs Next.js breakdown), watch your JavaScript bundle size. Unnecessary client-side hydration is the usual culprit. Astro’s partial hydration model is genuinely excellent for portfolio sites for exactly this reason.

    Schema markup that actually moves the needle

    Almost no freelance portfolios implement structured data. This is a free win.

    For a freelance design portfolio, three schema types are genuinely useful. First, Person schema on your about page: name, job title, description, and crucially sameAs linking to your LinkedIn, GitHub, Dribbble, and any other authoritative profiles. This helps Google build a knowledge graph entity around you as a professional, which strengthens trust signals across your whole site.

    Second, LocalBusiness schema if you work with local clients. Yes, you can use this as a freelancer. Include your city, your service area, and your contact details. Make sure these match exactly what you have on your Google Business Profile. Consistency between your schema and your GBP listing is a genuine local ranking signal.

    Third, CreativeWork or WebPage schema on case study pages, with author referencing your Person entity. This connects your work back to you as the creator in a machine-readable way. None of this is technically difficult: it’s JSON-LD you drop into a <script> tag in the <head>, and Google’s Rich Results Test will validate it in seconds.

    Local SEO signals for British designers

    If you want to rank for location-specific queries, which you absolutely should if you’re pitching to UK clients, you need to treat your portfolio like a local business online. Set up a Google Business Profile under your name or your trading name, categorised as “Graphic Designer” or “Web Designer”. Add your city to your page titles, your H1s, and your meta descriptions. Not stuffed; just present. “Freelance brand designer, Manchester” in your title tag is perfectly natural.

    Get citations. In the UK, the useful ones are Yell.com, Bark.com, Clutch.co (which has a strong UK presence), and FreeIndex. These are directories that Google actually pays attention to for local professional services. Your name, trading name, and contact details need to be consistent across all of them. Use the same format every time: same spelling, same phone number format, same postcode.

    Reviews matter more than most designers think. Even five genuine Google reviews from past clients will give you star ratings in local search results. Ask clients directly after a project wraps. Most won’t think to do it unprompted, but most are happy to write one if you send them a direct link.

    Content that supports your portfolio without bloating it

    A small blog or insights section can do serious work for your portfolio’s organic visibility without requiring you to become a content machine. The trick is to write for the intersection of what you know and what your target clients are searching for. A post about “how to brief a brand designer” written from a designer’s perspective will rank for searches that UK marketing managers and founders actually type. A post about your process for UX audits will attract clients who already know they need one.

    This is also where you can build topical authority. If your case studies are all fintech work, a few posts about designing for financial services, FCA compliance in UI, or what good fintech onboarding looks like will cluster your site around that niche. Google’s understanding of what your site is about is built from the whole, not just the homepage. I’d keep each post genuinely useful: 600 words of real expertise beats 1,500 words of padding every time. And if you’re the kind of designer who also codes, pieces like our TypeScript introduction for UK designer-developers suggest the territory worth covering, where technical specificity is the differentiator.

    The technical checklist before you publish

    A few things to verify before you consider the site ready. Your robots.txt should allow crawling; it sounds obvious but I’ve seen portfolios inadvertently blocking Googlebot from staging configs carried over to production. Submit an XML sitemap via Google Search Console and verify your domain there: both the www and non-www versions if you haven’t explicitly chosen one and set a canonical. Make sure your HTTPS is properly configured with no mixed content warnings, since Google has treated HTTPS as a lightweight ranking signal for years. Check that your canonical tags point to the right URLs and that you’re not accidentally indexing paginated or filtered views that duplicate content.

    Run Screaming Frog on your domain (the free version handles up to 500 URLs, which is plenty for a portfolio) to catch broken links, missing meta descriptions, and duplicate title tags. Fix those before you build links or push for rankings. The foundation has to be solid or the rest of the work is wasted.

    Freelance design portfolio SEO in the UK isn’t glamorous work. It’s structured data in a text editor, image compression, and directory submissions. But it compounds. The designer who does this in January and publishes two genuinely useful blog posts a quarter will be fielding inbound enquiries by the end of the year from clients they never had to cold-pitch. That’s the whole point.

    Frequently Asked Questions

    How long does it take for a freelance design portfolio to rank on Google?

    For a new domain with good technical foundations, expect three to six months before meaningful organic traffic appears. If you’re targeting low-competition local queries like “freelance designer [UK city]”, you can sometimes see results faster, particularly if you have a complete Google Business Profile and a handful of citations from UK directories.

    Do I need a blog on my portfolio to rank in UK search results?

    Not strictly, but it helps significantly. A blog lets you target informational keywords that your target clients search for, and it builds topical authority around your niche. Even four to six well-written posts per year can meaningfully expand the number of queries your portfolio ranks for.

    What's the best platform for building a portfolio that ranks well?

    Anything that gives you full control over your HTML, meta tags, and structured data. WordPress with a lightweight theme, Astro, or Framer (which now has solid SEO controls) are all solid choices. Avoid platforms that lock your content behind JavaScript rendering without server-side rendering, as Googlebot can struggle with purely client-rendered content.

    Does my Google Business Profile matter if I work remotely with clients across the UK?

    Yes. Even remote freelancers benefit from a GBP listing because it gives you visibility in local pack results when clients search in your city. Set your service area to the regions you actually serve. You don’t have to list a physical address publicly if you work from home.

    How many case studies do I need for good SEO on a freelance portfolio?

    Quality beats quantity. Three to five detailed case studies, each on its own URL with a proper description of the brief, your process, and the outcome, will outperform ten brief project thumbnails on a single page. Give each case study page a unique title tag and meta description targeting the specific type of work it represents.

The Latest