Design for extremes, and everyone else gets a better product

If you design for the average user, you are designing for a person who does not exist. Average is a statistical comfort, not a human being. At Always49 one of the rules we try to live by is to design for extremes. Look at the far ends of requirement, ability, environment, and confidence, and solve for those. Do that honestly and you usually produce something that is easier for everyone in the middle too.

This is easy to agree with in a workshop and easy to abandon when a deadline appears. The “typical user” is a tempting shortcut because they never object. They can see small grey text, they have a fast laptop, they remember their password, they know what an ellipsis icon means. They are not filling in a form on a bus with one hand, they are not using a screen reader, they are not a new starter on day two, or a trustee who logs in four times a year. Real products are full of those people. If your software only works for the typical case, it only works on the slide.

Take target size, a seemingly small detail that has become a live accessibility issue again as WCAG 2.2 criteria move into European standards. A tiny tap target is fine if you have perfect motor control, a fresh screen, and no rush. It is a wall if you have a tremor, large fingers, a cheap phone, or a job that has to be done in gloves. Making the target large enough is not a special mode for “accessibility users”, tt is a better control for a warehouse, a kitchen, a care setting, and a tired evening on the sofa. Extremes reveal the truth of a design.

The same is true of language. We still see products that speak in the dialect of the team that built them: payload, instance, nested resource, submit query. That language is an extreme of expertise. Design for the person who does not have it. Write the label as if the user is intelligent and uninformed, because they usually are. They are not stupid, they are busy. Clear copy is one of the highest-leverage UX decisions you can make, and it costs less than another round of visual polish.

There is an organisational extreme too, and we see it constantly in client work. Some people in a business will use a system all day. Others will use it under stress, once, when something has already gone wrong. Disaster recovery, onboarding, approvals, and incident reporting all live in that second category. If you only test with power users, you will build a cockpit. Cockpits are impressive. They are also how you freeze a manager who just needs to approve one thing before a board meeting. Effortless control means the rare path is as considered as the daily one.

We apply this to environment as much as to body and role. BillyChip is not used in a calm design studio. Shop-floor scanning at Home Bargains is not used like a marketing site. A charitable giving flow has to work for someone who is generous and distracted, not for someone who enjoys reading terms. When we talk about user-first software, we mean first in those rooms, not first in our own. Visiting the extreme context is research. Guessing it from the office is theatre.

Critics sometimes worry that designing for extremes means designing for edge cases at the expense of the commercial majority. We think that is a false trade. Captions help people in a noisy kitchen as much as they help people who are deaf. High contrast helps in sunlight. Plain language helps everyone who is skimming. Keyboard access helps power users as much as it helps people who cannot use a mouse. The extreme case is often just the majority case with the luck stripped off.

So our opinion is not that every product needs every possible accommodation on day one. It is that you should start from the hardest reasonable user and work inwards, instead of starting from a happy path and treating everyone else as a later patch. Patches are how products become uneven. Always49 would rather build the humane version first. It is better ethics. It is also better product sense. When software works at the edges, the centre usually takes care of itself.