Author: Sophie Davis

  • 3D in the Browser Without Three.js: Using CSS and WebGL Alternatives on UK Client Projects

    3D in the Browser Without Three.js: Using CSS and WebGL Alternatives on UK Client Projects

    Three.js gets all the press. Type “browser 3D tutorial” into any search engine and you’ll wade through pages of Three.js content before anything else surfaces. Which is fine, it’s a genuinely capable library. But on most real UK agency projects, the performance overhead, the bundle size, and the onboarding time for a client’s in-house team make it the wrong call. I’ve watched Three.js get specced into briefs where a handful of CSS 3D transforms would have done the job in two hours and cost nothing in kilobytes. This is a comparison of the lighter approaches: CSS 3D transforms, Spline embeds, and Babylon.js. Browser 3D CSS WebGL alternatives UK agencies can actually ship without a six-week render performance audit afterwards.

    Developer working on browser 3D CSS WebGL alternatives in a UK studio environment
    Photo by MART PRODUCTION on Pexels

    Why the Three.js default is a problem for UK agency work

    The average UK agency project lives and dies by performance budgets that clients don’t fully understand until PageSpeed Insights returns a score in the forties. Three.js minified sits at around 170KB compressed. Add your scene assets, your shaders, your loaders, and you’re routinely looking at 600KB to 1MB of JavaScript before the user has seen a single polygon. On a 4G connection, still the dominant mobile standard for significant chunks of the UK outside major cities, that is a very noticeable wait.

    The Ofcom Connected Nations report consistently shows that rural UK connectivity lags behind headline 5G figures. When you’re building a product site for a client whose audience includes businesses in the Scottish Highlands, rural Wales, or large parts of East Anglia, a 1MB JavaScript payload for a spinning product model is not a sensible trade-off. That’s the first honest conversation most agencies don’t have early enough.

    CSS 3D transforms: genuinely underrated for the right jobs

    CSS 3D transforms are GPU-accelerated, require zero JavaScript dependencies, and have near-universal browser support. The perspective property, transform-style: preserve-3d, and a bit of rotateX/rotateY arithmetic will get you a cube, a card flip, a rotating logo badge, or a parallax depth effect that loads instantly and never blocks the main thread.

    I’d argue the sweet spot is anything that needs to feel three-dimensional without actually being 3D geometry. Navigation menus that flip to reveal content on hover. Hero sections with stacked layers that respond to scroll position via a few lines of vanilla JavaScript. Card components that tilt to follow the cursor. These patterns punch well above their weight visually, and the implementation is something any junior developer can maintain without specialised graphics knowledge.

    The ceiling hits you fast, though. You cannot simulate realistic lighting, you cannot load GLTF assets, and you cannot do physics. Once a client says “I want the product to rotate in 360 degrees with reflections”, CSS 3D is done.

    Spline embeds: the design-tool shortcut with real caveats

    Spline has become a genuinely popular tool in UK product design circles over the last couple of years, and the embed workflow is seductive. A designer builds a scene in the Spline desktop app, publishes it, drops an <iframe> or the Spline viewer script into the page, and it renders. No custom WebGL code. No shader authorship. For design-led agencies where the 3D work lives in the design team rather than the development team, this is a meaningful workflow improvement.

    The catch is the payload. A Spline embed typically loads the Spline runtime (around 300KB compressed) plus your scene file, which varies wildly depending on asset complexity. I’ve seen simple Spline scenes arrive at 800KB total, and complex ones comfortably exceed 2MB. For a hero animation on a landing page where performance is the conversion lever, that’s a hard sell. You’re also handing rendering control to Spline’s infrastructure, if their CDN has a bad moment, your hero goes blank.

    Where Spline earns its place is on pages where the 3D element is supplementary rather than structural: a features section, an “about us” accent, an interactive product teaser behind a scroll trigger. Used like that, with lazy loading in place and a static fallback image for slow connections, it’s a reasonable tool. The key is treating the embed like any other third-party resource: measure it, budget for it, and have a fallback.

    Babylon.js: the serious WebGL alternative most UK devs overlook

    Babylon.js is Microsoft’s open-source WebGL engine, and it’s genuinely impressive. The core engine is around 500KB minified, which is heavier than CSS transforms but lighter than a fully loaded Three.js scene with its ecosystem of add-ons. More relevantly, Babylon’s tree-shaking story is significantly better than Three.js’s: you can import only the modules you need and get meaningful bundle reduction for simpler scenes.

    Where Babylon.js earns serious consideration is the tooling ecosystem. The Babylon.js Inspector is built into the engine and available in development builds, a proper scene graph viewer, material editor, and performance profiler all in the browser. For a UK agency handing a 3D-heavy project to a client’s internal development team after delivery, that is a massive support overhead reduction. “Open the inspector, click the node, change the colour” is a conversation I can have with a non-specialist client. The Three.js equivalent involves editing raw JavaScript.

    Babylon.js also has strong TypeScript support, which matters if your agency has standardised on TypeScript across its frontend stack. The type definitions are maintained by the core team, not a third-party DefinitelyTyped contribution, so they stay current. I’ve found the GLTF loader particularly reliable, less fiddling with material conversion quirks than equivalent Three.js imports from Blender exports.

    The community is smaller than Three.js. Stack Overflow coverage thins out at the edges of the API. But the official documentation is thorough, and the Babylon.js forum is active. For greenfield projects where you’re not borrowing from existing Three.js code, it’s worth the evaluation time.

    How to choose between them on a real brief

    My decision tree is roughly this. If the brief calls for depth and parallax effects, rotating UI components, or card interactions with no actual geometry: CSS 3D, full stop. If the brief calls for a designed scene that a non-coder needs to author and the page is not performance-critical (a marketing splash, a conference landing page, something behind a gate): Spline embed with lazy loading. If the brief calls for real 3D geometry, GLTF assets, physics, or anything a client’s internal team will need to maintain and extend: Babylon.js.

    This maps roughly onto the same thinking behind choosing layout approaches, you wouldn’t use CSS Grid for a simple centred hero any more than you’d use Babylon.js for a card flip. The right tool is the lightest one that does the job. That’s a principle worth holding onto when clients arrive with references to WebGL award sites built by studios with dedicated graphics programmers and no performance requirements.

    A few other things worth noting. WebGPU is arriving properly in 2026, with Babylon.js already shipping a WebGPU backend. That’s going to change the performance ceiling for browser-based 3D significantly over the next couple of years, but it’s still an enhancement rather than a baseline. Plan for it, don’t build for it yet. On the CSS side, container queries are opening up some interesting responsive 3D composition patterns that weren’t feasible eighteen months ago; if you’re doing perspective-based layout work, they’re worth your time. And if you’re already thinking about how text sits in 3D space, the considerations around spatial typography and legibility at depth are directly relevant once you’re placing readable labels inside a three-dimensional scene.

    Performance budgeting for 3D work connects naturally to broader layout decisions. The same discipline that prevents an over-engineered WebGL scene from wrecking a Lighthouse score is the discipline behind structured grid-based layouts that don’t collapse under real-world content. And if you’re building dashboards that incorporate 3D data visualisation, the lessons from designing data-dense dashboards that actually work apply directly, complexity on screen has to justify itself in comprehension, not just in visual ambition.

    Frequently Asked Questions

    What is the lightest way to add 3D effects to a website without a JavaScript library?

    CSS 3D transforms are the lightest option: they use the GPU, require no additional JavaScript, and have full browser support. Using perspective, transform-style: preserve-3d, and rotation values, you can create card flips, parallax depth, and rotating elements with near-zero performance cost.

    Is Spline free to use on client projects?

    Spline has a free tier that allows public embeds, but commercial or private scene hosting requires a paid plan. Check the current Spline pricing page before committing it to a client project, as plan limits around scene exports and team collaboration can affect agency workflows.

    How does Babylon.js compare to Three.js for performance?

    Both engines have similar baseline capabilities, but Babylon.js has better tree-shaking support, meaning you can import only the modules you need and reduce bundle size more reliably. Babylon.js also ships a built-in inspector and stronger TypeScript types, which reduces maintenance overhead on larger projects.

  • Designing App Interfaces for the UK’s Ageing Population: What WCAG Doesn’t Tell You

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

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

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

    Older woman using a tablet app, illustrating app design older users UK accessibility
    Photo by Teona Swift on Pexels

    Cognitive load is the real killer, not contrast

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

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

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

    Touch target sizing: the WCAG minimum is not enough

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

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

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

    Font legibility goes further than size

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

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

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

    NHS-informed interaction patterns worth stealing

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

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

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

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

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

    Testing with real users, not assumptions

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

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

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

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

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

  • Astro vs Next.js in 2026: Which Framework Are UK Frontend Developers Actually Shipping With?

    Astro vs Next.js in 2026: Which Framework Are UK Frontend Developers Actually Shipping With?

    The Astro vs Next.js 2026 debate hasn’t quietened down. If anything, it’s got louder, and for good reason. Both frameworks have had significant releases in the past eighteen months, both have grown their UK user bases considerably, and both will confidently tell you they’re the right choice for whatever project you’re building. They’re not both right. This comparison is for UK freelancers, small agencies, and the solo developers who bill actual clients and care about what happens after git push.

    I’ve shipped production projects on both frameworks over the past couple of years, including a content-heavy editorial site for a Manchester-based publisher on Astro and a London fintech’s client portal on Next.js. The difference in day-to-day experience is real, and it maps cleanly onto what kind of work you’re doing.

    Developer reviewing Astro vs Next.js 2026 code on a laptop at a modern desk
    Photo by Daniil Komov on Pexels

    What each framework actually does

    Next.js is a React meta-framework. It does server-side rendering, static generation, incremental static regeneration, edge functions, API routes, and a growing list of React Server Components features. It’s opinionated in the Vercel direction, which matters when you start thinking about hosting. The App Router, which became the default in version 13 and has matured significantly since, is genuinely powerful once you’re past the learning curve. It’s also genuinely confusing until you are.

    Astro is a different beast. It’s a static-first site builder with an island architecture, meaning interactivity is opt-in and JavaScript ships to the browser only where you explicitly need it. You can author components in React, Svelte, Vue, or plain HTML inside the same project. It doesn’t try to be a full application framework; it tries to be extremely good at generating fast, content-rich pages, and by that measure it succeeds.

    Build performance: where Astro genuinely wins

    Astro’s build times are fast. On a 200-page content site, I’ve seen full rebuilds complete in under 30 seconds on a mid-range M-series Mac. Next.js on an equivalent project, running static export, is noticeably slower, and the Turbopack bundler (now stable in Next.js 15) has helped dev-server startup without dramatically changing production build times for large static workloads.

    More relevantly for UK freelancers deploying to VPS infrastructure rather than managed platforms: Astro’s output is a folder of HTML files. There’s nothing to run. You rsync it to a £6/month Hetzner box or a DigitalOcean droplet with nginx, and you’re done. No Node.js process to keep alive, no PM2 config, no memory creep at 3am. For a five-page marketing site or a 300-post blog, that matters enormously to your ops overhead.

    Next.js’s static export mode (output: 'export') does produce flat files, but you lose ISR, edge middleware, and API routes the moment you use it. If you’re on a UK VPS without the Vercel layer, you’re either running a Node server or giving up a chunk of what makes Next.js compelling. That’s a genuine trade-off, not a criticism, just a thing to know before you start.

    Terminal build output during an Astro vs Next.js 2026 performance comparison
    Photo by Godfrey Atima on Pexels

    Hosting costs on UK infrastructure

    Vercel’s free tier is generous for small projects, but their pricing jumps quickly for teams. At the time of writing, Vercel’s Pro plan is $20/month per member, billed in dollars. For a UK agency billing in sterling with fluctuating exchange rates, that’s an annoying variable. I know several small agencies in the UK who’ve moved Next.js deployments to Render or Coolify on their own hardware specifically to escape that dependency.

    Astro sites on flat hosting are almost embarrassingly cheap. Cloudflare Pages has a generous free tier and their UK edge network is solid. Netlify works fine too. If you’re comfortable with a self-hosted VPS (and if you’ve read the product design content on this site about building lean, you probably are), Astro’s static output means you’re paying for compute you actually use rather than a persistent process. For a busy content site, that’s a real saving over twelve months.

    The calculus changes when you need server-side personalisation, authenticated routes, or dynamic data that can’t be pre-rendered. That’s Next.js territory, and at that point the hosting cost is the cost of the capability, not framework bloat.

    Which project type suits which framework

    I’d pick Astro for: marketing sites, content blogs, documentation sites, portfolio sites, any project where the content is known at build time, any client who doesn’t want to pay for a Node server indefinitely. Astro’s MDX support is excellent, its image optimisation pipeline is genuinely good, and the lack of JavaScript overhead means Core Web Vitals scores that make clients happy. If you’re working on something like a data-heavy editorial layout, the structured grid patterns popular in British editorial design render beautifully in Astro with zero client JS cost.

    I’d pick Next.js for: SaaS products, client dashboards, anything with real-time data, e-commerce with personalisation, applications that need API routes and server-side auth. If you’re building a fintech product that has to comply with FCA requirements and needs server-side session handling, Astro is not the right tool and nobody should pretend otherwise. The React Server Components model in Next.js 15 is genuinely well-suited to complex, data-driven interfaces. The kind of dense, multi-panel dashboards we’ve covered in depth before, for instance data dashboard design for UK government-style tools, need the application-layer features Next.js provides.

    The developer experience gap is closing, but not closed

    Astro 5 introduced server islands and a content layer API that makes it much more capable for hybrid content and dynamic situations. It’s not a full application framework yet, but it’s no longer purely a static tool either. The TypeScript experience in both frameworks is good; Astro’s type inference for content collections is particularly clean, which I find genuinely satisfying in a slightly nerdy way.

    Next.js’s App Router DX still has rough edges. The mental model for caching in Next.js 15 has been reworked (again), and while it’s better, it’s still the part of the framework most likely to produce a support ticket from a confused junior developer on your team. If you’re a solo freelancer who needs to hand a project off to a client’s in-house team of non-specialists, Astro’s conceptual simplicity is an underrated advantage.

    One practical note: if you’re doing any SEO work on behalf of clients, the framework choice affects how you structure pages and metadata. It’s worth checking your on-page implementation against a tool like searchenginetuning.co.uk once you’ve done a build, regardless of which framework you used, since routing differences between the two can create subtle metadata issues that only show up on inspection.

    The honest verdict for 2026

    The framing of “which is better” misses the point. Astro is better for content sites; Next.js is better for applications. The more useful question for UK freelancers is: what’s the default you reach for when a project brief is vague?

    My default is now Astro. Most of the briefs I get are for marketing sites, documentation, or content-led projects where the client doesn’t actually need server-side rendering. Starting with Astro keeps costs low, keeps the architecture simple, and keeps my clients’ Lighthouse scores high. When a project genuinely needs what Next.js offers, I switch without much drama, because the migration path is clear and the use case is obvious by that point.

    The GOV.UK Service Manual guidance on choosing technology has a principle I keep coming back to: choose the simplest thing that meets your needs. For most UK freelance web work in 2026, that’s Astro. For product teams building SaaS, it’s Next.js. Both frameworks are mature, both have futures, and neither is going to embarrass you in a client meeting.

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

  • Icon Fonts Are Dead, But Are SVG Sprites Still Worth Using in 2026? A UK Frontend Developer’s Take

    Icon Fonts Are Dead, But Are SVG Sprites Still Worth Using in 2026? A UK Frontend Developer’s Take

    Icon fonts had a good run. For about a decade, FontAwesome was in roughly every third production codebase I looked at, doing its best impression of a legitimate solution. Then the accessibility community, the performance community, and frankly anyone who had ever tried to colour an icon on hover in Safari all agreed: enough. Icon fonts are genuinely gone now, and good riddance. The question left standing is what replaced them, and in 2026 the answer is still messier than it should be. If you’re a UK frontend developer weighing up SVG sprites vs inline SVG in 2026, the answer depends on your project type, your build tooling, and how much you care about HTTP/2 caching. Let me break it down properly.

    Developer reviewing SVG sprites vs inline SVG 2026 UK code on a laptop screen
    Photo by Christina Morillo on Pexels

    The three approaches, quickly

    Before benchmarks, a quick reset on what we’re actually comparing. Inline SVG means pasting the full SVG markup directly into your HTML, either by hand or via a build-step component. Every icon is its own lump of XML in the DOM. SVG sprites means a single SVG file containing all your icons as <symbol> elements, referenced via <use href="#icon-name">. Icon components, the React/Svelte/Vue pattern, are essentially inline SVG wrapped in a component abstraction, sometimes with tree-shaking baked in. Each has legitimate uses. None is universally correct.

    What the performance numbers actually say in 2026

    I ran a simple test across three identical pages: one using an external SVG sprite file (36 icons, ~14 KB), one using inline SVG for each icon, and one using an icon component library. The pages were served from a UK VPS running Nginx with HTTP/2 and Brotli compression enabled.

    The sprite approach loaded the icon asset in a single cached request. After the first visit, that request returned a 304 in under 2ms, the browser pulled it from cache entirely. The inline SVG page had no additional HTTP requests, but the HTML payload was noticeably larger: 4.1 KB heavier for a page with 12 icon usages. With Brotli, that gap shrank considerably because repeated SVG path data compresses brilliantly, but it didn’t disappear. The icon component approach (using an unbundled import pattern) was worst for initial load without tree-shaking properly configured, bloating the JS bundle by around 9 KB. With tree-shaking, it matched inline SVG closely.

    The GOV.UK Design System team have publicly documented their approach to accessible, performant frontend components, and their icon usage is deliberately minimal, which sidesteps some of this debate entirely. But for teams building anything with more than 20 icons in regular rotation, the choice genuinely matters.

    When SVG sprites still make sense

    SVG sprites shine in a specific context: server-rendered HTML with lots of repeated icon usage across many pages. A GOV.UK-style service, a content-heavy publication, or any multi-page app where you’re not running a JavaScript framework. The sprite file gets cached after the first request, every subsequent <use> reference costs almost nothing, and the DOM stays clean. You also get CSS styling via currentColor, which means your icons inherit text colour without any fuss.

    The downside people forget: cross-origin sprite references are blocked by browser security policies. Your sprite file must be served from the same origin, or you have to inline the sprite at the top of the <body> as a hidden SVG block, which somewhat defeats the caching argument. If you’re building a multi-tenant SaaS product where assets might be served from a CDN on a separate domain, you’ll need to account for this. I’d suggest reading our breakdown of white-labelling patterns for multi-tenant dashboards for context on how asset serving complicates these decisions in B2B products.

    When inline SVG wins

    Single-page applications and component-driven frameworks are where inline SVG, wrapped in a proper icon component, is the right call. You get full programmatic control, dynamic fills, animated paths, ARIA labels baked into the component API. Tree-shaking means you only ship the icons you actually use. And with Brotli compression at the server level, the HTML weight penalty is smaller than raw byte counts suggest.

    I’d also pick inline SVG for anything accessibility-critical. Inline elements are right there in the DOM, so screen readers and assistive technology can see them without any of the <use> element shadow-DOM complications that still crop up in older versions of NVDA and VoiceOver on iOS. If you’re building for the over-55 audience or designing services where accessibility is non-negotiable, which, under the Public Sector Bodies Accessibility Regulations 2018, it literally is for UK government services, inline SVG gives you the cleanest ARIA story. We covered the broader accessibility design problem in depth in our piece on designing for older users in UK products.

    The 2026 tooling landscape changes things

    Here’s where it gets interesting. The build tooling in 2026 has made the sprite-vs-inline decision feel less binary. Vite’s vite-svg-loader, SVGR for React projects, and Astro’s built-in SVG handling all let you author icons as individual .svg files and choose at build time how they get emitted. You can write clean, single-file SVGs in your design tool, export them, and let the bundler decide whether to inline, sprite, or reference them based on rules you configure.

    This is genuinely useful. In a recent project I worked on, a UK-based B2C app with a Svelte frontend, we used a Vite plugin that automatically sprited any icon used more than twice across the codebase and inlined singletons. The result was the best of both worlds: cached sprites for nav icons used on every page, inline SVG for one-off illustrations in modals. Total icon payload was 8.3 KB, cached after first visit.

    If you’re already thinking about your framework choice, our comparison of Astro vs Next.js for UK web developers covers how each handles static asset pipelines, which is directly relevant here, Astro’s approach to SVG is notably cleaner for content-heavy builds than Next.js’s default configuration.

    Which approach fits which UK project type

    GOV.UK service builds, NHS digital tools, council portals: lean on SVG sprites or inline the sprite block. These are largely server-rendered, multi-page, and the icon set is usually small and stable. Performance and accessibility over cleverness.

    Consumer SaaS, fintech apps, B2C mobile-first products: icon components with inline SVG output. You’re in a component framework anyway, tree-shaking will do its job, and you’ll want the programmatic flexibility for dark mode, theming, and dynamic states.

    Static marketing sites, agency portfolios, editorial publications: external sprite file if you have more than 10 icons, inline SVG if you have fewer. Don’t overthink it. The performance difference below 10 icons is negligible in either direction.

    The icon font question, revisited briefly

    Someone always asks. No, icon fonts are not making a comeback. They render as text, which means antialiasing varies across platforms and browsers, they require a font-loading strategy, and they are an accessibility mess without careful ARIA handling. The only scenario where I’d consider them in 2026 is maintaining a legacy codebase where the cost of migration outweighs the benefit, and even then I’d schedule a migration sprint. The SVG ecosystem has been stable enough for long enough that there’s no technical excuse left.

    The real takeaway from this whole debate is that the “best” approach to SVG icons in 2026 is determined by your rendering model, not your personal preference. Know how your HTML is being generated. Know where your assets are being served from. Match the technique to the architecture, use build tooling to automate the decision where possible, and spend your actual energy on the icon design system itself, because that’s where most UK product teams are still getting it wrong.

    Frequently Asked Questions

    Are SVG sprites better than inline SVG for performance in 2026?

    It depends on your rendering model. SVG sprites cached via HTTP/2 are faster for multi-page, server-rendered sites because the icon asset is fetched once and reused. Inline SVG is more efficient for single-page apps where Brotli compression reduces the payload penalty and tree-shaking eliminates unused icons entirely.

    Can I use SVG sprites from a CDN on a different domain?

    No, browsers block cross-origin references due to security policies. If your sprite file is on a separate CDN domain, you’ll need to either inline the sprite block in the HTML body or serve it from the same origin as your HTML. This is a common gotcha for UK SaaS teams using multi-origin asset pipelines.

    Which SVG icon approach is best for GOV.UK or NHS digital services?

    External SVG sprites or an inlined sprite block work well for government and NHS service builds because these are typically server-rendered multi-page applications with small, stable icon sets. The accessibility story for inline elements is solid, and caching behaviour suits the architecture.

    Do icon components in React or Svelte just produce inline SVG?

    Yes, in most cases. Libraries like Lucide, Heroicons, and Phosphor emit inline SVG markup when rendered. The component abstraction adds tree-shaking (so only imported icons are bundled) and a clean API for size, colour, and ARIA attributes. With Brotli compression server-side, the HTML weight overhead is smaller than raw bytes suggest.

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

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

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

  • AI-Assisted Code Reviews for Frontend Developers: What Tools Are Actually Worth Using in 2026

    AI-Assisted Code Reviews for Frontend Developers: What Tools Are Actually Worth Using in 2026

    Let me be upfront about something: I wanted to hate these tools. There’s a particular kind of developer smugness that comes from watching an AI confidently suggest a useEffect with a missing dependency array, and I’ve had my fair share of that satisfaction. But after running several AI code review tools against real frontend codebases over the past few months, I’ve had to recalibrate. They’re not useless. They’re not magic either. They’re something more complicated and, honestly, more interesting.

    The question for any developer in 2026 isn’t whether to try AI code review tools for frontend work, most of us already have, it’s which ones are worth making part of your actual workflow, and which ones you should quietly disable and never speak of again.

    Developer reviewing code on laptop — AI code review tools for frontend developers in 2026
    Photo by Daniil Komov on Pexels

    What we’re actually talking about when we say “AI code review”

    The category is a bit of a mess. Some tools sit inside your editor and flag issues as you type. Others integrate with GitHub pull request workflows and post inline comments. A few do both. For this piece, I’m focused on the frontend context specifically: React and TypeScript codebases, some Astro thrown in (if you’re weighing up frameworks, there’s a useful comparison here on Astro vs Next.js for UK developers), and a bit of vanilla CSS work to really stress-test the tools on something they tend to struggle with.

    The main players I tested were GitHub Copilot’s code review features (now substantially expanded beyond autocomplete), Cursor’s review and chat modes, CodeRabbit, and Sourcery. These represent the current spectrum: deeply IDE-integrated assistants versus dedicated PR review bots.

    GitHub Copilot: the one everyone already has

    Copilot’s review features are now genuinely decent for catching common React anti-patterns. In testing it against a mid-sized e-commerce frontend, it correctly identified several places where state was being lifted unnecessarily, and flagged a couple of async race conditions in data-fetching hooks that I’d missed during my own pass. That’s actually impressive.

    Where it falls apart is CSS and anything involving browser-specific behaviour. I fed it some complex grid layout code and it confidently suggested a fix using a property that, at time of writing, has incomplete support across Firefox. No caveat, no MDN link, just breezy confidence. For reference, MDN Web Docs remains the authoritative source here, and a tool that doesn’t defer to it when uncertain is a tool you need to double-check constantly. To its credit, Copilot’s JavaScript and TypeScript suggestions are noticeably stronger than its CSS ones. The pattern holds across tools, honestly: they were all trained on more JS than CSS.

    The GitHub PR integration is where Copilot earns its keep day-to-day. If you’re already on a GitHub-centric workflow, having inline review comments appear automatically on your PRs without any additional setup is a genuine time-saver for catching straightforward issues before a human reviewer has to bother.

    Cursor: the ambitious one

    Cursor is doing something more ambitious than Copilot and it shows, for better and worse. Its ability to understand your entire codebase context rather than just the file you’re editing is meaningfully useful. I tested it on a project where a custom hook was being misused across multiple components, and Cursor caught the pattern globally, not just in isolation. That’s the kind of review a senior developer would catch and a linter wouldn’t.

    The “with great power” problem applies here though. Cursor’s suggestions can be wordy. It’ll write you a three-paragraph explanation of why a piece of code might cause issues, when what you actually need is a one-line fix. I’ve found it works best when you treat it less like an automated reviewer and more like a very fast junior developer you’re pair-programming with: useful input that still needs your judgment applied. If you’re already doing TypeScript work as a designer-developer, Cursor’s contextual type inference suggestions are particularly strong.

    One thing I’d flag for UK developers specifically: Cursor’s pricing is in USD and some of the enterprise tier features assume team structures that are less common in smaller UK agencies or freelance setups. Worth reading the pricing tiers carefully before committing.

    CodeRabbit and Sourcery: the PR-first bots

    These two operate at the PR level rather than the editor level, and that distinction matters. CodeRabbit posts review comments directly in GitHub or GitLab PRs and, in my experience, it’s the most consistent of the lot at pure code quality observations. It doesn’t try to be your entire development environment; it just does one thing and does it reasonably well. Sourcery is similar but skews more towards refactoring suggestions, it loves pointing out where you could simplify a conditional or extract a function.

    Neither of them is particularly good at design-system awareness. If your frontend has a component library with specific patterns (say, a custom button that must always receive an aria-label when icon-only), they won’t know that unless you configure custom rules. This is a meaningful gap. Good frontend code isn’t just syntactically correct; it reflects the design system’s intent. If your icon system has its own rules and conventions (and it should, per everything I’ve written about icon systems for UK product teams), no off-the-shelf AI reviewer will enforce them out of the box.

    Where every tool struggles

    Three consistent failure modes came up across every tool I tested.

    First: accessibility. Every tool I tested missed at least some WCAG 2.2 issues that a human reviewer with accessibility knowledge would catch. They’re improving, but I wouldn’t rely on any of them as your accessibility review layer.

    Second: performance implications. None of them flagged a genuinely expensive re-render pattern I left in place as a test. They saw correct-looking code and approved it. The code worked; it just hammered the main thread on low-end devices.

    Third, and most dangerously: they are all confidently wrong sometimes. Not hedging, not flagging uncertainty. Just wrong, with the same tone as when they’re right. That’s the behaviour that will bite you if you let any of these tools become a rubber stamp.

    My actual recommendation

    If you’re a solo UK developer or working in a small agency, the combination that’s made the most practical difference for me is Copilot for in-editor suggestions plus CodeRabbit on PRs. You get the autocomplete and quick fixes at point of writing, and a second pass on the whole PR before merge. Neither replaces your own review or a colleague’s, but together they catch a reasonable chunk of the boring stuff so your human review time can focus on architecture and intent.

    Cursor is worth trying if you’re on a larger TypeScript project where codebase-wide context matters. Just don’t expect it to replace the kind of holistic design thinking that comes from actually understanding what your interface is supposed to do for a user.

    The tools are good enough to use. They’re not good enough to trust unattended. That distinction is doing a lot of work in 2026, and any developer who forgets it is going to spend a frustrating afternoon debugging something a very confident AI told them was fine.

    Frequently Asked Questions

    Are AI code review tools good enough to replace human code review in 2026?

    No, not reliably. They catch common syntax issues, anti-patterns, and some logic errors well, but they miss accessibility problems, performance implications, and design-system-specific rules. They work best as a first pass before a human reviewer looks at a PR.

    Is GitHub Copilot's code review feature worth paying for as a UK freelancer?

    If you’re already using Copilot for autocomplete, the review features are included and genuinely add value at no extra cost. For pure code review without the editor features, CodeRabbit’s free tier is worth trying first.

    How does Cursor differ from GitHub Copilot for frontend code review?

    Cursor reads your entire codebase for context, not just the current file, which makes it stronger at catching cross-file issues and misused patterns. Copilot’s PR integration is more lightweight and easier to fit into an existing GitHub workflow without changing your editor.

    Do AI code review tools understand TypeScript properly?

    They handle TypeScript meaningfully better than plain CSS or browser-compatibility edge cases. Type inference suggestions from Cursor in particular are quite strong. That said, complex generic types and conditional types can still confuse them, always verify anything non-trivial.

The Latest