Category: Nerdy

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

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

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

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

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

    Why government data tools are the right case study

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

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

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

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

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

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

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

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

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

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

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

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

    Colour as data channel, not decoration

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

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

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

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

    Spacing is doing more work than you think

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

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

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

    What the Ofcom approach teaches us about filtering

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

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

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

    Making it work in practice

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    What killed scroll-jacking (finally)

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

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

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

    What “the grid is back” actually means in practice

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

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

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

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

    The CSS behind the comeback

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

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

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

    Why SaaS product teams are converging on the same patterns

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

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

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

    Grids, typography, and the system-font connection

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

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

    What this means for performance budgets

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

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

    Is this a permanent shift or another cycle?

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

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

    Frequently Asked Questions

    What is an editorial grid layout in web design?

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

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

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

    How does CSS subgrid help with structured editorial layouts?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Figma component strategies for multi-tenant dashboards

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

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

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

    Logo swapping and asset management across tenants

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

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

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

    Building the dashboard layout layer that works for every tenant

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

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

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

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

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

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

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

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

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

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

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

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

    Why open source typography is a serious option now

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

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

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

    Pairing one: Inter + Fraunces

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

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

    Pairing two: DM Sans + DM Serif Display

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

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

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

    Pairing three: Instrument Sans + Playfair Display

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

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

    Pairing four: Hanken Grotesk + Lora

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

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

    Pairing five: Cabinet Grotesk + Satoshi

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

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

    What actually matters when testing pairings at scale

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

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

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

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

    Open source fonts and site visibility: a quick note

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

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

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

    A word on licensing confidence

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

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

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

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

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

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

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

    How iPlayer handles content discovery without overwhelming you

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

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

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

    Accessibility as a structural decision, not a retrofit

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

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

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

    Multi-device consistency and where it gets complicated

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

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

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

    Performance design and the perception of speed

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

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

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

    The design system thinking underneath it all

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

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

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

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

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

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

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

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

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

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

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

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

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

    Site architecture: stop building a single-page portfolio

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

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

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

    Core Web Vitals targets for 2026

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

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

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

    Schema markup that actually moves the needle

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

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

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

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

    Local SEO signals for British designers

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

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

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

    Content that supports your portfolio without bloating it

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

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

    The technical checklist before you publish

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

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

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

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

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

  • Icon Design in 2026: Why Most UK Product Teams Are Getting Their Icon Systems Completely Wrong

    Icon Design in 2026: Why Most UK Product Teams Are Getting Their Icon Systems Completely Wrong

    There is a particular kind of design debt that nobody talks about in sprint retros. It lives in your Figma file, buried three pages deep. It is inconsistent stroke widths, a random mix of filled and outlined icons, one set from Heroicons, another ripped from Material Design, and a couple of bespoke ones drawn by a contractor in 2022 who has long since moved on. This is the state of icon design in a depressing number of British SaaS and fintech products right now, and it matters far more than most teams acknowledge.

    Across the UK’s product landscape, from challenger banks to B2B SaaS tools built in Leeds and Edinburgh, the icon layer is treated as an afterthought. And that is a serious problem, because icons are the nervous system of any interface. They carry meaning at a glance, reduce cognitive load, and signal whether a product feels polished or patched together. When your icon system is incoherent, users feel it even if they cannot name it. The trust erodes quietly.

    Product designer reviewing an icon design system in Figma, relevant to UK product design in 2026

    Why Lazy Icon Choices Are So Common

    The root cause is almost always speed. A team picks a free icon library early in the product’s life because something needs to ship. Heroicons is solid. Lucide is solid. Phosphor is genuinely excellent. The problem is not the library itself; the problem is never graduating beyond it. Products grow, brand guidelines get written, a design system gets built, and the icon layer just… never gets revisited.

    Then there is the “bespoke one-off” problem. A product manager wants a specific icon for a new feature that does not exist in the library. A designer draws it quickly. Now you have 80 icons from Phosphor at 1.5px stroke and one custom icon at 2px stroke with rounded joins, sitting right next to each other in your nav bar. Nobody notices until a sharp-eyed user or a new senior designer joins and immediately clocks it.

    Fintech interfaces in particular suffer from a third issue: regulatory screen clutter. FCA-compliant products often carry a lot of required information and iconography for warnings, risk levels, and disclosures. Teams bolt icons onto these elements ad hoc, sourced from wherever is convenient, which means the most legally sensitive parts of your interface often have the most visually chaotic iconography. That is a branding and a trust problem wrapped in a compliance wrapper.

    What a Coherent Icon Design System Actually Looks Like

    Building a proper icon design system for UK product design in 2026 is not as complex as some teams fear, but it does require deliberate decisions made up front. Here is the framework I find most useful.

    Step 1: Define Your Icon Grammar

    Before you draw a single icon, you need a written grammar. This means committing to: a single stroke weight (1.5px or 2px, not both), corner radius (sharp, slightly rounded, or fully rounded), fill style (outlined only, filled only, or a deliberate mixed system with semantic rules), and a grid (typically 24×24 with a 2px inner padding creating a 20×20 optical field). Monochrome or two-tone? That decision needs to happen now, not mid-sprint.

    The grammar is your constraint document. Without it, every new icon becomes a judgment call. With it, a new designer can add an icon six months from now and have it look like it belonged from day one.

    Step 2: Audit and Cull Your Existing Set

    Run a full audit. Export every icon currently in your product, lay them side by side, and apply your new grammar as a filter. Some will pass. Some will need redrawing. Some need removing entirely because the feature they represent was deprecated in 2024 and the icon is still floating around in three screens. Yes, this actually happens.

    Tools like Figma’s component analytics (available via the Org and Enterprise plans) can surface how many times a component is used, which makes this audit dramatically faster. If an icon has zero instances, archive it. If it has 400 instances and does not match your grammar, it goes into the redraw queue.

    Step 3: Build in Figma With Dark Mode Baked In From the Start

    This is where a lot of teams make a costly mistake. They build their icon system for light mode, then try to adapt it for dark mode later using colour overrides. By then, some icons have hard-coded fill colours, some use current colour correctly, and the whole thing becomes a maintenance nightmare.

    The correct approach: all icons should use currentColor as their fill or stroke value from the beginning. In Figma, this maps to “Use as mask” or, more precisely, building icons as fully monochromatic components where the colour is inherited from the parent frame or a semantic colour token. If you are using Tokens Studio (which pairs beautifully with Figma), your icon colour tokens can reference your semantic palette, so icon/primary resolves to #1A1A1A in light mode and #F5F5F5 in dark mode automatically. No overrides, no separate dark mode icon set required.

    Step 4: Scalability Means Naming Conventions Matter

    A naming convention sounds boring. It is actually the difference between a system that scales and one that collapses under its own weight eighteen months later. Use a consistent taxonomy: [category]/[name]/[variant]. So action/download/outline, status/warning/filled, navigation/home/outline. Every icon findable by category. Every variant predictably named.

    This also feeds directly into your front-end implementation. If you are exporting to SVG sprites or using a tool like SVGR to generate React components, a consistent naming convention means your component names are predictable too. <IconActionDownload /> is infinitely more maintainable than <DownloadIcon2New />, which is a real component name I have seen in production code.

    Step 5: Document Intent, Not Just Appearance

    The icon design system for UK product design in 2026 needs to go beyond a grid of icons in a Figma page. Each icon, or at minimum each category, needs usage notes. What is the difference between status/warning and status/error? When do you use the filled variant versus the outline? Are there contexts where icons should never appear without a text label (hint: for accessibility, the answer is almost always yes).

    The UK government’s accessibility requirements for public sector websites and apps are instructive here even if you are building a private SaaS product. WCAG 2.1 AA is the benchmark, and icons that carry meaning without a text alternative fail it. Documenting which icons are decorative and which are informational, and what the accessible label should be, is part of the system.

    The Brand Alignment Layer

    A coherent icon design system should feel like an extension of your brand, not a neutral utility grafted onto it. If your brand uses geometric, modernist typography and sharp angles, your icons should share that character. Soft, rounded icons in a brand that communicates precision and authority create a subconscious mismatch that users pick up on, even if they cannot articulate why something feels slightly off.

    This is why picking an off-the-shelf library and calling it done is always a partial solution at best. Libraries like Phosphor or Lucide are excellent starting points and perfectly valid for early-stage products. But a mature product with a defined brand identity, especially one competing in UK fintech where trust signals are everything, should have icons that were either drawn to the brand’s geometric character or significantly adapted from a base library.

    The practical route for most teams: start with a base library that is closest to your brand’s visual character, establish your grammar document, and then redraw any icons that deviate or that your product requires specifically. Over time, the bespoke set grows and the dependency on the base library shrinks. That is a healthy progression.

    Consistency as a Product Value

    Here is the thing that is easy to miss when you are deep in delivery cycles: icon consistency is not a nice-to-have design detail. It is a product quality signal. Users who encounter a polished, coherent icon set are building a subconscious model that this product was made carefully, by people who sweat the details. That trust compounds. It affects retention, it affects willingness to enter payment information, and in regulated sectors like fintech, it affects whether a user completes onboarding or bounces at the first moment of uncertainty.

    A proper icon design system for UK product design in 2026 is not about aesthetics for aesthetics’ sake. It is about building a product that communicates competence at every pixel.

  • What the ONS Data Design Team Gets Right (And What the Rest of Us Should Steal)

    What the ONS Data Design Team Gets Right (And What the Rest of Us Should Steal)

    The Office for National Statistics is not a design studio. Nobody working there is chasing a Awwwards nomination or obsessing over whether their typeface feels “premium”. And yet, if you spend time actually reading through ONS data visualisations, you start to notice something genuinely impressive: these charts communicate extraordinarily well. They are sober, functional, and designed with a discipline that most commercial dashboard teams never achieve. That is worth pulling apart.

    This is not a fan letter. There are real weaknesses in the ONS approach, and I’ll get to them. But the core methodology behind their data visualisation design is a masterclass in restraint, and restraint is the hardest thing to teach a designer who has spent three years in Figma making things look beautiful.

    Data analyst reviewing data visualisation design UK ONS charts on multiple monitors in a British office

    Why the ONS chart style is so readable (even when the data is horrible)

    The first thing you notice looking at ONS charts is the absence of noise. No gradients. No 3D extrusions. No decorative gridlines. The chart area is clean to the point of feeling almost spartan, and that is not an accident. Their house style explicitly prioritises clarity over aesthetics, which sounds obvious but is remarkably rare in practice.

    Their bar charts use a restrained palette: typically one primary colour for the main data series, with muted secondary tones for comparison series. The ONS colour set leans heavily on accessible combinations. They use a mid-blue as a workhorse colour, which sits well on both white and off-white backgrounds, and has solid contrast ratios for users with colour-vision deficiency. A lot of commercial dashboards still use red-green pairings for comparison metrics. The ONS almost never does this, because a meaningful percentage of the population cannot distinguish those colours reliably.

    The typography choice is equally deliberate. Their publications use a clean sans-serif across chart labels, axis annotations, and source attributions. The hierarchy is strict: title at the top, subtitle directly beneath it, axis labels smaller and lighter, source line at the bottom in a noticeably reduced size. There is never any ambiguity about what you are supposed to read first. That reading order matters enormously when the data is genuinely complex, like age-stratified mortality statistics or regional employment breakdowns.

    The colour palette decisions that data visualisation design uk ons charts gets right

    Colour in data visualisation is one of those areas where designers consistently over-engineer things. The temptation is to build a ten-colour categorical palette because it feels comprehensive. The ONS approach keeps categorical colours to a sensible minimum, typically no more than six distinct values on a single chart, and when the data requires more categories than that, they restructure the chart rather than add more colours.

    This is actually the correct answer, and most teams reach it too late, after building a twelve-colour legend that nobody can parse at a glance.

    Their sequential palettes for choropleth maps (the regional breakdown maps you see for things like median household income or broadband coverage) use single-hue progressions, typically moving from a pale tint to a saturated anchor. This is textbook perceptual uniformity. The human visual system processes luminance gradients more reliably than hue shifts, so a light-to-dark single colour reads as a continuous scale far more intuitively than a rainbow palette. The ONS gets this right by default. A huge number of Local Authority and NHS data dashboards still use rainbow gradients in 2026, which is genuinely baffling.

    Where the ONS approach has genuine gaps

    Right. Enough praise. There are real criticisms to make.

    Interactivity is sparse. The static chart approach works brilliantly for published reports and press releases, but the ONS digital presence has been slow to adopt genuinely exploratory visualisation. Their datasets are enormous and often the most interesting insights live in the sub-groups: age cohorts, regional splits, occupational categories. A well-built interactive chart could surface those without requiring a user to download a 40MB Excel spreadsheet. Tools like Observable Plot or D3.js could handle this elegantly. Some ONS pages now include simple chart builders, but the experience still feels like an afterthought compared to, say, what the Financial Times graphics team produces.

    Responsiveness is another weak point. Many ONS chart embeds were designed for desktop screens and degrade awkwardly on mobile. Given that mobile accounts for a substantial share of web traffic across the board, a chart whose axis labels overlap at 375px width is simply not finished. This is a common problem across government digital estates, but it matters more for the ONS because their data is genuinely in the public interest.

    And annotation. The ONS occasionally adds annotation to charts for major events (a shaded region for the pandemic period, a labelled inflection point for a policy change), but this is inconsistent. Annotation is arguably the most powerful tool in data storytelling. Telling the reader why a spike exists turns a confusing chart into a coherent argument.

    What to actually steal for your own UK data dashboard

    If you are building a dashboard for a UK public sector client, a fintech, or any product that has to make complex data legible to non-specialists, here is what I would take directly from the ONS playbook.

    First: commit to a maximum of five categorical colours. Pick them based on contrast ratios and colour-vision accessibility, not because they match your brand guidelines. Your brand team will survive.

    Second: use a strict typographic hierarchy with no more than three size levels across a chart. Title, axis labels, and source attribution. If you need a fourth level, the chart is probably too complicated.

    Third: strip the gridlines back to horizontal-only for bar and line charts. Vertical gridlines rarely add information and almost always add visual weight. The ONS rarely uses them, and their charts are better for it.

    Fourth: when your data has a natural comparison period (pre-pandemic vs post-pandemic, pre-Brexit vs post-Brexit trade figures), use a subtle background band to mark that period rather than relying on the user to cross-reference dates. The ONS does this consistently and it genuinely aids comprehension.

    Fifth, and this is the big one: design for the worst-case reader, not the best-case reader. The ONS writes for a journalist filing a story at speed, a policy analyst who has fifty tabs open, and a curious member of the public who has never read a statistics bulletin before. All three need to extract the key finding within about ten seconds. If your dashboard only works for someone who already understands the domain, it is not doing its job.

    The practical upshot for designers working with data

    There is a quiet revolution happening in UK product teams around data literacy. More designers are expected to understand chart types, know when a line chart is wrong for the data they have, or recognise that a pie chart with seven segments is functionally useless. The ONS charts, for all their limitations, are a free masterclass in applied data visualisation design. They are public documents, they cover every chart type in common use, and they have been iterated over decades with a clear mandate to communicate reliably rather than impress.

    Go look at them properly. Not to screenshot something pretty, but to study why something works. Then bring that rigour back to whatever dashboard you are building, and watch how much cleaner it gets when you stop trying to make it look clever.

    Frequently Asked Questions

    What chart types does the ONS use most often in their data visualisations?

    The ONS relies heavily on line charts for time-series data, bar charts for categorical comparisons, and choropleth maps for regional breakdowns. They tend to avoid pie charts and 3D charts, which is consistent with established data visualisation best practice.

    How do I make my data dashboard accessible to colourblind users?

    Use single-hue sequential palettes for continuous data and limit categorical palettes to colours that differ in both hue and luminance. Tools like the Colour Contrast Analyser (free from the Paciello Group) can check your combinations. Avoid red-green pairings entirely.

    Is the ONS data visualisation approach suitable for commercial or private sector dashboards?

    The core principles, restraint in colour, strict typographic hierarchy, and clean chart areas, translate directly to commercial contexts. You may need to incorporate brand colours, but the structural decisions the ONS makes are universally applicable.

    What tools do UK design teams typically use to build data dashboards?

    Common choices include Tableau, Power BI, and Looker for business intelligence dashboards, and D3.js or Observable Plot for bespoke web-based visualisations. Figma is widely used for prototyping chart layouts before building in code.

    How many colours should a data visualisation use?

    Most data visualisation experts recommend a maximum of five to six distinct categorical colours per chart. Beyond that, the legend becomes too complex to parse quickly and the visual differentiation between series breaks down, particularly on small screens.

  • TypeScript for Designers Who Code: A No-Fluff Introduction for UK Freelancers in 2026

    TypeScript for Designers Who Code: A No-Fluff Introduction for UK Freelancers in 2026

    JavaScript is brilliant until it isn’t. You’re three components deep into a design system, passing tokens around, and suddenly a prop that was supposed to be a colour hex string is undefined at runtime and your whole button component goes blank in production. Sound familiar? TypeScript exists precisely to prevent that specific category of misery. If you’re a UK freelancer who designs and builds your own components but has always bounced off TypeScript docs written for enterprise backend engineers, this is the piece I wish had existed when I started.

    This isn’t a theoretical exercise. We’re going through the concepts that actually matter for building UI work, typed props, design tokens, component interfaces, and skipping the rest. There’s no need to understand generics at a deep level to ship better, safer front-end code. Let’s prove that.

    Freelance developer working on TypeScript for designers UK freelance 2026 in a London flat with VS Code open

    Why TypeScript Keeps Coming Up in UK Freelance Briefs

    A quick look at job boards and freelance platforms in the UK confirms what most of us have quietly noticed: TypeScript has stopped being a “nice to have” and started appearing as a baseline requirement. Whether it’s a Bristol-based SaaS startup or a London agency scope, the brief increasingly says TypeScript. The Stack Overflow Developer Survey has had TypeScript as one of the most wanted languages for several consecutive years, and UK freelance rates for TypeScript-comfortable devs are noticeably higher than those for pure JavaScript work.

    The reason it matters specifically for designer-developers is less about catching logical bugs and more about self-documentation. When you’re the only person on a project (or handing off to a client’s internal team six months later), typed components tell the next person exactly what a component expects. That’s not just good engineering; it’s good design thinking applied to code.

    The One Mental Model That Makes TypeScript Click

    Stop thinking of TypeScript as a separate language. It’s JavaScript with annotations you write for your future self. At build time, those annotations are stripped out entirely. The browser never sees them. What you’re doing is describing the shape of your data so the editor (VS Code, in almost every case) can warn you when you’ve given a component the wrong thing.

    Think of it like a Figma component with defined properties. In Figma, you specify that a button has a variant property that accepts primary, secondary, or ghost. You can’t just type any random value in there. TypeScript does exactly the same thing in code. The concept is genuinely identical; the syntax is just different.

    Typing Design Tokens: The Best First Project

    If you’re working with a design token system (and in 2026, you really should be), TypeScript earns its keep immediately. Consider a colour token file. In plain JavaScript, there’s nothing stopping you misspelling brand.primry instead of brand.primary and only finding out at runtime. In TypeScript:

    type ColourScale = {
      primary: string;
      secondary: string;
      accent: string;
      muted: string;
    };
    
    const colours: ColourScale = {
      primary: '#1A1A2E',
      secondary: '#16213E',
      accent: '#0F3460',
      muted: '#E94560',
    };

    Now if you try to access colours.primry, VS Code underlines it in red before you’ve even saved the file. For a freelancer working alone without a QA team, that’s an enormous catch rate improvement for almost zero extra effort.

    Typing React Component Props (This Is the Big One)

    Most of the TypeScript a designer-developer actually needs lives in one place: component props. Here’s a typed button component that covers the vast majority of real-world cases:

    type ButtonVariant = 'primary' | 'secondary' | 'ghost';
    type ButtonSize = 'sm' | 'md' | 'lg';
    
    interface ButtonProps {
      label: string;
      variant?: ButtonVariant;
      size?: ButtonSize;
      disabled?: boolean;
      onClick?: () => void;
    }
    
    export function Button({
      label,
      variant = 'primary',
      size = 'md',
      disabled = false,
      onClick,
    }: ButtonProps) {
      return (
        <button
          className={`btn btn--${variant} btn--${size}`}
          disabled={disabled}
          onClick={onClick}
        >
          {label}
        </button>
      );
    }

    A few things worth unpacking here. The question marks after property names like variant? mean optional. Without a question mark, TypeScript will force you to pass that prop every time you use the component. The union type 'primary' | 'secondary' | 'ghost' is exactly like a Figma constrained property. Pass anything else and TypeScript complains. You’ll notice this maps precisely to the kind of variant logic that comes out of a design system.

    The interface vs type Debate (Short Answer: Don’t Stress It)

    You’ll see both interface and type used to describe the shape of objects, and people on the internet argue about this endlessly. For UI component work, the practical difference is negligible. I tend to use interface for component props because it reads slightly more like a Figma component definition, and type for unions like ButtonVariant. That’s a personal preference, not a rule. Either works. Pick one and be consistent within a project.

    Working with Design Tokens From Figma and Tokens Studio

    If your workflow involves Tokens Studio for Figma exporting tokens as JSON, TypeScript becomes genuinely powerful. You can type the entire token structure and get autocomplete across your whole codebase. Import the JSON, cast it to a typed interface, and every token reference is now checked. This is the workflow that makes typescript for designers uk freelance 2026 relevant beyond just passing a code interview; it actively speeds up your component-building process.

    Tokens Studio exports to a JSON structure. A small TypeScript utility file that types that structure means your spacing.md or colour.background.subtle tokens are autocompleted in every component file. No more digging back into Figma to check exact token names. Your editor knows them all.

    Setting Up TypeScript in a New Project (The Quickest Path)

    If you’re starting fresh with a Vite + React project (the sensible 2026 choice for most freelance UI work), it’s a single flag:

    npm create vite@latest my-project -- --template react-ts

    That gives you a TypeScript-ready project with a tsconfig.json already configured sensibly. Don’t touch the tsconfig until you need to. The defaults are fine for component work. Avoid the trap of spending an afternoon tuning compiler settings before you’ve written a single component. Get a typed button built first. Tune later, if ever.

    Adding TypeScript to an existing JavaScript project is slightly more involved, but still manageable. The TypeScript docs have a migration guide, and for most freelance projects the approach of renaming .jsx files to .tsx one at a time (rather than all at once) keeps the project shippable throughout the transition. You can run TypeScript in allowJs: true mode while you migrate gradually, which means you’re not blocked from deploying while you work through it.

    When TypeScript Gets Annoying (And What to Do About It)

    Honestly, there are moments. Typing event handlers in React can feel verbose at first. Third-party libraries occasionally have incomplete type definitions. If you hit a wall and genuinely cannot work out the correct type, as unknown as YourType is the escape hatch. Use it sparingly, note it in a comment, and revisit it later. It’s not cheating; it’s pragmatic. The goal for a freelancer working on UI components isn’t TypeScript purity, it’s shipping good work faster with fewer runtime surprises.

    The @types ecosystem covers most popular libraries. If you’re using a library and TypeScript doesn’t know its types, a quick npm install @types/library-name --save-dev usually solves it. The TypeScript official site has solid docs for looking up specific patterns when you get stuck.

    The short summary for anyone dipping into typescript for designers uk freelance 2026 work: the learning curve is shorter than it looks from the outside, the payoff in editor feedback is immediate, and it makes your design systems significantly more robust to hand off. Type your tokens, type your props, and let the compiler catch the typos that would otherwise cost you a debugging hour at 11pm before a client deadline.

    Frequently Asked Questions

    Do I need to know TypeScript to get freelance design-developer work in the UK in 2026?

    Increasingly yes, at least at a basic level. Many UK agency and SaaS briefs list TypeScript as a requirement or strong preference, and freelancers comfortable with it command noticeably higher day rates. You don’t need deep expertise, but knowing how to type component props and design tokens puts you ahead of most JavaScript-only candidates.

    What's the difference between TypeScript and JavaScript for building UI components?

    TypeScript is JavaScript with added type annotations that describe the shape and type of your data. For UI components, this means you declare exactly what props a component accepts and what values are valid. At build time, TypeScript strips those annotations out, so the browser runs plain JavaScript. The benefit is purely in the editor and build step, where you catch errors before they reach production.

    How long does it take to learn enough TypeScript to be productive on freelance projects?

    For a JavaScript-comfortable developer focusing on UI work, a weekend of focused learning, typing props, design tokens, and basic interfaces, is enough to be genuinely productive. Full fluency takes longer, but the 20% of TypeScript that covers 80% of component-level work is quite approachable.

    Can I use TypeScript with Figma design tokens exported from Tokens Studio?

    Yes, and it works very well. Tokens Studio exports JSON token files which you can import into your codebase. By creating a TypeScript interface that matches the token structure, you get full autocomplete and error-checking on every token reference across your project. It’s one of the most immediately useful applications of TypeScript for designer-developers.

  • Reactive SVGs: How to Build Illustrations That Respond to Data Using D3 and UK Open Datasets

    Reactive SVGs: How to Build Illustrations That Respond to Data Using D3 and UK Open Datasets

    Raw data is boring. A spreadsheet of ONS broadband penetration figures or Ofcom spectrum usage statistics is about as gripping as a council planning notice. But bind those same numbers to a living, breathing SVG illustration and suddenly you have something people actually want to look at. That is the promise of reactive SVG data visualisation, and D3.js is the library that makes it properly possible without reaching for a bloated charting framework that hides all the interesting bits from you.

    This article is a hands-on walkthrough. We are going to fetch real UK open data, parse it, and use D3 to bind it to SVG elements so the visuals respond dynamically to the figures. No toy datasets. No made-up numbers. Real data from sources the UK government and regulators actually publish.

    Developer building a reactive SVG data visualisation UK project on a large monitor in a modern studio
    Developer building a reactive SVG data visualisation UK project on a large monitor in a modern studio

    Why SVG and D3 Instead of Canvas or a Chart Library?

    Canvas is fast for pixel-heavy rendering. Chart libraries like Chart.js are quick to deploy. But neither gives you the fine-grained control that reactive SVG data visualisation demands when you want illustrations, not just bar charts. SVG is part of the DOM, which means every shape, path, and text node is queryable, styleable, and animatable with CSS. D3 exploits this completely.

    The data join pattern at D3’s core (enter, update, exit) is genuinely elegant once it clicks. You tell D3 what data you have, what DOM elements should represent it, and what to do when data changes. The library handles the rest. It is declarative in the right places and imperative where you need control. I have used it on projects ranging from tiny inline sparklines to full-screen choropleth maps, and I keep coming back because nothing else gives you the same ceiling.

    Getting Your UK Open Data: ONS and Ofcom

    The Office for National Statistics publishes machine-readable datasets through its ONS API, which returns JSON in a fairly navigable structure. Ofcom releases its Connected Nations datasets as downloadable CSVs covering broadband coverage by local authority district. Both are genuinely free, regularly updated, and ideal for a reactive SVG project.

    For this walkthrough we are using Ofcom’s Connected Nations data: specifically, the percentage of premises with access to gigabit-capable broadband by UK nation and region. It is a flat CSV, which means we can use D3’s built-in d3.csv() loader and avoid writing a custom parser.

    import * as d3 from "https://cdn.jsdelivr.net/npm/d3@7/+esm";
    
    const DATA_URL = "https://your-hosted-copy/ofcom-connected-nations.csv";
    
    d3.csv(DATA_URL, d => ({
      region: d["Region"],
      gigabit_pct: +d["Gigabit capable (%)"],
      premises: +d["Total premises"]
    })).then(data => {
      render(data);
    });

    Note the + coercion on the numeric fields. D3’s CSV parser returns strings by default. Skip that coercion and your scales will treat “84” as text, which produces spectacularly wrong output. Ask me how I know.

    Building the SVG Container and Scales

    The margin convention in D3 is worth following even when it feels ceremonial. It keeps your axes and labels inside the viewport without wrestling with overflow: visible hacks later.

    const margin = { top: 40, right: 30, bottom: 60, left: 120 };
    const width = 800 - margin.left - margin.right;
    const height = 500 - margin.top - margin.bottom;
    
    const svg = d3.select("#chart")
      .append("svg")
      .attr("viewBox", `0 0 ${width + margin.left + margin.right} ${height + margin.top + margin.bottom}`)
      .attr("preserveAspectRatio", "xMidYMid meet")
      .append("g")
      .attr("transform", `translate(${margin.left},${margin.top})`);

    Using viewBox instead of hard-coded pixel dimensions is non-negotiable if you want the illustration to be responsive. The SVG scales itself to the container, and your D3 coordinates stay consistent regardless of screen size. This is how reactive SVG data visualisation actually becomes reactive to viewport changes as well as data changes.

    Close-up of D3.js code powering a reactive SVG data visualisation UK broadband chart on a laptop screen
    Close-up of D3.js code powering a reactive SVG data visualisation UK broadband chart on a laptop screen

    Now the scales. For a horizontal bar chart of regional broadband coverage:

    const x = d3.scaleLinear()
      .domain([0, 100])
      .range([0, width]);
    
    const y = d3.scaleBand()
      .domain(data.map(d => d.region))
      .range([0, height])
      .padding(0.3);

    scaleBand handles the spacing maths for categorical axes so you do not have to. The padding value of 0.3 adds 30% whitespace between bands, which visually separates the bars without making them hair-thin.

    The D3 Data Join: Where the Reactive Magic Happens

    This is the part that confuses people initially and then becomes the thing they explain excitedly to colleagues. The data join binds an array of data objects to a selection of DOM elements. Elements that do not yet exist go into the enter selection. Elements whose data has disappeared go into the exit selection. Everything in between is the update selection.

    const bars = svg.selectAll("rect.bar")
      .data(data, d => d.region); // key function keeps transitions smooth
    
    // Enter: create new bars
    bars.enter()
      .append("rect")
      .attr("class", "bar")
      .attr("y", d => y(d.region))
      .attr("height", y.bandwidth())
      .attr("x", 0)
      .attr("width", 0) // start at zero for transition
      .attr("fill", "#4F46E5")
      .merge(bars) // merge with update selection
      .transition()
      .duration(800)
      .ease(d3.easeCubicOut)
      .attr("width", d => x(d.gigabit_pct));
    
    // Exit: remove stale bars
    bars.exit()
      .transition()
      .duration(400)
      .attr("width", 0)
      .remove();

    The key function in .data(data, d => d.region) is critical for smooth transitions. Without it, D3 matches data to elements by index. With it, elements are bound by region name, so if you filter or reorder the dataset the bars animate to their new positions rather than snapping jarringly.

    Making It Genuinely Reactive: Filtering and UI Controls

    The real payoff of reactive SVG data visualisation comes when you wire up UI controls that change the underlying data and re-call the render function. Add a simple dropdown that filters by UK nation:

    const nations = ["All", "England", "Scotland", "Wales", "Northern Ireland"];
    
    const select = d3.select("#controls")
      .append("select")
      .on("change", function() {
        const selected = this.value;
        const filtered = selected === "All"
          ? fullData
          : fullData.filter(d => d.nation === selected);
        render(filtered);
      });
    
    select.selectAll("option")
      .data(nations)
      .enter()
      .append("option")
      .text(d => d);

    Each time the user changes the dropdown, render(filtered) runs with a new data array. D3 works out which bars need to be added, which need updating, and which need removing. You do not manually manipulate the DOM. That is the whole point.

    Going Beyond Bar Charts: Binding Data to Illustrated SVG Paths

    Bar charts are fine, but the really interesting territory is binding data to custom SVG illustrations, like a stylised map of the UK’s twelve regions, or an illustrated diagram of network infrastructure where path stroke-width encodes bandwidth figures.

    The principle is identical. Load an SVG file (exported from Figma or Illustrator), inline it in your HTML, then use D3 to select specific paths by their id or data-region attributes and drive their visual properties from data. Colour fills from a sequential scale, opacity driven by coverage percentage, stroke animations that pulse for regions below a threshold: all of it is just attribute binding.

    const colour = d3.scaleSequential()
      .domain([0, 100])
      .interpolator(d3.interpolateBlues);
    
    data.forEach(d => {
      d3.select(`#region-${d.region.replace(/\s+/g, "-").toLowerCase()}`)
        .transition()
        .duration(600)
        .attr("fill", colour(d.gigabit_pct));
    });

    This approach turns a static SVG illustration into a living data artefact. Your designer exports a clean regional map from Figma. Your D3 code breathes data into it. The two disciplines talk to each other through attribute naming conventions agreed upfront. It is the kind of collaboration between design and dev that produces genuinely impressive output.

    Performance and Accessibility Notes

    A few things worth pinning to your monitor. First, ARIA labels. SVG is not inherently accessible. Add role="img" and aria-label to your SVG container, and use <title> and <desc> elements inside individual groups for screen readers. The Web Accessibility Initiative has clear guidance on SVG accessibility patterns.

    Second, transitions look great but they are not free. If you are rendering several hundred elements, consider using d3.transition() with a shared timer rather than individual transitions, and cap your dataset size where the visual encoding stops being legible anyway. A choropleth with 400 regions is just noise.

    Third, host your open data files yourself or proxy them. Fetching directly from government data portals in production is fragile; file structures change, URLs break, and there is no SLA. Pull the data into your own infrastructure on a schedule and serve it from there.

    The Bottom Line on D3 and Open Data

    Reactive SVG data visualisation using UK open datasets is one of those projects that teaches you an enormous amount in a short time. You learn D3’s join model. You learn how SVG coordinate systems actually work. You learn that ONS data is more useful than most developers realise. And you produce something genuinely worth showing in a portfolio, because it combines real public information with craft-level visual thinking. That combination is rare, and it shows.

    The Ofcom and ONS datasets are updated regularly, which means a project you build this month stays relevant as new figures land. Wire it up to a scheduled data fetch, add a timestamp to your visualisation, and you have something that essentially maintains itself.

    Frequently Asked Questions

    What is reactive SVG data visualisation and how does it differ from a static chart?

    Reactive SVG data visualisation means your SVG elements update dynamically when the underlying data changes, using a library like D3.js to bind data to DOM attributes in real time. A static chart is a fixed image or pre-rendered output; a reactive one responds to user input, data filters, or live data feeds without a page reload.

    Where can I download free UK open datasets to use with D3.js?

    The Office for National Statistics (ons.gov.uk) and Ofcom both publish machine-readable open datasets covering topics from broadband coverage to regional demographics. The ONS also provides a developer API that returns JSON, and Ofcom’s Connected Nations data is available as downloadable CSV files updated annually.

    Do I need to know D3.js well to build reactive SVG illustrations, or can beginners start here?

    D3’s data join pattern has a learning curve, so some JavaScript confidence is recommended before diving in. That said, the enter/update/exit model is well-documented and once it clicks, building reactive SVG visualisations becomes much more intuitive. Starting with a simple bar chart bound to a CSV is the fastest path to understanding it properly.

    Can I import an SVG illustration from Figma and bind data to it using D3?

    Yes, and this is one of the most powerful workflows available. Export your SVG from Figma, inline it in your HTML, and give key paths meaningful IDs or data attributes. D3 can then select those paths and drive their fill, opacity, stroke, or transform properties directly from your dataset.

    How do I make D3 SVG visualisations accessible for screen readers?

    Add role=”img” and an aria-label to the SVG container, and include a element as the first child of the SVG for a short description. For more complex visuals, a <desc> element and aria-describedby attribute provide additional context. Avoid encoding critical information solely through colour, and ensure interactive elements are keyboard-navigable.</p> <p><script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is reactive SVG data visualisation and how does it differ from a static chart?", "acceptedAnswer": { "@type": "Answer", "text": "Reactive SVG data visualisation means your SVG elements update dynamically when the underlying data changes, using a library like D3.js to bind data to DOM attributes in real time. A static chart is a fixed image or pre-rendered output; a reactive one responds to user input, data filters, or live data feeds without a page reload." } }, { "@type": "Question", "name": "Where can I download free UK open datasets to use with D3.js?", "acceptedAnswer": { "@type": "Answer", "text": "The Office for National Statistics (ons.gov.uk) and Ofcom both publish machine-readable open datasets covering topics from broadband coverage to regional demographics. The ONS also provides a developer API that returns JSON, and Ofcom's Connected Nations data is available as downloadable CSV files updated annually." } }, { "@type": "Question", "name": "Do I need to know D3.js well to build reactive SVG illustrations, or can beginners start here?", "acceptedAnswer": { "@type": "Answer", "text": "D3's data join pattern has a learning curve, so some JavaScript confidence is recommended before diving in. That said, the enter/update/exit model is well-documented and once it clicks, building reactive SVG visualisations becomes much more intuitive. Starting with a simple bar chart bound to a CSV is the fastest path to understanding it properly." } }, { "@type": "Question", "name": "Can I import an SVG illustration from Figma and bind data to it using D3?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, and this is one of the most powerful workflows available. Export your SVG from Figma, inline it in your HTML, and give key paths meaningful IDs or data attributes. D3 can then select those paths and drive their fill, opacity, stroke, or transform properties directly from your dataset." } }, { "@type": "Question", "name": "How do I make D3 SVG visualisations accessible for screen readers?", "acceptedAnswer": { "@type": "Answer", "text": "Add role=\"img\" and an aria-label to the SVG container, and include a element as the first child of the SVG for a short description. For more complex visuals, a element and aria-describedby attribute provide additional context. Avoid encoding critical information solely through colour, and ensure interactive elements are keyboard-navigable." } } ] } </script></p> </div> <div style="margin-top:var(--wp--preset--spacing--40)" class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/reactive-svg-data-visualisation-uk-d3-open-data/"><time datetime="2026-07-23T21:03:20+00:00">July 23, 2026</time></a></div></div> </li></ul> <div class="wp-block-group has-global-padding is-layout-constrained wp-block-group-is-layout-constrained" style="padding-top:var(--wp--preset--spacing--60);padding-bottom:var(--wp--preset--spacing--60)"></div> <div class="wp-block-group alignwide has-global-padding is-layout-constrained wp-block-group-is-layout-constrained"><nav class="alignwide wp-block-query-pagination is-content-justification-space-between is-layout-flex wp-container-core-query-pagination-is-layout-4dea2dca wp-block-query-pagination-is-layout-flex" aria-label="Pagination"> <div class="wp-block-query-pagination-numbers"><span aria-current="page" class="page-numbers current">1</span> <a class="page-numbers" href="https://launchpad-design.co.uk/category/nerdy/page/2/">2</a> <a class="page-numbers" href="https://launchpad-design.co.uk/category/nerdy/page/3/">3</a></div> <a href="https://launchpad-design.co.uk/category/nerdy/page/2/" class="wp-block-query-pagination-next">Next Page<span class='wp-block-query-pagination-next-arrow is-arrow-arrow' aria-hidden='true'>→</span></a> </nav></div> </div> </div> <div class="wp-block-column is-layout-flow wp-block-column-is-layout-flow" style="flex-basis:25%"> <h2 class="wp-block-heading has-small-font-size" style="font-style:normal;font-weight:600;letter-spacing:1.6px;text-transform:uppercase">The Latest</h2> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> <div class="wp-block-query is-layout-flow wp-block-query-is-layout-flow"><ul class="wp-block-post-template is-layout-flow wp-block-post-template-is-layout-flow"><li class="wp-block-post post-258 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-nerdy category-web-design tag-css-grid tag-editorial-grid-layout tag-structured-layout-design tag-uk-product-design tag-web-design-2026"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/editorial-grid-layout-web-design-2026-uk/" target="_self" >The Grid Is Back: Why British Editorial and SaaS Sites Are Returning to Structured Layout in 2026</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/editorial-grid-layout-web-design-2026-uk/"><time datetime="2026-09-02T08:21:49+00:00">September 2, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li><li class="wp-block-post post-255 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-nerdy category-web-design tag-design-tokens tag-figma-component-systems tag-multi-tenant-dashboard tag-saas-ui-design tag-white-label-saas-design"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/white-label-saas-dashboard-design-multi-tenant-uk-2026/" target="_self" >Designing Multi-Tenant SaaS Dashboards: The White-Labelling Patterns UK B2B Teams Need in 2026</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/white-label-saas-dashboard-design-multi-tenant-uk-2026/"><time datetime="2026-08-31T18:55:36+00:00">August 31, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li><li class="wp-block-post post-253 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-nerdy category-web-design tag-font-licensing tag-free-web-fonts tag-google-fonts-uk tag-open-source-font-pairing tag-typography-for-web-design"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/open-source-font-pairing-uk-web-design-2026/" target="_self" >Open Source Font Pairing in 2026: The Combinations UK Designers Are Actually Using to Replace Paid Typefaces</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/open-source-font-pairing-uk-web-design-2026/"><time datetime="2026-08-31T17:04:37+00:00">August 31, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li><li class="wp-block-post post-250 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-nerdy category-web-design tag-accessibility-in-product-design tag-bbc-iplayer-ui-design tag-design-systems-uk tag-product-design-principles-uk tag-streaming-interface-design"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/bbc-iplayer-ui-design-principles-uk-product-design/" target="_self" >The Principles Behind BBC iPlayer’s UI: What Every British Product Designer Can Learn From It</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/bbc-iplayer-ui-design-principles-uk-product-design/"><time datetime="2026-08-31T07:11:42+00:00">August 31, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li><li class="wp-block-post post-248 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-nerdy category-web-design tag-core-web-vitals-portfolio tag-designer-local-seo-uk tag-freelance-design-portfolio-seo tag-schema-markup-for-designers tag-uk-portfolio-seo-2026"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/freelance-design-portfolio-seo-uk-2026/" target="_self" >How to Build a Freelance Design Portfolio That Ranks on Google in 2026: A UK-Specific SEO Breakdown</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/freelance-design-portfolio-seo-uk-2026/"><time datetime="2026-08-30T19:46:11+00:00">August 30, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li><li class="wp-block-post post-246 post type-post status-publish format-standard has-post-thumbnail hentry category-design category-web-design tag-accessible-ui-design tag-designing-for-older-users-uk-accessibility tag-inclusive-design-principles tag-over-55-digital-design tag-web-accessibility-uk"> <div class="wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-54d079fe wp-block-group-is-layout-flex"><h3 class="wp-block-post-title has-large-font-size"><a href="https://launchpad-design.co.uk/designing-for-older-users-uk-accessibility-over-55/" target="_self" >Designing for Older Users: What UK Product Teams Get Wrong About the Over-55 Audience Online</a></h3> <div class="wp-block-post-date has-small-font-size"><a href="https://launchpad-design.co.uk/designing-for-older-users-uk-accessibility-over-55/"><time datetime="2026-08-30T07:41:32+00:00">August 30, 2026</time></a></div></div> <div style="height:var(--wp--preset--spacing--20)" aria-hidden="true" class="wp-block-spacer"></div> </li></ul> </div> </div> </div> </main> <footer class="wp-block-template-part"> <div class="wp-block-group alignfull is-style-section-4 has-contrast-color has-base-background-color has-text-color has-background has-link-color wp-elements-5da341d6370005ca50e8ccec8a4d9236 has-global-padding is-layout-constrained wp-container-core-group-is-layout-58f2d333 wp-block-group-is-layout-constrained is-style-section-4--2" style="padding-top:var(--wp--preset--spacing--50);padding-right:var(--wp--preset--spacing--40);padding-bottom:var(--wp--preset--spacing--50);padding-left:var(--wp--preset--spacing--40)"> <div class="wp-block-group alignwide is-content-justification-space-between is-layout-flex wp-container-core-group-is-layout-686a51e3 wp-block-group-is-layout-flex"> <div class="wp-block-group wp-container-content-9cfa9a5a has-global-padding is-content-justification-left is-layout-constrained wp-container-core-group-is-layout-236ffaf5 wp-block-group-is-layout-constrained"> <p class="has-text-align-left wp-block-paragraph" style="font-size:clamp(0.875rem, 0.875rem + ((1vw - 0.2rem) * 0.039), 0.9rem);font-style:normal;font-weight:600;letter-spacing:1px;text-transform:uppercase">Search</p> <form role="search" method="get" action="https://launchpad-design.co.uk/" class="wp-block-search__button-outside wp-block-search__icon-button wp-block-search" ><label class="wp-block-search__label screen-reader-text" for="wp-block-search__input-3" >Search</label><div class="wp-block-search__inside-wrapper" style="width: 100%"><input class="wp-block-search__input" id="wp-block-search__input-3" placeholder="" value="" type="search" name="s" required style="border-width: 1px"/><button aria-label="Search" class="wp-block-search__button has-background has-icon wp-element-button" type="submit" style="border-width: 1px;background-color: #f3931d"><svg class="search-icon" viewBox="0 0 24 24" width="24" height="24"> <path d="M13 5c-3.3 0-6 2.7-6 6 0 1.4.5 2.7 1.3 3.7l-3.8 3.8 1.1 1.1 3.8-3.8c1 .8 2.3 1.3 3.7 1.3 3.3 0 6-2.7 6-6S16.3 5 13 5zm0 10.5c-2.5 0-4.5-2-4.5-4.5s2-4.5 4.5-4.5 4.5 2 4.5 4.5-2 4.5-4.5 4.5z"></path> </svg></button></div></form></div> </div> <div style="height:48px" aria-hidden="true" class="wp-block-spacer"></div> <div class="wp-block-group alignwide is-content-justification-space-between is-layout-flex wp-container-core-group-is-layout-1d0a7695 wp-block-group-is-layout-flex"> <div class="wp-block-group is-layout-flex wp-block-group-is-layout-flex"><div class="is-default-size wp-block-site-logo"><a href="https://launchpad-design.co.uk/" class="custom-logo-link" rel="home"><img loading="lazy" width="731" height="279" src="https://launchpad-design.co.uk/wp-content/uploads/2026/01/launchpad_logo.jpg" class="custom-logo" alt="Launchpad Design news and articles" decoding="async" srcset="https://launchpad-design.co.uk/wp-content/uploads/2026/01/launchpad_logo.jpg 731w, https://launchpad-design.co.uk/wp-content/uploads/2026/01/launchpad_logo-300x115.jpg 300w" sizes="auto, (max-width: 731px) 100vw, 731px" /></a></div></div> </div> </div> </footer></div> <script type="speculationrules"> {"prefetch":[{"source":"document","where":{"and":[{"href_matches":"/*"},{"not":{"href_matches":["/wp-*.php","/wp-admin/*","/wp-content/uploads/*","/wp-content/*","/wp-content/plugins/*","/wp-content/themes/twentytwentyfive/*","/*\\?(.+)"]}},{"not":{"selector_matches":"a[rel~=\"nofollow\"]"}},{"not":{"selector_matches":".no-prefetch, .no-prefetch a"}}]},"eagerness":"conservative"}]} </script> <script id="eztoc-scroll-scriptjs-js-extra"> var eztoc_smooth_local = {"scroll_offset":"30","add_request_uri":"","add_self_reference_link":""}; //# sourceURL=eztoc-scroll-scriptjs-js-extra </script> <script id="eztoc-scroll-scriptjs-js" src="https://launchpad-design.co.uk/wp-content/plugins/easy-table-of-contents/assets/js/smooth_scroll.min.js?ver=2.0.87"></script> <script id="eztoc-js-cookie-js" src="https://launchpad-design.co.uk/wp-content/plugins/easy-table-of-contents/vendor/js-cookie/js.cookie.min.js?ver=2.2.1"></script> <script id="eztoc-jquery-sticky-kit-js" src="https://launchpad-design.co.uk/wp-content/plugins/easy-table-of-contents/vendor/sticky-kit/jquery.sticky-kit.min.js?ver=1.9.2"></script> <script id="eztoc-js-js-extra"> var ezTOC = {"smooth_scroll":"1","visibility_hide_by_default":"","scroll_offset":"30","fallbackIcon":"\u003Cspan class=\"\"\u003E\u003Cspan class=\"eztoc-hide\" style=\"display:none;\"\u003EToggle\u003C/span\u003E\u003Cspan class=\"ez-toc-icon-toggle-span\"\u003E\u003Csvg style=\"fill: #999;color:#999\" xmlns=\"http://www.w3.org/2000/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"\u003E\u003Cpath d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"\u003E\u003C/path\u003E\u003C/svg\u003E\u003Csvg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http://www.w3.org/2000/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"\u003E\u003Cpath d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"/\u003E\u003C/svg\u003E\u003C/span\u003E\u003C/span\u003E","chamomile_theme_is_on":""}; //# sourceURL=eztoc-js-js-extra </script> <script id="eztoc-js-js" src="https://launchpad-design.co.uk/wp-content/plugins/easy-table-of-contents/assets/js/front.min.js?ver=2.0.87-1787901608"></script> <script id="wp-emoji-settings" type="application/json"> {"baseUrl":"https://s.w.org/images/core/emoji/17.0.2/72x72/","ext":".png","svgUrl":"https://s.w.org/images/core/emoji/17.0.2/svg/","svgExt":".svg","source":{"concatemoji":"https://launchpad-design.co.uk/wp-includes/js/wp-emoji-release.min.js?ver=7.0.4"}} </script> <script type="module"> /*! This file is auto-generated */ var e="script#wp-emoji-settings",t=document.querySelector(e);if(!(t instanceof HTMLScriptElement))throw new Error("Element missing: "+e);const r=JSON.parse(t.text),s=(window._wpemojiSettings=r,"wpEmojiSettingsSupports"),o=["flag","emoji"];function i(e){try{var t={supportTests:e,timestamp:(new Date).valueOf()};sessionStorage.setItem(s,JSON.stringify(t))}catch(e){}}function c(e,t,n){e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(t,0,0);t=new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data);e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(n,0,0);const r=new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data);return t.every((e,t)=>e===r[t])}function p(e,t){e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(t,0,0);var n=e.getImageData(16,16,1,1);for(let e=0;e<n.data.length;e++)if(0!==n.data[e])return!1;return!0}function u(e,t,n,r){switch(t){case"flag":return n(e,"\ud83c\udff3\ufe0f\u200d\u26a7\ufe0f","\ud83c\udff3\ufe0f\u200b\u26a7\ufe0f")?!1:!n(e,"\ud83c\udde8\ud83c\uddf6","\ud83c\udde8\u200b\ud83c\uddf6")&&!n(e,"\ud83c\udff4\udb40\udc67\udb40\udc62\udb40\udc65\udb40\udc6e\udb40\udc67\udb40\udc7f","\ud83c\udff4\u200b\udb40\udc67\u200b\udb40\udc62\u200b\udb40\udc65\u200b\udb40\udc6e\u200b\udb40\udc67\u200b\udb40\udc7f");case"emoji":return!r(e,"\ud83e\u1fac8")}return!1}function f(e,t,n,r){let a;const s=(a="undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?new OffscreenCanvas(300,150):document.createElement("canvas")).getContext("2d",{willReadFrequently:!0}),o=(s.textBaseline="top",s.font="600 32px Arial",{});return e.forEach(e=>{o[e]=t(s,e,n,r)}),o}function a(e){var t=document.createElement("script");t.src=e,t.defer=!0,document.head.appendChild(t)}r.supports={everything:!0,everythingExceptFlag:!0},new Promise(t=>{let n=function(){try{var e=JSON.parse(sessionStorage.getItem(s));if("object"==typeof e&&"number"==typeof e.timestamp&&(new Date).valueOf()<e.timestamp+604800&&"object"==typeof e.supportTests)return e.supportTests}catch(e){}return null}();if(!n){if("undefined"!=typeof Worker&&"undefined"!=typeof OffscreenCanvas&&"undefined"!=typeof URL&&URL.createObjectURL&&"undefined"!=typeof Blob)try{var e="postMessage("+f.toString()+"("+[JSON.stringify(o),u.toString(),c.toString(),p.toString()].join(",")+"));",r=new Blob([e],{type:"text/javascript"});const a=new Worker(URL.createObjectURL(r),{name:"wpTestEmojiSupports"});return void(a.onmessage=e=>{i(n=e.data),a.terminate(),t(n)})}catch(e){}i(n=f(o,u,c,p))}t(n)}).then(e=>{for(const n in e)r.supports[n]=e[n],r.supports.everything=r.supports.everything&&r.supports[n],"flag"!==n&&(r.supports.everythingExceptFlag=r.supports.everythingExceptFlag&&r.supports[n]);var t;r.supports.everythingExceptFlag=r.supports.everythingExceptFlag&&!r.supports.flag,r.supports.everything||((t=r.source||{}).concatemoji?a(t.concatemoji):t.wpemoji&&t.twemoji&&(a(t.twemoji),a(t.wpemoji)))}); //# sourceURL=https://launchpad-design.co.uk/wp-includes/js/wp-emoji-loader.min.js </script> </body> </html>