Building for all ages: what a teenager and a parent both need from a tool

The phrase "designed for all ages" usually means "designed for nobody in particular." It tends to produce software that is rounded, colourful, cautious, and vaguely condescending to everyone using it.

But the underlying goal is real. A CraftlyKit game might be opened by a fifteen-year-old between classes, and a CraftlyKit tool might be opened by their parent trying to fix a spreadsheet. Both should feel the thing was made for them. That is achievable — it just requires being specific about where the two groups actually differ, which is a shorter list than people assume, and where they do not, which is a longer one.

Where the differences actually are

Having watched people of very different ages use the same small tools, the meaningful differences cluster in three places. None of them is "one group is better with technology."

Tolerance for guessing

A teenager encountering an unfamiliar interface will generally click things to find out what they do. It is a fast, effective strategy, learned from software that is mostly reversible.

Someone older often will not, and the reason is usually not confusion — it is a reasonable fear of breaking something or triggering something irreversible. If you have ever lost work to a mis-click, you learn to read before you click.

The design consequence is not "add more explanation." It is make actions obviously reversible and clearly labelled, which serves both groups at once. Confident clickers explore faster when nothing is destructive, and cautious users act sooner when the label says exactly what will happen. A button that says "Convert" tells you more than one that says "Go", and both audiences benefit.

What counts as an obvious convention

Interface conventions are learned, not innate, and different generations learned different ones.

A hamburger menu is obvious if you learned phones in 2015 and opaque if you did not. A floppy-disk save icon is obvious to people who used floppy disks and arbitrary to everyone else. Swipe gestures with no visible affordance are natural to some people and invisible to others.

The safe approach is not to pick the newer convention or the older one. It is to use the convention and also say the word. An icon with a text label beside it works for everyone and costs a few pixels. Unlabelled icon-only interfaces are the single most common way small tools quietly exclude people.

Default text size

Younger eyes handle small text. Older eyes often do not, and neither group should have to zoom. The fix is boring: set a body size around 17-18px rather than the 14px that looks tidy on a designer's monitor, keep line lengths in the 60-75 character range, and never disable pinch-zoom on mobile.

This is one of those choices where the "designed for older users" version is simply the better version. Nobody has ever complained that text was too comfortable to read.

Where they do not differ at all

The list of things both groups want is much longer, and it is where most of the actual work is.

Nobody wants to make an account. The assumption that teenagers happily sign up for things and adults resist is wrong in both directions. Everyone resists a sign-up wall in front of a tool that could just work. This is why nothing on this site asks who you are before it does its job.

Nobody reads instructions. Not the teenager, not the parent, not the developer who wrote them. Interfaces have to be understandable through use, which is the same constraint that governs the games.

Everyone is on a phone at least half the time. The assumption that adults are on desktops and teenagers are on phones is decades out of date. Both are on phones, often the same model, often with the same cracked screen.

Everyone is impatient. Load time does not have an age gradient. Four seconds is too long for a fifteen-year-old and too long for a forty-five-year-old.

Everyone is doing something else. Nobody gives a small utility their full attention. It is used in a gap, between two other things, with a conversation happening nearby.

The accessibility overlap

Almost every choice that widens an age range is also an accessibility improvement, which makes this an unusually efficient area to work in.

• Larger default text helps older readers and low-vision users.
• Strong colour contrast helps in bright sunlight, on cheap screens, and with colour vision deficiency.
• Visible keyboard focus helps keyboard users, screen reader users, and anyone whose trackpad is unreliable.
• Labelled icons help new users, non-native English readers, and screen readers.
• Respecting prefers-reduced-motion helps people with vestibular disorders, and also people on a slow device where the animation would stutter anyway.
• Touch targets of at least 44 pixels help small hands, unsteady hands, and everyone on a moving bus.

None of these are "accessibility features" bolted on at the end. They are what a well-built interface looks like, and the population they exclude when missing is far larger than the population usually imagined.

Where the two audiences genuinely diverge

Two places do need real, separate decisions rather than a shared solution.

Tone. Copy written to be relatable to teenagers usually reads as embarrassing to adults, and copy written to sound professional reads as stiff and boring to teenagers. The way out is not to split the difference — it is to be plain and specific instead of trying to have a personality in the microcopy. "Nothing here yet" works for everyone. "Oops! Looks like this space is feeling a little lonely 😢" works for nobody.

Handling of minors' data. This one is not a design preference, it is a legal and ethical obligation. A site that a fifteen-year-old might use is a site that has to think about COPPA, about not collecting more than it needs, and about what advertising means in that context. The practical answer here is to collect as little as possible from anyone — no accounts, no profiles, local storage instead of server storage — which sidesteps most of the question by not creating the data in the first place. The specifics are in the privacy policy, written to be read rather than to be legally survivable.

The test that works

The most useful check is not a persona document. It is this: hand the thing to someone in each group, say nothing, and watch where they stop.

The stopping points are almost never where you expected. They are usually a word that means something different to them than to you, an icon whose meaning you assumed was universal, or a moment where they are not sure whether an action already happened.

That last one is worth dwelling on. A large share of confusion in small tools is not about what to do next — it is uncertainty about whether the previous thing worked. A visible confirmation after every action removes more friction, for every age, than almost any other change.

It is the rule I leaned on hardest building TabVault, which has to work for a student saving thirty research tabs and for someone who just wants to keep their place in one long video. Saving a tab shows you immediately that it saved, and into which category — because the alternative is a person clicking the button twice, unsure whether the first press did anything.

If you have tried something from here and found the place where it stops making sense, that is the most useful thing you could send me. The projects page has what currently exists.