Category: Nerdy

  • Designing Fintech Onboarding Flows That Satisfy FCA Compliance Without Destroying UX

    Designing Fintech Onboarding Flows That Satisfy FCA Compliance Without Destroying UX

    Regulatory weight and conversion rate sit at opposite ends of a very uncomfortable seesaw. The FCA mandates identity verification, risk disclosures, appropriate target market assessments, and explicit consent capture. Your head of growth wants a three-screen sign-up that takes under two minutes. Both of them are right, which is precisely what makes fintech onboarding UX FCA compliance UK work so genuinely difficult to get right. I’ve spent time across several fintech projects watching perfectly good onboarding flows collapse under the weight of legal requirements bolted on at the last minute, and the pattern is always the same: compliance treated as a decoration applied after the design is done, rather than a structural constraint built into it from day one.

    The good news is that the FCA’s requirements, read carefully, don’t actually demand bad UX. They demand specificity, honesty, and informed consent. A well-designed flow can deliver all three without feeling like a GDPR cookie banner multiplied by a mortgage application.

    Person holding smartphone showing fintech onboarding UX designed for FCA compliance in the UK
    Photo by Julio Lopez on Pexels

    Where most fintech onboarding flows go wrong structurally

    The most common structural mistake I see is treating every compliance step as a discrete screen break. Identity document upload on screen four, risk disclosure on screen six, consent checkboxes on screen nine. Each one feels like a toll booth, and users mentally clock every stop. The alternative is to think about compliance requirements as information architecture decisions, not interruptions. KYC document capture, for instance, can be sequenced after the user has already committed to a goal: they’ve told you they want to invest, they’ve seen projected outcomes, they understand what they’re signing up for. Asking for ID at that point feels earned rather than arbitrary.

    Sequencing is half the battle. The other half is copy. Risk warnings on UK-regulated products, particularly for investments and consumer credit, tend to arrive pre-written from legal teams in fonts small enough to require a magnifying glass and phrasing dense enough to require a law degree. The FCA’s Consumer Duty rules, which came into full effect for closed book products in July 2024, push firms to communicate in a way that customers can actually understand. That’s a design problem as much as a legal one. Breaking a risk statement into a short headline, a two-sentence plain-English summary, and a collapsible “full details” section isn’t hiding information; it’s presenting it in a hierarchy that matches how humans actually read. The full text is always there. It’s just not the first thing you see.

    Designing identity verification that doesn’t feel like airport security

    KYC is the step where onboarding flows lose the most users, and the drop-off is rarely because users don’t want to verify their identity. It’s because the experience makes them feel like suspects. A few principles I keep coming back to: tell users why you’re asking before you ask. “We’re required by UK law to confirm your identity before you can invest” lands completely differently to a cold request to photograph your passport. Frame it as protection for them, because it genuinely is.

    Camera and document capture UX deserves proper engineering time. Liveness checks from providers like Onfido or Jumio have their own SDKs with reasonable default flows, but the screens before and after them, the instructions, the error states, the success confirmation, are yours to design. Error states in particular are where I’ve seen teams get lazy. “Verification failed” is not a helpful message. “We couldn’t read the text on your document clearly; try in a well-lit space and avoid glare on the document surface” is. One of those recovers the user. The other sends them to your support queue or, more likely, away entirely.

    Re-upload flows need the same care. If a document is rejected at the provider level, the user needs to understand the specific reason, have a clear path to try again, and ideally be able to do so without starting the whole onboarding journey from scratch. Session persistence during KYC is not a nice-to-have. It’s conversion-critical.

    Passport and smartphone showing mobile identity verification as part of fintech onboarding UX FCA compliance
    Photo by Leeloo The First on Pexels

    Risk disclosures and target market assessments done without alienating users

    The FCA’s appropriateness and suitability requirements for investment and credit products mean you have to gather information about a user’s financial situation, knowledge, and risk appetite before they can proceed. Designed badly, this feels like a test they might fail. Designed well, it feels like personalisation. The difference is framing and feedback.

    Appropriateness questionnaires should show progress, explain why each question matters, and give contextual help for any term that might be unfamiliar. “What do you understand by ‘capital at risk’?” is a reasonable regulatory question. But if you don’t give users a way to learn the answer before they answer, you’re testing knowledge rather than ensuring understanding, which is a different thing entirely. An expandable tooltip or a micro-explanation card below the question adds maybe two hours of design time and measurably reduces incorrect responses that then generate even more friction downstream.

    For fintech onboarding UX FCA compliance UK to actually work at scale, risk disclosure copy needs to be tested with real users, not just approved by legal. The FCA doesn’t prescribe the exact format of most risk warnings; it prescribes what they must communicate. That leaves significant room for a design team to present legally sound information in a human way. I’d strongly recommend reading the FCA’s own Consumer Duty guidance directly, because the emphasis on “consumer understanding” as an explicit outcome gives you genuine leverage in conversations with legal teams who default to dense small-print.

    Consent capture without the checkbox graveyard

    There’s a pattern I call the checkbox graveyard: seven or eight tick-boxes at the end of onboarding, each one linking to a PDF document somewhere in the cloud, with phrasing like “I have read and agree to the terms, conditions, privacy policy, cookie policy, risk disclaimer, investment restriction notice, and marketing preferences.” Every one of those items deserves its own moment. Bundled together, they’re legally questionable under PECR and UK GDPR, and they produce consent that users don’t actually understand they’ve given.

    Disaggregated consent is both better UX and better compliance. Break it into distinct steps: contractual terms (one screen, with a summary of key points), risk acknowledgement (specific to the product type, not generic), and marketing preferences (entirely optional, clearly separated, no dark patterns). This feels longer in a flow diagram but shorter in practice, because each decision is clear and fast rather than vague and anxious. The same principle applies when designing for financial compliance more broadly: every regulatory requirement is an opportunity to build trust, not just a hurdle to clear.

    One practical note on marketing consent: do not pre-tick it. Not just because UK GDPR requires it to be active rather than pre-ticked, but because pre-ticked consent generates low-quality marketing lists that cost you more in email deliverability and engagement metrics than the marginal extra opt-ins are ever worth.

    Testing compliance flows without breaking your recruitment budget

    Usability testing on regulated flows has one specific challenge: you can’t just grab five people from your network and call it research, because the target market assessments your FCA authorisation requires are based on specific user segments. You need to test with representative users, people who match the financial sophistication profile your product is designed for. That takes slightly more recruitment effort, but the signal quality is worth it.

    Prototype early and ugly. Compliance copy is the one place I’ll argue for testing literally with legal team-supplied text before any design polish is applied. If users can’t understand the risk warning in a bare wireframe, a better colour palette won’t fix it. Get the words right first. The design layer makes good information clear; it can’t make bad information legible.

    It’s also worth thinking about how compliance-forward design thinking bleeds into adjacent industries. Organisations handling environmental reporting, EPC certificates, and energy efficiency commitments face their own disclosure-heavy regulatory requirements, and some of the same UX principles transfer. Compliance as copy clarity, progressive disclosure of dense information, and earned consent. Nottingham-based R2G.co.uk (https://www.r2g.co.uk/), which helps organisations make substantive changes to their energy and sustainability practices, including climate action planning and solar panel deployment, deals with its own form of compliance-laden client communication around energy saving targets and environmental obligations. The challenge of making regulation feel human is not unique to fintech.

    The fintech onboarding UX FCA compliance UK problem isn’t going away; if anything, Consumer Duty enforcement will tighten the expectations on how clearly regulated information must be communicated. But the firms that treat that as a design challenge rather than a legal obstacle tend to end up with better products. The constraints are real. So is the opportunity.

    For teams working on the visual systems underpinning these flows, the kind of rigorous colour and contrast thinking covered in how UK design teams are solving semantic colour token problems is directly relevant, particularly when you’re rendering risk warnings and legal text that must meet WCAG accessibility standards. Equally, if your onboarding has meaningful motion or state transitions, the production concerns from CSS scroll-driven animations in production apply to anything that animates between compliance steps. Smooth progress transitions are fine. Obscuring the fact that a user is looking at a risk warning is not.

    The firms getting fintech onboarding UX FCA compliance UK right are not the ones with the most aggressive conversion optimisation. They’re the ones that decided compliance legibility is a brand value, not a checkbox. That framing changes every design decision that follows.

  • Print Is Not Dead: How UK Editorial Designers Are Using InDesign and Variable Data Printing to Produce Hyper-Personalised Collateral

    Print Is Not Dead: How UK Editorial Designers Are Using InDesign and Variable Data Printing to Produce Hyper-Personalised Collateral

    There’s a particular kind of satisfaction in holding something printed. The weight of it, the slight resistance of the paper. I’ve been watching UK studios quietly rediscover that feeling, and what’s interesting is that it’s not nostalgia driving the movement. It’s data. Specifically, variable data printing editorial design UK workflows are getting genuinely sophisticated in ways that digital-first teams haven’t really caught up with yet.

    Budget is moving. Not dramatically, not in ways that make headlines, but in ways you notice when you talk to creative directors at mid-sized British publishers and brand studios. Some of them are shifting meaningful portions of their collateral spend back into print, and the reason is almost always the same: digital has become so cheap and so saturated that well-crafted physical mail actually stands out again.

    Editorial designer working on variable data printing editorial design UK project in InDesign with printed proofs on desk
    Photo by alleksana on Pexels

    What variable data printing actually is (and why it’s not just mail merge)

    Variable data printing, or VDP, lets a single print run produce thousands of unique documents. Each piece can have a different name, different image, different copy block, different offer, different layout. The data is pulled from a structured source, mapped to placeholders in a template, and the press (typically a digital inkjet or laser system) renders each version on the fly.

    People hear “variable data” and immediately think of those slightly creepy mailers from the early 2000s where your name appeared in the middle of a stock photo of a house. That was the technology at its clumsiest. What’s happening now in serious editorial design studios is much more considered. A good VDP workflow in 2026 treats personalisation as a design constraint, not a gimmick. The grid has to accommodate variation without breaking. The typography has to hold across name lengths from “Jo” to “Bartholomew”. The colour logic has to survive when the lifestyle image swaps from a 50-year-old in a garden to a 25-year-old in a flat.

    InDesign is still the dominant tool for building these templates. Adobe’s Data Merge panel is functional if a bit clunky, and most serious studios supplement it with scripts or use specialist VDP software like XMPie or Objectif Lune’s PlanetPress that can talk directly to InDesign’s document structure. The data itself usually lives in a CSV or comes via API from a CRM. GDPR compliance is, obviously, the first conversation anyone has before a campaign touches a database, and the ICO’s direct marketing guidance is worth bookmarking if you’re setting up a UK campaign for the first time.

    Grid discipline and why it matters more in print than on screen

    This is the bit digital designers consistently underestimate. On screen, a broken layout is a CSS bug, usually fixable in minutes. In print, a broken layout is waste. Expensive, irreversible waste.

    Serious VDP editorial design in the UK relies on grids that are genuinely stress-tested. A baseline grid isn’t optional, it’s structural. Every text frame has minimum and maximum character count rules baked into the data specification, because if a customer’s address runs to six lines instead of three, the whole composition shifts. Studios I’ve spoken to talk about “safe zones” for variable content, designing fixed anchor points that keep the piece visually coherent regardless of what the data throws at it.

    The grid discipline required for print VDP is, frankly, more rigorous than most web design systems I’ve seen. If you’ve read our walkthrough on building a design token pipeline with Style Dictionary, you’ll recognise the underlying logic: systematic constraints that scale. The difference is that in print, the constraints are physical, not just conceptual.

    Which UK studios and publishers are actually doing this well

    The publishing sector has been at this longest. Condé Nast UK and Immediate Media have been running sophisticated subscriber personalisation programmes for years, but what’s changed recently is that smaller independent publishers are now accessing the same level of workflow tooling. Print-on-demand infrastructure has dropped in price significantly, and the minimum viable run for a personalised campaign is now genuinely accessible to an independent magazine or a B2B publisher working with a list of a few thousand contacts.

    Charity direct mail has also had a quiet renaissance. Organisations that moved aggressively into digital fundraising between 2018 and 2023 found response rates collapsing as email inboxes became unmanageable. Several UK charities, including some household names, have returned to highly personalised print appeals that reference a donor’s specific giving history. The conversion rates on these, compared to equivalent digital touchpoints, are notable enough that they’re rebalancing budgets.

    On the brand side, a number of UK luxury and premium consumer brands, particularly in homeware, food and drink, and financial services, are investing in print that explicitly signals they’re not doing this digitally. A well-designed, personalised printed piece says something about a brand’s confidence that a triggered email sequence simply cannot.

    The InDesign workflow in practice

    A typical VDP project at a UK design studio starts with data mapping, before anyone touches InDesign. You audit the data fields available from the client’s CRM, decide which fields are reliable enough to use in personalisation (postcode segment, product category, donation history, subscription tier), and then design the logic rules: if field X is empty, fall back to Y; if field Z exceeds 30 characters, use abbreviated version.

    Template construction then follows standard InDesign editorial practice, except every text frame and image frame that will vary is tagged. Scripts handle the repetitive work of merging and preflight checking each record. Output is usually a batched PDF handed to the print supplier, or increasingly a JDF-compliant file that talks directly to the press.

    Colour management is where a lot of studios get caught out. RGB-to-CMYK conversion in a variable workflow can produce subtle inconsistencies across a run if profiles aren’t locked down at the export stage. ISO 12647-2 is the relevant standard for offset and digital print in the UK, and any serious print supplier will expect you to be working to it. If your studio is primarily digital-first, this colour discipline is genuinely different from preparing assets for screen, and it’s worth the investment in a proper profile workflow before your first print run.

    Why some UK brands are moving budget back from digital to physical

    The economics are worth examining clearly. A well-executed VDP direct mail campaign in the UK has a cost per piece somewhere between £1.50 and £5 depending on format, personalisation complexity, and run length. That sounds expensive next to a 0.3p email. But response rates on quality print campaigns from Royal Mail’s own research have consistently run at 3-5% for direct mail, against sub-1% for email in saturated categories.

    Physical print also doesn’t get blocked by an ad blocker, isn’t filtered into a promotions tab, and doesn’t disappear when a platform changes its algorithm. Those constraints matter quite differently once you’ve watched a Meta advertising account get suspended at short notice, or watched organic social reach collapse. Several UK brand teams I’ve spoken to describe print as a channel that’s predictable in a way that digital increasingly isn’t.

    There’s also a connection to how design systems are being thought about more holistically. Our article on how UK publishing houses are bridging print and web design systems covers the token and brand identity side of this in more detail, but the broader point is that studios are being asked to think across both surfaces again rather than treating print as an afterthought.

    What frontend and digital designers can take from this

    I’d argue the grid rigour and the data-conditional design thinking that VDP demands are directly transferable to component design on screen. The problem of “what does this layout look like when the content field is unexpectedly long?” is exactly the same problem you’re solving when you build a card component that needs to handle both a two-word label and a twelve-word one. If you’re working on UI systems, reading how print designers solve layout stress-testing is genuinely useful. It’s the same intellectual muscle.

    The personalisation logic also maps closely to what frontend teams are doing with edge-rendered conditional content, something we’ve covered in the context of Cloudflare Workers and Vercel Edge for UK web performance. The underlying idea, serving different content to different users based on structured data, is the same. Print just does it with ink and paper instead of JavaScript.

    Print isn’t coming back to displace digital. But for UK studios and publishers who’ve spent a decade assuming print was a diminishing line item, the numbers are making a reasonably compelling case for a second look. Variable data printing in particular has reached a level of tooling maturity where the design discipline required is genuinely interesting, and the results, when the grid work is done properly, are impressive in a way that a targeted push notification simply isn’t.

    Frequently Asked Questions

    What is variable data printing and how does it differ from standard print runs?

    Variable data printing allows each piece in a print run to contain unique content, such as different names, images, or copy, pulled from a data source like a CSV or CRM. Unlike a standard print run where every sheet is identical, VDP renders each record individually, making large-scale personalised collateral possible on a single press pass.

    Which software do UK studios use for variable data printing workflows?

    Adobe InDesign with its Data Merge panel is the most common starting point, often supplemented with custom scripts. For more complex campaigns, specialist tools like XMPie or PlanetPress integrate directly with InDesign’s document structure and offer more robust data logic, conditional rules, and preflight checking across thousands of records.

    Is variable data printing GDPR compliant in the UK?

    VDP campaigns using personal data must comply with UK GDPR and the Privacy and Electronic Communications Regulations. This means having a lawful basis for processing, honouring opt-outs, and handling data securely throughout the workflow. The ICO publishes specific direct marketing guidance that covers the key requirements for UK print campaigns.

    How much does a variable data printing campaign cost in the UK?

    Cost per piece typically runs between £1.50 and £5 depending on format, paper stock, personalisation complexity, and run length. Shorter runs and more complex personalisation push the cost up, but this needs to be weighed against response rates, which Royal Mail’s research consistently places at 3-5% for quality direct mail compared to under 1% for email in saturated categories.

  • Designing Invoicing and Payment Interfaces for UK Freelancers: The VAT, MTD, and HMRC Details That Actually Matter

    Designing Invoicing and Payment Interfaces for UK Freelancers: The VAT, MTD, and HMRC Details That Actually Matter

    There is a surprisingly narrow gap between an invoicing tool that genuinely helps a UK self-employed person and one that technically works but quietly drives them mad every time they raise a bill. I have spent a fair amount of time poking around tools like FreeAgent, QuickBooks, Xero, and Zoho Invoice from a design perspective rather than an accountant’s, and what I keep finding is the same cluster of UI decisions made by people who either don’t understand how UK freelancers actually bill, or who designed for a generic global user and bolted on a ” UK mode” as an afterthought. The details really do matter here, and invoicing app design for UK freelancers, specifically around MTD, is one of those domains where a handful of small interface choices either build or completely destroy a user’s trust.

    Freelancer reviewing invoicing app design for UK MTD compliance on laptop
    Photo by cottonbro studio on Pexels

    Why invoicing is a harder UX problem than it looks

    On the surface, an invoice is just a document with some numbers on it. The complexity creeps in the moment you layer on the UK-specific regulatory context. A self-employed person in the UK might be VAT-registered or not. If they are, they need to apply the correct rate (standard 20%, reduced 5%, or zero-rated), show the VAT amount as a separate line, display their VAT registration number on the invoice face, and generate a quarterly summary that feeds into a Making Tax Digital-compatible submission to HMRC. If they are not VAT-registered, none of that applies, but the interface still has to handle the state gracefully rather than just hiding fields and leaving a confusing gap in the layout.

    MTD for Income Tax Self Assessment (ITSA) is rolling out to sole traders and landlords with income above £50,000 from April 2026, dropping to £30,000 from April 2027, according to HMRC’s own guidance on Making Tax Digital. That means a significant chunk of self-employed users are going to need their invoicing tool to connect directly to HMRC’s API infrastructure, or at least export data in a format a bridging tool can consume. If the app’s data model doesn’t cleanly separate gross income, allowable expenses, and tax by quarter, the UI will become a mess of manual workarounds.

    The VAT calculation problem is mostly a UI sequencing problem

    I’d argue that most VAT errors in invoicing UIs are not calculation errors at all. They are sequencing errors. The app asks for a line item amount, and it is unclear whether that amount is exclusive or inclusive of VAT. Some tools default to exclusive (the accountant-friendly default) without making that obvious to a user who typed in a round number expecting it to be what the client pays. Others toggle the behaviour per line item but hide the toggle in a settings panel three levels deep.

    The cleanest pattern I have seen is a persistent, visible label directly adjacent to every price input: a small toggle that reads “ex. VAT” or “inc. VAT”, styled as a segmented control rather than buried in a dropdown. The gross and net amounts then update live beneath the input. This sounds obvious. Very few tools actually do it. FreeAgent gets close, though it tends to assume ex. VAT at all times, which trips up newer freelancers who quote inclusive prices to clients.

    Partial exemption is where things get genuinely gnarly. A designer who also licenses stock assets might have a mix of standard-rated and exempt supplies on the same invoice. The interface needs to handle mixed-rate line items without requiring the user to split the invoice manually. This is rare enough that most tools don’t bother, but for micro-agencies it comes up constantly. If you’re designing a micro-SaaS product aimed at solo UK developers, this is exactly the kind of edge case that separates a tool worth paying for from one people drop after two months.

    Payment status states: the UI gets lazy here every time

    An invoice is not a static document. It passes through multiple states over its lifetime, and a well-designed tool treats each state as a distinct UI moment with distinct affordances. The states a UK freelancer actually cares about are broadly: draft, sent, viewed (if read receipts are available), partially paid, overdue, paid, and written off. Most apps handle draft and paid. The middle ground is where the design falls apart.

    “Overdue” is particularly underserved. An invoice becomes overdue the moment it passes its payment terms date. The correct UI response is an immediate, ambient status indicator on the invoice list view, not a buried orange badge that only appears when you open the individual record. The list view should surface: how many days overdue, the outstanding amount, and a one-click chase action that generates a polite reminder email using the client’s name pulled from the contact record. Xero’s invoice list is reasonable here. Zoho Invoice used to be terrible at this but improved around late 2024.

    Partial payment is handled badly by almost everyone. The UI typically shows a payment received, subtracts it from the total, and leaves the remaining balance visible on the invoice record. What it rarely does is update the invoice status label to something meaningful like “Part paid” or show a visual progress bar on the payment. A bar showing £600 received against a £1,200 invoice is immediately scannable. A number buried in a summary table is not. This is a basic data visualisation principle that applies just as much to invoicing as it does to analytics dashboards.

    There’s also the question of what happens after payment is marked. Most tools do nothing. A smart tool archives the invoice, updates the client’s payment history, and optionally prompts the user to log any bank transfer fees as an expense, keeping the MTD records clean. That last step is the kind of thought that shows real understanding of the workflow, not just the document format.

    MTD compliance in the UI: what it actually requires you to show

    Making Tax Digital for ITSA requires digital records of income and expenses, quarterly submissions, and a final declaration. For an invoicing tool, the UI implication is that every invoice needs to be classifiable by tax year and quarter at the point of creation, not retroactively. Some tools make you tag invoices manually by quarter; this is a design failure. The quarter should be inferred automatically from the invoice date and the user’s accounting period settings, with a visible indicator on the invoice record confirming which submission it will roll into.

    The quarterly summary view is where most tools currently fail their UK users most visibly. What a freelancer needs to see, in plain language, is their total taxable income for the quarter, their allowable expenses, and the net figure that will be submitted to HMRC. Many apps show these figures somewhere, but they are scattered across separate reports rather than surfaced as a single pre-submission dashboard. The GOV.UK Design System approach of task-based progress states would work beautifully here: a checklist that shows which invoices are categorised, which expenses are logged, and whether the quarter is ready to submit. Incidentally, there is a lot the public sector has figured out here that the private sector still ignores, which I wrote about separately in a piece on what the GOV.UK Design System gets right that most private sector UI libraries get wrong.

    The submission itself should be a single action with a clear confirmation state. Currently, most tools that support MTD direct submission show a modal, ask for confirmation, fire the API call, and then return the user to the dashboard with no persistent record of what was submitted or when. The correct pattern is a submission receipt view with a timestamp, a reference number from HMRC, and a link to download the submitted data as a PDF. Audit trails matter for compliance and they matter for the user’s peace of mind.

    Small details that builders consistently miss

    A few things I would add to any design spec for this kind of tool. First, the invoice number sequence. UK freelancers often have clients who require invoices to follow a specific format, and the ability to customise the prefix and starting number is non-negotiable. But the UI should also warn users if they are about to create a gap in the sequence, because a missing invoice number can flag a VAT audit.

    Second, currency handling. A UK freelancer who invoices in GBP but occasionally bills an EU client in euros needs the tool to record the sterling equivalent at the exchange rate on the invoice date, for MTD record-keeping purposes. This is largely ignored by mid-market tools. If you’re thinking about building something in this space and you’ve looked at how Figma’s Dev Mode handles complex state management between design and code, the principle is similar: the source of truth needs to be unambiguous even when the display layer shows a different unit.

    Third, the statement of account view. Many UK clients request a statement rather than individual invoices when settling multiple bills at once. This is a separate document type with its own UI requirements: it lists all outstanding invoices for a given client, with dates, amounts, and running balances. Most invoicing tools treat this as a secondary feature or don’t have it at all. For a freelancer managing ten or more active clients, it’s essential.

    The invoicing interface is genuinely one of the most legally consequential UIs a self-employed person uses. Getting it wrong is not just a UX annoyance; it can mean a failed VAT return or a compliance gap in their MTD records. That’s reason enough to design it properly from the start, rather than treating the UK regulatory layer as a localisation task someone can bolt on in a sprint.

  • Designing for the NHS App Ecosystem: What Third-Party Health Developers Need to Know About NHS Design Patterns

    Designing for the NHS App Ecosystem: What Third-Party Health Developers Need to Know About NHS Design Patterns

    If you’ve ever tried to build a companion app or integration layer for the NHS ecosystem, you’ll know the experience is somewhere between solving a puzzle with missing pieces and navigating a labyrinth designed by committee. The documentation exists. The NHS Digital Service Manual is actually one of the better-maintained design systems in the UK public sector. The problem isn’t the documentation. The problem is that most health tech startups read it the way people read terms and conditions: quickly, selectively, and with total confidence they’ve understood the important bits.

    They haven’t. I’ve seen the same mistakes repeat across a dozen health tech projects, from GP appointment add-ons to mental health tracking apps trying to slot into NHS workflows. So let’s go through what’s actually being misunderstood, because some of these errors go beyond aesthetics into genuinely risky territory.

    Tablet displaying NHS design patterns in a clinical setting
    Photo by Matheus Bertelli on Pexels

    Why NHS design patterns are not just a visual style guide

    The first and most common misconception: teams treat NHS design patterns as a branding exercise. Copy the blue. Use the logo typeface (Frutiger, or the open-source Fraunhofer approximation). Borrow the card components. Job done, looks credible.

    That’s backwards. The NHS design system is built around a set of interaction principles and a specific clinical context that most commercial UI thinking doesn’t account for at all. The GOV.UK Design System, which shares some DNA, at least gets discussed in design circles (I wrote about what GOV.UK gets right that private sector UI libraries get wrong a while back), but the NHS variant has additional constraints layered on top, because the users and stakes are different.

    Consider one obvious example: error messaging. In a typical SaaS product, an error message is a minor friction point. In a clinical UI, an error message about a dosage input or an appointment slot could cause a patient to take the wrong action. The NHS Service Manual specifies error summary patterns precisely because the consequences of user confusion in health contexts are categorically different from, say, a failed checkout flow. The pattern is not decoration. It is a risk mitigation tool.

    What health tech startups consistently get wrong about accessibility

    WCAG 2.2 compliance gets mentioned in every NHS digital service assessment, and most teams know this, at least in theory. In practice, I see two failure modes.

    The first is treating accessibility as a checklist rather than a design constraint. Teams run an automated audit with axe or Lighthouse, fix the obvious contrast ratios, add some aria-labels, and declare compliance. But automated tools catch roughly 30-40% of WCAG issues. The remainder, focus order, screen reader narrative flow, meaningful alternative text, timeout behaviour for users with cognitive impairments, only surfaces in manual testing with real assistive technology.

    The second failure mode is misunderstanding the NHS user base. NHS app users are not a homogeneous tech-savvy audience. As I covered in my piece on designing for older users and accessibility, the over-55 demographic represents a huge proportion of NHS service users, and they interact with digital interfaces in ways that invalidate many assumptions baked into modern component libraries. Small tap targets, hover-only states, icons without labels, modals that trap keyboard focus badly: all of these become genuine barriers at scale when your user base skews older and potentially has reduced motor control or vision impairment.

    Developer writing code for NHS design patterns component library
    Photo by Harold Vasquez on Pexels

    The NHS explicitly requires user research with real patients as part of service assessments. Not personas. Not assumed user journeys mapped on a whiteboard. Actual sessions with actual people. Teams that skip this stage almost always pay for it later, either in failed assessments or in post-launch complaints that damage the trust relationship with NHS partners.

    Trust signals in clinical UI: where commercial design intuitions break down

    Here’s where it gets philosophically interesting. Commercial product design has spent the last decade optimising for conversion: clear CTAs, reduced friction, bright colour on primary actions, social proof via user counts and review scores. Health tech apps that import these patterns wholesale often end up looking untrustworthy to clinical users, and sometimes to patients.

    Clinical trust operates differently. A patient interacting with a mental health app doesn’t want it to feel like a productivity tool. They want it to feel safe, unhurried, and unambiguous. This means generous whitespace (which commercial designers sometimes read as “wasted space”), plain language at a reading age appropriate for a wide public audience, and absolutely no dark patterns near anything related to consent or data sharing.

    The NHS has very specific guidance on data handling UI precisely because health data is special category data under UK GDPR. The ICO and NHS England both publish guidance on this. If your consent flows borrow the kind of nudge patterns you’d find on a subscription cancellation screen (pre-ticked boxes, vague opt-in language, confusing toggle states), you are not just creating bad UX. You are potentially creating a legal and regulatory problem. I wrote about UK consumer protection and UX design in a different context, but the principle around manipulation through UI design is directly applicable here.

    The NHS digital service standard: what the assessment process actually demands

    Teams building apps that will connect to NHS systems, or carry NHS branding, typically need to pass a Digital Technology Assessment Criteria (DTAC) review. This is not the same as simply passing an NHS design assessment, and conflating them is a common error.

    DTAC covers clinical safety (DCB0129 compliance), data protection, technical security, interoperability (FHIR R4 where relevant), and usability. The clinical safety requirement alone, which requires a named Clinical Safety Officer and a documented hazard log, catches many startups completely off guard. This is not a box-ticking exercise. A hazard log means identifying the ways your software could harm a patient if it behaves unexpectedly, and documenting what you’ve done to mitigate each risk.

    I’ve seen teams, including a couple of otherwise well-run companies that handle complex integrations, treat the DTAC process as a hurdle to clear rather than a framework that makes their product genuinely safer. The distinction matters enormously when something goes wrong. Agencies building products with technical integration complexity, like Dijitul Developments, understand that integration architecture decisions made early have compliance implications downstream, and the same is true in spades for health tech builds touching NHS infrastructure.

    Component library choices and why “looks NHS” is not enough

    The NHS frontend library is open source and available on GitHub. It covers form components, navigation patterns, warning callouts, and action links. Using it is sensible. But a few nuances trip people up.

    First, the library is React-agnostic by design, but most health tech teams are building in React or React Native. The official components are vanilla HTML/CSS/JS. There are community-maintained React wrappers, but these are not officially supported, and their fidelity to the latest NHS frontend version varies. Teams need to own the maintenance overhead if they use them.

    Second, the NHS design system has specific guidance on what components to use for clinical decision support contexts versus patient-facing contexts. Using a summary card component (designed for showing appointment details to a patient) inside a clinician-facing dashboard creates cognitive dissonance for clinical staff who have built up a mental model of what each pattern means. Context collapse in UI is a real problem that purely visual pattern-matching doesn’t prevent.

    What building well actually looks like

    The teams I’ve seen do this well share a few habits. They read the NHS service manual properly, including the content design guidance, which is where a lot of the philosophy is actually explained. They involve a clinical safety lead from the start rather than bolting one on before submission. They conduct genuine usability testing with NHS staff and patients, not just developers who have become blind to their own interface.

    They also build with the understanding that NHS design patterns are living documents. The manual updates. Guidance around things like app accessibility and FHIR integration evolves. Setting up a process to track changes, rather than treating the design system as a one-time reference, is the difference between a product that stays compliant and one that quietly drifts out of alignment.

    Getting this right is genuinely hard. But the NHS has done a lot of the thinking for you, if you’re willing to engage with it seriously rather than skin-deep.

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

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

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

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

    Why British developers specifically are drawn to pixel aesthetics

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

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

    The tooling behind modern pixel art game design

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

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

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

    Colour palette constraints as a design decision, not a limitation

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

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

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

    How this connects to broader UI and UX craft

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

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

    EGX and the studio ecosystem making this real

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

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

    Animation within the constraint: where the real craft lives

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

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

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

  • Motion design on a budget: how UK freelancers are using CSS @starting-style and View Transitions API to ditch After Effects

    Motion design on a budget: how UK freelancers are using CSS @starting-style and View Transitions API to ditch After Effects

    There is a very specific kind of dread that hits when a client says “can we make it feel more animated?” and you know your budget doesn’t stretch to a Motion designer with an After Effects licence. For a long time the answer was either a clunky JavaScript library, a GIF someone exported badly, or a frank conversation about scope. That’s changing. The CSS view transitions API and the @starting-style at-rule have quietly arrived in production-ready browsers, and between them they let you ship animation work that would have required a full motion stack twelve months ago. I’ve been folding both into client projects over the past six months and the results are genuinely surprising.

    Web developer writing CSS view transitions API code for UK web design project
    Photo by Lukas Blazek on Pexels

    What the view transitions API actually does

    The short version: it gives the browser a built-in mechanism for animating between two states of a page, or two separate pages entirely, without you having to manually capture snapshots, manage z-indices, or reach for a library like Framer Motion. You call document.startViewTransition(), update the DOM inside the callback, and the browser handles the crossfade. Out of the box that crossfade is a simple opacity dissolve. The interesting bit is what happens when you start using view-transition-name on specific elements.

    Give a card component the property view-transition-name: product-card, navigate to a detail page where the same element carries the same name, and the browser will automatically interpolate the element’s position and size between the two states. It looks like the element physically moves from one page to the other. This is what used to require either a shared-element transition library or a fairly involved JavaScript animation that manually tracked bounding boxes. Now it’s four lines of CSS.

    Browser support at the time of writing sits at around 90% globally according to Can I Use, with Firefox having shipped full support in version 125. For CSS view transitions API UK web design work, that number is good enough to use without a heavy fallback strategy. A quick @supports (view-transition-name: none) guard is all you need for the remaining edge cases.

    Where @starting-style fits in

    The @starting-style at-rule solves a different but equally annoying problem. CSS transitions have always been unable to animate an element from its initial rendered state, because by the time the browser applies your transition, the starting values are already gone. The classic workaround was a JavaScript double-rAF trick: set initial styles, wait a frame, apply final styles, let CSS transition do the rest. Horrible to maintain, prone to flickering on slow devices.

    @starting-style lets you declare the styles an element should start from before it first renders. A modal that fades in from opacity: 0 and slides up from transform: translateY(8px) now needs zero JavaScript to achieve that entry animation. The CSS handles the whole thing. Combined with the transition-behavior: allow-discrete property for animating display: none to display: block, you can build fully animated show/hide patterns that would previously have required a library like Alpine.js just to manage class toggling.

    Close-up of CSS view transitions API and @starting-style code in a dark editor
    Photo by Bibek ghosh on Pexels

    What this means for UK freelancers on tighter budgets

    The practical upshot is that the expensive part of the motion design stack is getting smaller. After Effects is brilliant software but its annual licence through Adobe Creative Cloud sits north of £300 per year, and that’s before you factor in the export workflow: render to video, optimise, embed, deal with autoplay policies, repeat for every browser quirk. For a freelancer billing at typical UK day rates, that overhead is significant. CSS view transitions API UK web design work sidesteps most of it.

    The kinds of animations that previously justified that overhead, things like page transitions, element morphs, list reordering effects, tooltip entrances, were the ones clients most often requested. They’re also exactly the animations these new primitives handle well. You’re not replacing a full-blown After Effects composition reel with CSS. You’re replacing the mundane, repetitive motion work that consumed time without requiring genuine creative complexity.

    Web design agencies handling high volumes of client projects are starting to notice the shift. Based in Mansfield, Nottinghamshire, dijitul (dijitul.uk) is a digital agency specialising in web design, SEO, and hosting that works across a broad range of business clients. For agencies like that, where business efficiency and marketing output per project matter, shifting routine animation work from JavaScript-heavy software to native CSS primitives compresses delivery timelines without sacrificing the polish clients expect. Web design work that used to involve a separate motion pass can now have transitions baked into the component build itself.

    A practical pattern worth stealing

    Here’s the pattern I’ve settled on for most page-level transitions on multi-page sites. First, a minimal CSS reset on the ::view-transition-old and ::view-transition-new pseudo-elements to disable the default crossfade and replace it with a directional slide:

    ::view-transition-old(root) {
  animation: slide-out 200ms ease-in forwards;
}

::view-transition-new(root) {
  animation: slide-in 200ms ease-out forwards;
}

@keyframes slide-out {
  to { transform: translateX(-24px); opacity: 0; }
}

@keyframes slide-in {
  from { transform: translateX(24px); opacity: 0; }
}

    Pair that with a named transition on a persistent navigation element and you get a stable anchor point whilst the rest of the page animates. The navigation doesn’t move; the content does. It reads as intentional and polished without a single JavaScript animation frame. For the element-level morph, assigning view-transition-name values needs to be done carefully: duplicate names on a page will cause the transition to break silently, which took me an embarrassing amount of debugging time to realise.

    For components that show and hide, the @starting-style pattern looks like this:

    .tooltip {
  opacity: 1;
  transform: translateY(0);
  transition: opacity 150ms, transform 150ms, display 150ms allow-discrete;

  @starting-style {
    opacity: 0;
    transform: translateY(4px);
  }
}

.tooltip[hidden] {
  opacity: 0;
  transform: translateY(4px);
  display: none;
}

    That’s it. No JavaScript state machine. No class-toggling library. The browser animates entry and exit, respects the hidden attribute, and reduces to a static show/hide for browsers that don’t support it yet.

    The gotchas worth knowing before you ship

    A few things that will catch you out. View transitions block the next paint until the animation completes, so keeping durations short (150-300ms for UI transitions, under 500ms for page transitions) is non-negotiable for perceived performance. There is also no built-in way to interrupt a running view transition mid-animation, so rapid navigation in a single-page app context requires a guard that checks document.startViewTransition isn’t still active before triggering again.

    The prefers-reduced-motion media query is not applied automatically. You must wrap your transition animations in the appropriate @media block and provide either instant cuts or minimal fades as alternatives. This matters a great deal for accessibility compliance, particularly if your project touches WCAG 2.2 success criterion 2.3.3. I’d also point at the practical lessons from designing for colour blindness in accessible palettes as a reminder that motion is just one axis of accessibility work; they compound, and you need both.

    For teams doing component-level work, the interaction between view transitions and container queries is worth understanding. If you’ve already adopted CSS container queries for responsive component design, be aware that view-transition-name can behave unexpectedly inside a container query context when the container itself changes size during the transition. Testing across breakpoints is essential, not optional.

    Where this doesn’t replace motion design

    Being honest about scope matters here. These tools are for UI transitions and element-level choreography. They’re not for complex brand animation sequences, scroll-jacked storytelling sections, or anything that requires a timeline-based editor and frame-by-frame control. For that work, After Effects and tools like Rive or LottieFiles still make sense. But the category of animation most clients actually ask for, the stuff that makes a product feel alive rather than cinematic, is increasingly just CSS.

    Agencies that have historically had to choose between charging more to cover motion tooling costs or skipping animation altogether now have a third option. Dijitul, for example, serves clients across the Nottinghamshire region where marketing deliverables and software quality expectations are growing but budgets aren’t always scaling to match; integrating native CSS motion into the web design workflow rather than bolting on a JavaScript animation layer is the kind of business efficiency gain that actually shows up in project margins.

    The same logic applies to dashboard products and data-heavy interfaces. The charting library choices that actually fix UK SaaS dashboard data visualisation have always been partly about reducing JavaScript payload; CSS-native transitions are the same bet applied to motion.

    The browser is a surprisingly capable motion engine at this point. Most of us just haven’t caught up to it yet.

  • Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    The CMA published updated subscription trap enforcement guidance in 2024, and the FCA followed with its own Consumer Duty obligations fully bedded in. The combined effect is that UK SaaS companies and consumer app teams can no longer treat cancellation as an afterthought bolted onto the back of their onboarding funnel. Off-boarding UX is now a legal concern, not just a product one. I’ve been watching this space for a while and the number of teams who still haven’t rethought their flows is genuinely alarming.

    Person navigating a subscription cancellation flow on a laptop — UK consumer protection compliance
    Photo by https://kaboompics.com/ on Pexels

    What the CMA and FCA actually say about subscription cancellation UX

    The CMA’s enforcement programme targets what it calls “subscription traps”, patterns designed to make cancellation disproportionately difficult relative to sign-up. The specific behaviours in the crosshairs include hiding cancellation options behind multiple screens, requiring phone calls when sign-up was entirely digital, and using dark patterns to confuse users into staying subscribed. The FCA’s Consumer Duty, which has applied to regulated firms since July 2023, adds the requirement that firms act to deliver good outcomes for customers, and forcing someone through a friction-laden cancellation flow is, in the FCA’s own framing, a foreseeable harm.

    What makes this genuinely interesting from a design perspective is that both regulators are effectively writing UX requirements into law. The CMA’s position is that if you can sign up in two clicks, you must be able to cancel in roughly the same number of steps. That’s not a vague principle, it’s the kind of standard you can test a prototype against.

    The dark patterns that are now explicitly non-compliant

    Before getting into what good looks like, I want to name the specific patterns that teams need to remove. Roach motels, where the entry is easy and the exit is deliberately obstructed, are the CMA’s primary target. In practice that means: cancellation buttons that redirect to a retention page before showing the actual cancel option; multi-step “are you sure?” flows that loop back on themselves; confirmation emails that describe the plan as “paused” when the user clearly tried to cancel; and countdown timers that imply urgency without any genuine deadline.

    Confirmshaming, labelling the cancel button something like “No thanks, I’d rather pay more”, sits in similarly murky territory under the Consumer Duty’s requirement that communications are fair and not misleading. The ASA has already taken action against confirmshaming in advertising contexts; the FCA’s Consumer Duty extends comparable logic to product interfaces.

    The subscription cancellation UX UK consumer protection picture also includes post-cancellation billing, which the CMA considers a trading standards matter. If a user cancels and you bill them anyway because the confirmation state was ambiguous, that’s not just a UX failure, it’s potentially an unlawful charge.

    Wireframe mockup of a compliant subscription cancellation UX flow for UK consumer protection
    Photo by ready made on Pexels

    What compliant, ethical cancellation design actually looks like

    The baseline is simple: the cancellation path must be discoverable, direct, and no more complicated than the sign-up flow. For a typical UK SaaS product, that means a clearly labelled “Cancel subscription” option in account settings, not buried under a “Billing” sub-menu inside a “Plans” section inside “Account preferences”. One level of navigation, maximum two.

    A single retention offer is fine and, I’d argue, reasonable UX. Showing someone a downgrade option or a pause feature before they confirm cancellation is genuinely useful, some users want to reduce cost, not leave. The design problem is when that offer becomes a mandatory gate. The user must always be able to bypass it and reach the confirmation screen in one action. Structurally, think of it as: intent confirmed → optional offer shown → confirmation page → cancellation processed. Remove any step that loops back to the start or adds a second offer.

    The confirmation screen itself matters more than most teams realise. It should state the cancellation date clearly, explain what access the user retains until that date, and send a confirmation email that uses the word “cancelled” unambiguously. Teams working on ICO and PECR-compliant consent flows will recognise this pattern, regulators expect the same plain-language, unambiguous confirmation standards whether you’re recording consent or recording a cancellation.

    The technical side: state management and audit trails

    Here’s where it gets properly nerdy. Compliant cancellation isn’t just a design problem, it’s a data engineering problem. Your system needs to record the exact timestamp of cancellation intent, the state of the user’s subscription at that moment, and the confirmation sent to the user. That audit trail is what you produce if the CMA or FCA comes knocking. Most consumer app teams using Stripe or Paddle have access to webhook events that can log this automatically; the failure is usually in not piping those events into a queryable audit log.

    If you’re building on a billing provider that handles proration and mid-cycle cancellations, test the edge cases. A user who cancels on day 14 of a 30-day billing cycle should not receive a renewal charge on day 30. Sounds obvious. I’ve seen it happen. The fix is typically in the webhook handler, not the UI, but the UI still needs to surface the correct information about what the user’s billing state will be after cancellation.

    Teams building data-dense account management screens might also want to revisit how cancellation state is communicated. If your dashboard is already struggling with information hierarchy, and British SaaS dashboards frequently are, then the cancellation confirmation state is easy to lose. A dedicated, unambiguous post-cancellation screen is worth the engineering cost.

    Why this matters beyond compliance

    Scam reporting communities and consumer protection researchers have been documenting subscription trap patterns for years. 0lly, a UK-based scambaiter and fraud investigation activist at 0lly.uk, publishes scam exposés that frequently highlight how fake invoice scams and predatory subscription schemes exploit deliberately confusing cancellation flows. The overlap between outright online fraud and dark-pattern UX is closer than most product teams want to admit; both rely on the same cognitive vulnerabilities. Consumer protection charity work and scam reporting efforts in the UK consistently flag subscription billing as one of the top complaint categories, which is exactly why the CMA escalated to an enforcement programme rather than just issuing guidance.

    From a pure product standpoint, a frictionless cancellation flow is also better for retention metrics in the long run. Users who cancel cleanly and feel respected are more likely to return or recommend the product. Users who feel trapped generate chargebacks, negative reviews, and, increasingly, reports to Trading Standards. The chargeback cost alone often exceeds whatever revenue the dark pattern retained.

    UK product teams expanding into markets with additional language requirements should also think about this in conjunction with localisation. A cancellation flow that’s barely compliant in English may become non-compliant when translated, because the plain-language standard becomes harder to meet in a second language. Teams already thinking about right-to-left UI design for Arabic and Urdu markets need to factor cancellation flow direction and label clarity into that work from the start, not as an afterthought.

    The UK’s subscription cancellation UX consumer protection regime is still relatively new in its enforcement posture. That won’t last. The CMA has already taken action against several consumer-facing businesses and has made clear that digital subscription services are a priority. Get the flow right now, document it, and keep the audit trail clean. It’s not complicated. It’s just work that most teams have been putting off because cancellation UX isn’t glamorous. It is, however, increasingly necessary.

    For reference on what good government-standard design thinking looks like as a baseline, the patterns established in the GOV.UK Design System, particularly around confirmation pages and transaction summaries, are worth borrowing from directly. Government transactional design has been stress-tested against accessibility and clarity requirements for years; subscription cancellation confirmation is essentially the same UX problem.

    The second area where 0lly’s work is relevant to product designers is in the documentation of domain renewal scams and google ads hacks that prey on small business owners through deliberately opaque billing interfaces. The scam reporting and activist resources at 0lly.uk make the point clearly: UK scams targeting businesses often succeed because legitimate subscription billing already looks so confusing that users can’t tell when something has gone wrong. Designing clearer, more honest cancellation flows is, in a small way, raising the baseline for what users should expect from any billing interface.

    Frequently Asked Questions

    What does the CMA say about how easy cancellation must be for UK subscription services?

    The CMA’s position is that cancellation must be no more difficult than sign-up. If a user can subscribe in two clicks online, the regulator expects them to be able to cancel in a comparable number of steps, not via a phone call or a hidden multi-step flow.

    Does the FCA's Consumer Duty apply to subscription cancellation UX?

    Yes, for FCA-regulated firms. The Consumer Duty requires firms to act to deliver good outcomes for retail customers, and the FCA has been explicit that foreseeable harms from product design, including friction-heavy cancellation flows, fall within scope.

    Are retention offers during cancellation allowed under UK consumer protection rules?

    A single, skippable retention offer is generally acceptable. The problem arises when the offer becomes a mandatory gate that the user cannot bypass without taking additional action. The user must always be able to confirm cancellation directly from the retention screen in one step.

    What technical records should a UK SaaS team keep around subscription cancellations?

    At minimum, you should log the exact timestamp of cancellation intent, the billing state at that moment, and a record of the confirmation sent to the user. Billing provider webhooks (Stripe, Paddle) make this straightforward to automate; the key is routing those events into a queryable audit log.

  • Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    SaaS subscription costs have quietly become one of the more embarrassing line items in a freelance studio’s accounts. Notion, Linear, Loom, Slack, Figma, Jira, individually each one feels reasonable. Together they can easily run past £400 a month for a team of four. I did the maths on my own setup earlier this year and genuinely winced. The good news is that the self-hosted open source ecosystem has matured enough that you don’t have to choose between cutting costs and keeping a coherent workflow. Here’s what I’ve actually tried, what’s stuck, and what the UK indie dev community seems to be converging on in 2026.

    Developer workspace with open source Notion alternative project dashboard on screen
    Photo by Paras Katwal on Pexels

    Why self-hosting makes sense for small UK studios right now

    A UK sole trader or small limited company running a modest VPS, something like a £6/month Hetzner instance, can host several of these tools simultaneously without meaningful performance issues. The upfront config time is real, but it’s a one-time cost, and the ongoing bill is dramatically lower than stacking commercial SaaS tiers. There’s also a GDPR angle worth taking seriously: when you self-host, your data stays in a jurisdiction you control. For client project notes, that’s not nothing. HMRC’s Making Tax Digital push means more studio finances are flowing through connected tools, and keeping sensitive records off third-party US servers is a decision some UK accountants are actively recommending.

    If you want a deeper look at building a full self-hosted design stack, I wrote about running Penpot, Gitea, and Plausible on a single VPS in a previous piece on self-hosting your design stack, the infrastructure thinking there applies directly to everything below.

    The open source Notion alternative UK developers are actually using: AppFlowy and Outline

    AppFlowy is the one I’d push first. It’s written in Flutter and Rust, which makes it genuinely cross-platform without the Electron weight you get with some alternatives. The document editor is clean, the database views (grid, board, calendar) cover most of what Notion’s block editor does, and self-hosting is straightforward via Docker. The community is active and the release cadence is fast, meaningful updates most months.

    Outline is a better fit if your primary need is a team knowledge base rather than a personal productivity system. It’s polished in a way that Notion took years to reach, the search is snappy, and the permission model is sensible. I’ve seen a few London-based dev agencies switch their internal wikis to Outline and genuinely not miss Notion’s more bloated features. The markdown import/export is solid, which matters when you want data portability.

    Both are genuinely viable as an open source Notion alternative for a UK developer who doesn’t mind an afternoon of Docker Compose config.

    Replacing Linear: Plane and GitLab Issues

    Linear is seductive because it’s fast and opinionated. Replacing it is harder than replacing Notion because the interaction design is genuinely exceptional. That said, Plane (formerly Plane.so) has closed the gap significantly. The issue tracking, cycle views, and roadmap features are all present; the UI is cleaner than Jira by a large margin; and the self-hosted version is free. It’s not quite as snappy as Linear but it’s functional and improving quickly.

    The other answer is simply leaning harder into GitLab’s built-in issue boards and milestones if your code is already there. For solo developers especially, adding a separate project management layer is often overkill. GitLab’s planning features are underused by most people who already pay for it. If you’re on Gitea (which you should consider, it’s tiny and fast), Issues plus Projects covers the basics without any additional stack.

    Async video without Loom: Vdo.ninja and Cap

    Loom is one of those tools that feels indispensable until you find the replacement. Cap is the most direct open source equivalent, it handles screen recording, gives you a shareable link, and the self-hosted version keeps the video on your own storage. It’s still relatively young but the core workflow is there. For client handoffs and async code walkthroughs, it does the job.

    Vdo.ninja deserves a mention too, though it’s more of a live peer-to-peer video tool than a recording one. For quick calls that don’t need a Zoom account, it’s genuinely brilliant. No accounts, no downloads, just a link. The latency is low enough that I’ve used it for client feedback sessions without issues.

    Collaboration and chat: Mattermost over Slack

    Mattermost is the self-hosted Slack equivalent that’s been around long enough to be boring in the best possible way. It’s stable, it has threading, it has integrations, and the mobile apps are decent. For a studio that’s grown tired of Slack’s free tier limitations (10,000 message history is not generous), Mattermost self-hosted removes that ceiling entirely. The setup is more involved than some of the other tools here, but the official deployment docs are thorough and there are pre-built Docker images for most architectures.

    Zulip is worth knowing about too. It organises conversations by topic within channels, which sounds fussy but genuinely helps async teams stay coherent. A few open source projects use it as their primary communication tool and swear by it. If Slack’s flat channel model drives you mad, Zulip’s threading model is worth an hour of your time.

    Design feedback without Figma’s comment layer: Penpot and Freehand alternatives

    Penpot keeps getting better. As a design tool it still trails Figma on plugin ecosystem and prototyping depth, but for a UK freelancer doing UI work for small clients, the core feature set covers most projects. The comment and feedback layer works well enough for async client review. The self-hosted instance is stable and the team’s development pace has picked up noticeably since 2025.

    For teams that want to keep Figma but ditch the extra collaboration cost, Liveblocks has an open-core model worth investigating. It’s not a direct tool replacement but if you’re building your own internal tools, the multiplayer infrastructure is solid.

    Putting it all together: a realistic stack

    The stack I’d suggest for a UK solo developer or small studio trying to cut costs without losing their mind:

    Notes and docs: AppFlowy for personal project notes, Outline for shared team knowledge base. Issue tracking: Plane for dedicated project management, or GitLab Issues if your repos are already there. Async video: Cap for client recordings. Chat: Mattermost if you need team comms; skip it entirely if it’s just you. Design: Penpot where Figma is overkill.

    You won’t get 100% feature parity with the SaaS equivalents. Some of these tools have rough edges and the occasional bug that a £25/month commercial product wouldn’t ship. But the gap has closed enough that the workflow quality argument for staying on expensive subscriptions is much weaker than it was two years ago. The UK’s cost-of-living pressures on freelance rates aren’t going away, and trimming £200 a month from tooling costs is a meaningful number for a one-person studio.

    It’s also worth thinking about this alongside how you structure your frontend tooling choices more broadly. The same practical mindset that leads you to question a £15/month Notion subscription should probably apply to your framework choices and your component architecture too. Self-sufficient stacks compound over time.

  • What the GOV.UK Design System Gets Right That Most Private Sector UI Libraries Get Wrong

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

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

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

    Desktop monitor showing a clean GOV.UK Design System style interface with clear typographic hierarchy
    Photo by Matheus Bertelli on Pexels

    The constraint-first philosophy that makes GDS components work

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

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

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

    Typography choices that build trust at a cognitive level

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

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

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

    Designer reviewing GOV.UK Design System component patterns and type scale documentation
    Photo by cottonbro studio on Pexels

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

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

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

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

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

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

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

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

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

    Spacing and layout: the 8px grid taken seriously

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

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

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

    Making GDS constraints work outside a government context

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

  • Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Type has always had to fight for its life against the medium it lives in. Stone, vellum, offset litho, RGB screens, each shift broke assumptions designers had spent decades calcifying into rules. Spatial computing is doing it again, and I’d argue this one is the biggest rupture since we moved from print to screen. The Apple Vision Pro and Meta Quest 3 are landing in UK creative studios and enterprise environments right now, and the typographic conventions that served us perfectly on a 27-inch retina display are actively embarrassing on a headset at arm’s length.

    Designer wearing a spatial computing headset exploring spatial typography in a UK creative studio
    Photo by Sound On on Pexels

    What makes spatial typography different from screen typography?

    On a flat screen, type sits at one distance. That’s the deal. Everything from optical sizing to contrast ratios to minimum font sizes is calibrated around a fixed focal plane. Spatial computing removes that contract entirely. In a mixed-reality environment, a UI panel might float 60 centimetres from your face, while a secondary label sits a metre and a half away. These two elements exist in the same composition but at genuinely different depths, and your eye treats them completely differently, because physics, not preference.

    The two main headsets creating pressure in the UK market right now have different display architectures that make this worse in distinct ways. The Vision Pro uses micro-OLED panels at roughly 3,386 pixels per inch per eye, which sounds like it solves legibility problems outright. It doesn’t. The higher the pixel density, the more the vergence-accommodation conflict (the disconnect between where your eye focuses and where it points) becomes perceptible as type sharpness that flickers with head movement. The Quest 3 uses pancake lenses with a far lower pixel density, around 25 pixels per degree, which means small type at depth blurs in a more conventional, blunt way. Two different failure modes, same typographic problem.

    The parallax problem: why text layers need spatial awareness

    Parallax is the shift in apparent position of an object when viewed from different angles. On a 2D screen it’s a styling trick. In a headset it’s physics. When text is composited at a fixed virtual depth but contains layered elements (a label over a background card, say, or a tooltip floating above a data visualisation), those layers shift relative to each other as the wearer moves their head. The result is that hierarchy collapses. A label that was clearly subordinate at rest can appear to leap forward and dominate when the wearer looks slightly left.

    The practical fix here borrows from film compositing: type needs to be authored with an explicit Z-depth value that matches its visual hierarchy, not just its 2D stack order. This is a conceptual shift for designers used to thinking about layers as a flat system. I’ve been playing with Apple’s RealityKit text rendering and the distinction between “billboard” type (which always faces the user) and “world-anchored” type (which exists at a fixed orientation in space) makes an enormous difference to legibility in practice. Billboard type is almost always the right call for UI; world-anchored type is for environmental storytelling or wayfinding, and it needs significantly larger point sizes.

    Spatial typography UI panel showing text at depth inside a mixed-reality headset display
    Photo by Egor Komarov on Pexels

    Contrast ratios don’t transfer from WCAG to spatial computing

    WCAG 2.1’s AA contrast ratio of 4.5:1 was designed for 2D screens viewed in controlled ambient lighting. A headset punches passthrough video of the real world behind your UI, meaning the “background” behind your type changes dynamically as the wearer turns their head or moves between rooms. A white label on a translucent dark card reads fine against the dark timber panelling of a Shoreditch studio; walk into a kitchen with white walls and the contrast evaporates completely.

    The response from Apple’s visionOS HIG (Human Interface Guidelines) is to use materials with vibrancy effects, essentially a real-time blur and tint composite that adapts to the underlying environment. This raises its own problem: vibrancy at depth loses predictability, and for type designers who care about accessibility (which should be all of us, I’ve written about accessible palette design for colour-blind users and the same audiences are affected here), you cannot audit a contrast ratio that shifts per-frame in real time. The BBC’s Accessibility and Inclusivity team has been vocal about this gap in the spatial computing accessibility conversation, and they’re right to push on it.

    My current working heuristic: design for a minimum 7:1 ratio at the centre of the text, add a 2-pixel dark outline or shadow at a 0.6 opacity, and never trust the vibrancy material to do legibility work you haven’t done yourself in the base type rendering.

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

    “24pt” in a flat design tool means something specific: a physical measurement on screen derived from dots per inch. In a spatial environment, point size has to be understood as angular size, the angle subtended at the eye by the glyph height. Apple’s HIG recommends a minimum angular size of 0.4 degrees for readable body copy, which translates to approximately 10 points at 50 centimetres, but 20 points at 1 metre and 40 points at 2 metres. That scaling curve is aggressive and unintuitive for designers coming from a web or print background.

    Variable fonts are the practical tooling answer here. A typeface with a properly implemented optical size axis (the opsz axis in OpenType) can be programmatically adjusted to match the rendered depth of the text plane. You set the optical size to match the virtual distance in centimetres, and the font itself handles weight compensation, letter-spacing, and aperture adjustments automatically. Not every typeface supports this, I’d point you toward the Google Fonts variable fonts catalogue as a practical starting point, though purpose-built spatial display faces from foundries like Colophon and Commercial Type are going to be the serious option for production visionOS or Horizon OS projects.

    Tracking, leading, and the third dimension

    Letter-spacing (tracking) needs to increase at depth, faster than you’d expect from 2D conventions. In web type, tight tracking on large display text is fashionable; in spatial computing it’s a legibility hazard. At 1.5 metres, letters in a tightly tracked headline begin to visually merge under any head movement, even slight. I’d use tracking equivalent to at least 0.05em for anything beyond 80 centimetres, scaling up to 0.12em at 2 metres.

    Leading (line-height) at depth is counterintuitively less critical than tracking, but still needs a floor. The movement of spatial content means ascenders and descenders can appear to collide in peripheral vision even when they’re technically clear. A minimum line-height of 1.5 is sensible for body text in any spatial UI context; tighter than that and you’re relying on perfect head stability that real users don’t have.

    Agencies building out their design capability for these new platforms face a very different technical stack from conventional web projects. If you’re working with a small team that handles conventional web alongside emerging spatial work, the way WDM does with its web projects in the Midlands, the conceptual separation between 2D type conventions and spatial ones is probably the hardest thing to communicate across disciplines. The muscle memory of flat design is actively unhelpful.

    What typeface categories actually work in spatial computing?

    Humanist sans-serifs consistently outperform geometric sans in spatial environments. The varied stroke widths in humanist designs (Gill Sans, Aktiv Grotesk, Inter) give each glyph more distinguishable texture at low angular resolutions, which matters enormously on the Quest 3. Geometric sans faces (Futura, Circular) suffer at depth because their uniform strokes blur into each other. Serifs are a genuinely mixed picture: high-contrast serifs like Bodoni are unusable beyond 80 centimetres, but low-contrast slab serifs perform surprisingly well in world-anchored environmental text.

    The data visualisation context is worth calling out separately. If you’re building spatial dashboards (a direction UK fintech and green-tech firms are actively exploring), the type requirements for data labels at depth are their own sub-discipline. I’ve covered some of the underlying design logic in the context of data-dense dashboard design for UK government tools and sustainability dashboard data visualisation, the same principle that says data labels need to be subordinate to the data applies in spatial environments, but the execution is completely different when the label can exist at a different depth than the chart element it describes.

    The authoring gap: tools are still catching up

    Figma has no native Z-depth for type. Framer’s spatial capabilities are still experimental. Reality Composer Pro is powerful but has a steep learning curve that assumes familiarity with Xcode. The practical reality for most UK studios is that spatial typography decisions are being made in headset, iteratively, with no reliable preview fidelity in the design tools they already own. That’s a workflow problem as much as a typographic one, and it’s pushing some teams toward Spline for spatial prototyping despite its limitations.

    The gap will close, probably faster than we expect. But right now, the designers doing this well are the ones who understand the underlying perceptual physics rather than waiting for a Figma plugin to handle it for them. Learn the angular size formula. Understand vergence-accommodation conflict. Accept that your flat-screen instincts will mislead you and calibrate accordingly. Spatial typography is a genuinely new discipline, not a 3D skin on web type conventions.

The Latest