Nobody designs a product that cannot scale. They design a product that works beautifully at the size it is on the day it launches, and the structure quietly decides everything that happens afterwards. Three years later the navigation has a “More” menu with eleven things in it, the settings page has grown eight accordions, and every new feature request begins with a twenty-minute argument about where it goes.
That is not a design system problem and it rarely gets fixed by one. Components can be immaculate while the structure underneath them is collapsing. Scalable UX is about something narrower and harder: choosing structures where the cost of adding the next thing stays roughly flat.
The short version
- Scalability is a cost curve. Ask what it costs to add the twentieth thing, not the second.
- Design the rule, not the screen. A pattern without stated criteria gets applied by guesswork.
- Structure around what people are trying to do, not around how your company is organised.
- Design against the heaviest realistic account from day one, not the demo account with three records.
- Name the slot the next feature goes into before anyone asks for it.
- A “More” menu is not an overflow solution. It is a record of a decision nobody made.
Scalability is a cost curve, not a property
Products do not stop being usable at a particular size. They get gradually more expensive to extend, and one day somebody notices that shipping a small feature takes six weeks of debate. The useful question at design time is therefore not “does this scale” — everything scales to some degree — but what does each additional item cost?
Three curves show up repeatedly.
Flat cost. Adding the twentieth item costs the same as adding the second. Sectioned navigation with search. A settings page organised by object rather than by feature. A list view with filters and saved views. These structures absorb growth because the structure does not change shape as things are added.
Linear cost. Each addition costs a bit more than the last, because the user has more to scan and the team has more to reconcile. A flat sidebar. A role system where each new permission is a separate checkbox. Survivable for a long time, and usually what you actually have.
Compounding cost. Each addition makes every future addition harder, because it interacts with everything already there. A tab bar at its width limit. Settings organised by the team that built each feature. A notification system with no grouping model. These are the ones that produce the six-week small feature, and they always look fine at launch.
The practical diagnostic takes two minutes in a planning meeting. Pick the next three features on your roadmap and ask, for each: where does it go, and who decides? If the answer requires a discussion, your structure is already charging you compound interest.
What breaks, roughly in this order
Growth does not strain everything at once. In most products the failures arrive in a predictable sequence, which is useful because it tells you what to design properly first.
Navigation goes first, usually somewhere between eight and twelve top-level destinations. The symptom is an overflow menu, a second navigation bar, or a “Home” that has quietly become a directory.
Findability goes next. Once there is more content than a person can hold in their head, browsing stops working and search becomes the primary interaction. Most products treat search as a fallback until well past this point.
Then data density. Interfaces designed with four rows of sample data behave differently at four hundred. Sorting, filtering, bulk actions and pagination all turn out to have been afterthoughts.
Then permissions. The moment a second kind of user appears, every screen acquires a hidden conditional. Role systems built as a list of checkboxes become unreadable at about the fifteenth permission.
Then settings. Every feature adds its own preferences, and because no one owns the settings architecture, each lands wherever its team put it.
Then notifications. What was helpful at two a day is noise at thirty, and by then people have turned them off entirely, which is expensive to undo.
Everything scales to some degree. The question is what the twentieth thing costs, not whether the second one fits.
Five principles that keep the curve flat
1. Design the rule, not the screen
A pattern is not scalable because it is documented. It is scalable because somebody can apply it to a new case without asking you. That requires stated criteria: when to use this over that, what belongs in it, what disqualifies it. “Use a modal for destructive confirmations only” is a rule. “Here is our modal” is a component.
The test of a rule is whether two designers who have never spoken produce the same answer. If they do not, you have a component library and a convention gap.
Check: take your three most-used patterns and write the sentence that says when not to use each.2. Structure by intent, not by org chart
Navigation that mirrors your internal teams is the single most common source of compounding cost, because your teams reorganise and your users do not. The billing team’s work and the account team’s work may be one task to the person doing it.
Structure around what someone is trying to accomplish, and the structure survives reorganisations, acquisitions and the arrival of features nobody has thought of yet. It also tends to produce fewer top-level destinations, which is where this whole problem starts.
Check: if a stranger could draw your org chart from your navigation, redesign the navigation.3. Let the container absorb the growth
Choose structures that do not change shape as they fill. Sections with search beat a flat list, because adding the thirtieth item changes nothing about the model. Filters and saved views beat adding another tab. Progressive disclosure beats a longer page. A list that supports sorting, filtering, selection and bulk action on day one will still work when it holds ten thousand rows.
The opposite instinct — add one more tab, add one more top-level item — is cheap each time and is exactly how compounding cost accumulates.
Check: for each container in your product, ask what happens at ten times the current contents. If the answer is “add a More menu”, the container is wrong.4. Design against the heaviest realistic account
Most interfaces are designed against a tidy demo: three projects, two team members, short names, no edge cases. Then the biggest customer arrives with four hundred projects, sixty users, a name in a script you did not test, and three years of history.
Build the design file with that account in it from the start. Long names, deep nesting, empty states, states full to bursting, a user with permission to see almost nothing. It is slower in week two and it removes an entire category of rework in year two.
Check: does your design file contain a screen with realistic worst-case data in it? Not an edge case page — the main screen, populated honestly.5. Name the slot before the feature exists
For every area of the product, decide in advance where the next thing goes. Not what it will be — where it will live, and what would qualify it for that place. This is the habit that most reliably prevents the “More” menu, because the extension path is a decision made calmly rather than under delivery pressure.
When the answer for a new feature is genuinely “nowhere”, that is useful information. It usually means the feature is either more important than it looked, or does not belong in this product at all.
Check: take the next three roadmap items and place each one on the current navigation without discussion. Count how many you can.Stress-test a pattern before you commit to it
Pick a pattern you are using now and the growth you realistically expect. The tool gives what breaks first, the alternative that holds, and what it costs to change later rather than now.
Pattern stress test
Two inputs. The cost of switching later is the number most teams never calculate.
Which pattern?
How much bigger will it get?
Two inputs, one diagnosis
Pick the pattern you are using and the growth you expect.
What holds instead
—
Design it this way now
—
0 of 2 chosen
How to find the problem before it finds you
Three exercises, none of which takes longer than an afternoon.
The ten-times walkthrough. Take your five most-used screens and populate them with ten times the data: ten times the rows, the projects, the team members, the history. Walk the main task. Nearly every density and findability failure in your future is visible in that one session, years before a customer finds it.
The next-three-features placement. Already mentioned, and it is the cheapest of the three. Three roadmap items, placed on the current structure, no discussion allowed. The ones that cannot be placed are telling you where your structure ends.
The new-joiner reconstruction. Ask someone who joined in the last month to explain why a given feature lives where it does. If they cannot infer the logic, neither can your users — and more importantly, neither can the next designer deciding where to put something.
One caution worth stating plainly. Future-proofing has a failure mode of its own, and it is building elaborate flexible structures for growth that never arrives. A three-level navigation taxonomy on a product with nine screens is not foresight; it is cost paid up front for an option you may never exercise. The principles here are about choosing structures with flat extension costs, not about building capacity in advance. When in doubt, choose the simpler structure and the clearer rule about where the next thing goes.
Where this goes wrong
| Failure | Looks like | Prevention |
|---|---|---|
| The overflow menu | A “More” item holding the eleven things nobody could place | Decide the extension slot before the feature is built. |
| Navigation as org chart | Two destinations that are one task for the user | Structure around intent; it survives reorganisation. |
| Demo-data design | Screens that work at three rows and fail at three hundred | Design against the heaviest realistic account from week one. |
| Search as a fallback | Search added late, scoped to one object type, rarely used | Treat search as primary navigation past a known content threshold. |
| Permissions as checkboxes | A settings screen with forty switches nobody understands | Model roles around jobs, with permissions grouped beneath them. |
| Settings by team | Preferences grouped by who built the feature | Give settings an owner and organise by the object being configured. |
| Components without rules | Three designers, three different answers for the same case | Write the “when not to use this” sentence for every pattern. |
| Over-building for scale | A deep taxonomy on a nine-screen product | Choose flat extension cost, not pre-built capacity. |
If you change three things this quarter
Run the next-three-features placement test at your next planning meeting; it costs ten minutes and tells you immediately whether your structure is still absorbing growth. Populate your three most important screens with ten times the data and walk the main task. And pick your most-used pattern and write the sentence saying when not to use it.
None of those requires a redesign, a migration or anyone’s budget approval. They are diagnostic, and they tend to surface the one structural decision that is quietly setting the price of everything else you ship this year.
How we work at Adi Design. On product work we design against the heaviest realistic account rather than a demo, write the rule alongside every pattern, and name the extension slot for areas likely to grow. If your product is getting harder to add to and you are not sure where the cost is coming from, get in touch.
