Scaling Interaction Assumptions

Scaling — interaction assumptions

The second kind of scaling fallacy: assumptions about how users will behave, what use cases they'll have, what they'll consider acceptable. A design that works for 100 early users — who tend to be sophisticated, motivated, and tolerant of rough edges — frequently fails for 100,000 broad-audience users who lack those qualities.

Interaction scaling is often harder than load scaling because it requires anticipating how a broader, more diverse audience will use the product. Engineers can load-test infrastructure; product designers have to imagine future users.

Common interaction-scaling failures

Original audience assumptions don't transfer. A productivity tool designed for engineers expects technical sophistication; when adopted by non-technical professionals, the assumptions fail.

Edge cases become common. A 1-in-1000 case happens 100 times a day at a million users. Designs that assumed "this won't happen often" find that it does.

Feature discovery breaks down. Features that were discoverable when the product had 5 of them become invisible when the product has 50. Users miss capabilities or use them wrong.

Onboarding doesn't scale. A hands-on onboarding (calling each user, showing them around) works for hundreds; doesn't work for hundreds of thousands.

Support model doesn't scale. Founders answering every support email is fine at 10 users; impossible at 10,000.

Moderation doesn't scale. Manual content moderation works for small communities; impossible for large ones. Algorithmic moderation has its own issues.

Cultural and linguistic assumptions don't transfer. A product designed for one country has assumptions (language, units, formats, cultural conventions) that fail in others.

Accessibility gaps surface. A product that "works for our team" may have accessibility gaps that affect the broader audience disproportionately.

Naming conventions don't scale. Personal names, address formats, ID systems vary widely; designs based on one convention fail for others.

Power-user features intimidate novices. Capabilities that are useful for sophisticated users overwhelm casual users.

Designing for interaction scale

Anticipate diversity. Imagine the full range of users you'll have, not just your current users. New audiences, languages, abilities, technical skill levels.

Design for the long tail. Edge cases at scale become routine cases. Test with weird names, unusual addresses, unexpected workflows.

Build for self-service. Users who can solve problems themselves don't need support. Documentation, error messages with recovery paths, contextual help.

Plan for moderation at scale. What happens when bad-faith users find your product? Spam filtering, abuse reporting, automated detection.

Internationalize early. Adding internationalization (translation, locale formatting, right-to-left layouts) after launch is much harder than designing for it from the start.

Plan for accessibility from the start. Accessibility built in from the start is cheap; bolted on later is expensive and incomplete.

Calibrate features to scale. Features that are appropriate at one scale may be inappropriate at another. Manual review, hand-curation, personal touch — all need to evolve.

Design for varying technical sophistication. Unless your audience is uniformly sophisticated, design layers that accommodate different skill levels.

Worked examples

A productivity tool designed for engineers

A team builds a document-editing tool initially used by engineers. Heavy use of keyboard shortcuts, technical terminology, and assumed comfort with markdown. Engineers love it.

The product expands to non-technical professionals. They struggle: keyboard shortcuts they don't know exist; terms like "fork" and "branch" mean nothing; markdown is foreign.

The fix: layered control. Engineers keep their keyboard-shortcut workflow; non-technical users get a WYSIWYG mode with simpler vocabulary. Both audiences served.

The lesson: original-audience assumptions need to be questioned as the audience broadens.

A name field that breaks for international users

A signup form has First Name and Last Name fields, each capped at 30 characters. Works for most US users. Fails for users with long names, multi-component names (Spanish, Korean naming conventions), single-name users (Indonesian convention), users with name characters outside ASCII.

The fix: a single "Full Name" field with generous character limit and Unicode support. Don't impose name structure assumptions.

The lesson: cultural assumptions baked into forms surface as the audience diversifies.

Manual moderation that doesn't scale

A community platform's founders moderate every post personally for the first year. Quality stays high. As the platform grows past 10,000 users, manual moderation becomes impossible. They try to hire moderators; quality drops; bad-faith content slips through.

The fix: combination of automated detection (machine learning), community moderation (trusted users), and reactive moderation (report-and-review). The previous "manual everything" approach can't scale.

The lesson: processes that depend on human attention per item don't scale; design for scale by automating, distributing, or eliminating.