There's a difference between designing for a hundred users and designing for ten thousand. Not just in performance or infrastructure, but in the design itself. Decisions that are invisible at small scale become load-bearing at large scale. We've learned this the hard way, particularly through our work on health platforms that serve hundreds of thousands of people annually.
What You Need to Know
- Design decisions compound at scale. A confusing label that generates one support ticket per hundred users generates a hundred tickets at ten thousand users
- Accessibility isn't optional at scale. With ten thousand users, you're statistically guaranteed to have users with diverse access needs
- Performance perception is a design problem, not just an engineering one. Skeleton screens, progressive loading, and feedback patterns matter more as user patience decreases
- Design systems pay for themselves faster at scale because inconsistency multiplies
What Changes at Scale
When a system has fifty users, you can fix problems by talking to people. Someone is confused by a form? Walk over to their desk. A workflow doesn't make sense? Sit with the team for an afternoon. This feedback loop is fast and personal.
At ten thousand users, that model doesn't work. You can't talk to everyone. The feedback you get is biased toward the most vocal users, who are rarely representative. Problems that affect 5% of users, 500 people, might never reach you through normal channels.
Design at scale means designing for people you'll never meet, using data patterns rather than personal relationships to understand what's working and what isn't.
The Decisions That Compound
Labels and language
We worked on a health platform where a single form field label caused confusion for about 3% of users. At the time we launched, that was manageable. As the user base grew past 100,000 annual users, that 3% became thousands of people making mistakes, generating support requests, and losing trust in the system.
3,000+
annual support contacts traced to a single ambiguous form label on a platform with 100,000+ users
Source: Internal project data, anonymised
We changed the label. Support requests for that field dropped by 80% within a month. One word. The lesson: every piece of language in your interface is a decision that gets multiplied by your user count.
Navigation depth
Every click is a filter. Some percentage of users drop off at each step. At small scale, the drop-off is noise. At large scale, it's measurable. A workflow that requires four clicks to complete will lose more users than one that requires two, and the difference scales linearly with your user base.
This doesn't mean everything should be one click away. It means every step in a workflow needs to justify its existence. If a step exists for organisational reasons rather than user reasons, it's costing you.
Error states
At fifty users, errors are rare events. At ten thousand, someone is hitting an error state right now. The quality of your error messages, recovery paths, and fallback behaviours becomes a core part of the user experience rather than an edge case.
The best test of a design isn't the happy path. It's what happens when something goes wrong at two in the morning and the person using the system is tired, stressed, and needs it to work.
Rainui Teihotua
Chief Creative Officer
Accessibility Is Not Optional
This should go without saying, but it needs saying because it's still treated as optional far too often. With ten thousand users, you will have users who navigate by keyboard. Users who rely on screen readers. Users with low vision, colour blindness, motor impairments, cognitive differences.
The WCAG 2.1 AA standard isn't aspirational at scale. It's baseline.
We've retrofitted accessibility into systems that launched without it. The cost is always higher than building it in from the start. Colour contrast, focus management, semantic HTML, ARIA labels, these aren't polish. They're infrastructure.
24%
of New Zealanders live with a disability that can affect how they use digital services
Source: Stats NZ Disability Survey, 2013
Performance as Design
Users don't distinguish between "the system is slow" and "the system is badly designed." A page that takes three seconds to load feels broken, regardless of what's happening on the server.
At scale, performance perception is a design concern. Skeleton screens that show the shape of content before it loads. Progressive disclosure that shows the most important information first. Optimistic UI patterns that confirm actions before the server responds.
These patterns don't make the system faster. They make it feel faster. And at scale, perception is what determines whether people trust the system enough to use it.
Design Systems Pay Off Faster
A design system is overhead when you're small. At scale, it's essential. Without one, ten designers making independent decisions will create ten slightly different versions of the same component. Each one works. None of them are consistent.
Inconsistency at scale erodes trust. If the submit button is blue on one page and green on another, users notice. If form validation works differently in different sections, users learn not to trust the interface.
The investment in a design system, component library, documented patterns, consistent tokens, pays back faster the larger the user base. What feels like unnecessary process at fifty users becomes essential infrastructure at ten thousand.
What We'd Do Differently
If we were starting a large-scale project today, we'd invest more in three things from day one: structured user feedback collection (not just support tickets), automated accessibility testing in the CI pipeline, and real-device performance testing.
The common thread is measurement. At scale, intuition isn't reliable enough. You need data to know what's actually happening for the people using your system.