There is a specific kind of design review horror that every UK product designer eventually experiences. The prototype looks immaculate. The components are tight, the spacing is perfect, and the typography sings. Then someone asks: “What happens when the user’s surname is Featherstonehaugh?” Or: “Our biggest client has a 47-character company name.” The room goes quiet. The designer opens Figma and starts dragging a text box wider. The dream is over.
That scenario is almost entirely caused by one bad habit: designing with placeholder content. Lorem ipsum is comfortable. It fills space without asking difficult questions. But it lies to everyone in the room, and I’d argue it’s one of the most underrated sources of production bugs and last-minute design rework in UK product teams today. Replacing it with realistic test data UI design UK practice isn’t a nice-to-have; it’s a discipline that changes the quality of every design review you run.
Why lorem ipsum is a design smell
Placeholder text masks problems that only emerge with real content. A navigation label that reads “Lorem” fits neatly. “Accessibility Settings” might not. A dashboard card with “Lorem ipsum dolor” as the description looks fine at 16px. “You have 3 outstanding invoices totalling £4,280.00 (VAT inclusive)” at the same size might wrap awkwardly, break a flex container, or push a CTA button off-screen entirely.
These aren’t edge cases. They’re the norm for UK products that serve real British users with British addresses, postcodes, phone numbers, and names drawn from an extraordinarily varied pool. The Office for National Statistics publishes population data that illustrates just how linguistically diverse the UK is. If your app serves the public, your test data needs to reflect that diversity or you’ll ship interfaces that break on perfectly normal inputs.
The fix isn’t complicated, but it does require a shift in how teams think about the design-to-development handoff. And Faker.js with the en_GB locale is the cleanest place to start.
What Faker.js en_GB actually gives you
Faker.js is a widely used JavaScript library for generating synthetic but structurally accurate fake data. The en_GB locale setting is the part most UK teams skip, and it matters enormously. Without it, you get American-formatted phone numbers, US-style zip codes, and first names weighted heavily towards an American demographic distribution. With en_GB, you get UK mobile numbers in the 07xxx xxxxxx format, British postcodes like SW1A 1AA or M1 1AE, and names that actually reflect the British population: Priya, Mohammed, Cillian, Aoife alongside James, Sarah, and David.
Here’s the kind of seed script I’d use to generate a realistic dataset for a UK SaaS dashboard review:
import { faker } from '@faker-js/faker/locale/en_GB';
const generateUser = () => ({
id: faker.string.uuid(),
name: `${faker.person.firstName()} ${faker.person.lastName()}`,
email: faker.internet.email(),
phone: faker.phone.number(),
postcode: faker.location.zipCode(),
company: faker.company.name(),
plan: faker.helpers.arrayElement(['Starter', 'Growth', 'Enterprise']),
invoiceTotal: faker.finance.amount({ min: 50, max: 12000, dec: 2, symbol: '£' }),
joinedAt: faker.date.past({ years: 3 }).toLocaleDateString('en-GB'),
});
const users = Array.from({ length: 50 }, generateUser);
console.log(JSON.stringify(users, null, 2));Run that once and you have 50 structurally honest user records. Drop them into your design tool via a JSON plugin, or pipe them into a Storybook story, and suddenly your design review is testing something real.
How realistic data changes design reviews
I’ve sat in enough design crits to know that lorem ipsum reviews have a particular rhythm: everyone nods at the aesthetics and nobody catches the layout bugs. Swap in real data and the conversation changes completely. People start asking the right questions immediately.
Long company names break table rows. Very short names (“Jo”, “Ed”) create awkward avatar initials. Financial figures with varying digit counts expose alignment issues in data tables. British postcodes have variable lengths (“E1 6RF” versus “SW1A 2AA”) that will absolutely break a fixed-width input if nobody tested it. Dates formatted as en-GB (“21 April 2026”) behave differently from ISO strings in ways that affect column widths.
This connects directly to a broader problem I’ve written about with British SaaS dashboards failing at data visualisation: the visual layer only tells you something useful if the data underneath it is honest. A chart seeded with placeholder values of similar magnitude will look balanced. Real financial data with outliers will expose whether your Y-axis scaling is any good.
Integrating seed scripts into the design workflow
The practical question is where this data actually lives in a team’s process. There are a few patterns worth knowing.
Figma + JSON plugins: Tools like Figma’s own “Content Reel” or the “JSON to Figma” community plugin let you paste a JSON array and populate component instances automatically. Generate your Faker data, export it, load it in. Takes about three minutes once the script exists.
Storybook stories with seeded data: For component-level work, writing Storybook stories that import from a shared seed script is even more powerful. Every developer on the team sees the same realistic data when they open the component browser. If you’re doing any work that touches solo micro-SaaS UI development, this is a genuinely weekend-implementable improvement to your workflow.
Shared seed fixtures in the repo: The most mature version of this is a /fixtures directory in the codebase with a set of deterministic seed scripts (using a fixed random seed so the data is reproducible). Designers reference the same fixture files that QA engineers use. Suddenly “the data in the mockup” and “the data in the test environment” are the same thing, which eliminates an entire category of “it looked fine in Figma” conversations.
The locale details that actually matter for UK products
Beyond names and postcodes, there are some locale-specific data patterns that UK products get wrong constantly:
Phone numbers: UK mobiles start with 07. UK landlines vary by region: 020 for London, 0161 for Manchester, 0131 for Edinburgh. If your input field only fits 11 digits with no space formatting, you need to know that before you ship.
VAT numbers: UK VAT registration numbers follow the format GB followed by 9 digits. Faker’s en_GB locale doesn’t generate these natively, but a simple custom helper wrapping faker.string.numeric(9) with the GB prefix gets you there.
Bank sort codes and account numbers: The UK uses 6-digit sort codes (formatted as XX-XX-XX) and 8-digit account numbers. Again, Faker doesn’t generate these by default, but they’re trivial to construct and essential if you’re building any fintech-adjacent interface.
Names with apostrophes and hyphens: O’Brien, Al-Hassan, Lloyd-Jones. If your database schema or your UI component hasn’t been tested with these, it probably breaks somewhere. Seed your data with a handful of deliberately awkward names and find out before a real user does.
All of this feeds into why teams doing genuinely differentiated UK B2B SaaS product design tend to have stronger QA cultures too. The design and development disciplines start to blur productively when the artefacts they work with share the same data reality.
A note on edge cases as first-class design concerns
One thing I’d push back on is the framing of long names or unusual characters as “edge cases”. In a UK product with any meaningful user base, they’re just… cases. The ONS data on name diversity, the variation in UK address formats across England, Scotland, Wales, and Northern Ireland (where some postcodes behave differently), and the variety of business entity types (Ltd, LLP, PLC, sole trader) all mean that the surface area of “normal” is wider than most teams design for.
Seed scripts with realistic test data are the mechanism that makes this visible early. A design review where someone spots that the table breaks on a Welsh business name is infinitely cheaper than a support ticket from a real user in Llanfairpwllgwyngyll.
The tooling is lightweight, the setup time is minimal, and the improvement to design review quality is immediate. Lorem ipsum had a good run. It’s time to retire it.