Designing experiences for millions of people
How product teams think about scale, usability and personalization when the rare case stops being rare.
Product Desk · Product & design
In this story (5 sections)
General edition. , or use the switcher above.
Designing for millions isn’t designing for one person a million times. It’s designing so that the person you never imagined can still succeed.
This explainer covers four ideas that shape large-audience products: edge cases, defaults, rollout and guardrails.
The short version
- At large scale, edge cases (slow networks, old devices, assistive technology) are common, so the baseline experience has to work for them.
- Most people never touch settings; defaults are the product for most users.
- Change at scale means staged rollouts with a way back, and guardrail metrics that must not get worse.
- Personalization at scale is mostly well-chosen defaults for groups, with an easy way to change.
At scale, the edge cases are the product
A product used by a few hundred people can be shaped by the preferences of a few hundred people. A product used by millions is, by arithmetic, used by people on slow connections, old phones, assistive technology, unfamiliar languages and unusual days. The rare case stops being rare.
Designing for that audience is less about adding options and more about making the default correct for as many people as possible, and degrading gracefully for the rest.
Defaults beat options
Most people never open settings. Whatever the default is, is the product for most of them. Teams that serve large audiences therefore spend disproportionate effort on defaults: the first screen, the empty state, the error message, the behaviour with no preference stated.
This is also where personalization is best understood. At scale it works less like a different product per person and more like a handful of well-chosen defaults for groups of people, with an easy way to change.
What changes as the audience grows
| Concern | A small audience | A very large audience |
|---|---|---|
| Accessibility | Handled case by case | A baseline requirement, tested continuously |
| Performance | Noticed by the team | Differs sharply by device and network; measured on the slow end |
| Change | Announce and ask | Staged rollout with a way back |
| Feedback | Conversations | Patterns across many weak signals, read with care |
Measure what you must not break
A guardrail metric is a number you agree not to make worse while pursuing another goal, such as keeping error rates and load times steady while testing a new layout. Guardrails make bold experiments safer, because a win on the target metric doesn’t count if a guardrail was breached.
What this explainer leaves out
Scale also brings legal, localisation and infrastructure questions that aren’t covered here, and the table above is a simplification. Treat it as an orientation, not a playbook.
Key takeaways
- 01Invest in defaults, empty states and error messages first.
- 02Test on the slow end of devices and networks.
- 03Pair every experiment with guardrail metrics.
Terms used (1)
- guardrail metric
- A measure you agree not to make worse while you pursue a different goal, such as error rate or page load time during a layout test.
Your perspective
A better read starts with knowing what matters to you.
Three quick questions. A publication that adapts to your perspective.
Keep reading
All stories →What does it really take to bring AI into production?
Make four decisions about a hypothetical AI project (scope, data, oversight, rollout) and see what you’d be trading away. A simulation, clearly labelled.
The personalization paradox
When does tailoring an experience to someone make it better, and when does it become intrusive? An interactive look at four rungs of personalization.
What shipping products teaches you
Five practical observations about dates, first versions, measurement, release size and memory, written as field notes rather than rules.