My father is 70 and uses an app every day — this is how you build it

Age is not the problem

It is easy to say that "older people can't cope with technology", and it is almost never true. Someone who grew up without a computer learned to drive, to run a household, to fill in forms and to get through government offices — all far more complicated than any app. What they did not learn, quite reasonably, is to guess. They do not assume that three dots in a corner hide a menu, that swiping sideways deletes something, or that the button which moved to the bottom of the screen yesterday is still the same button.

Ordinary software is built on the assumption that the user will guess right, and if not, will try again. People who do not like technology do not try again. They close it and do not come back. As far as they are concerned the failure is the tool's, not theirs — and they are right. So the question is not how to teach them to use it, but how to build something with nothing in it to learn.

There is a real difference between younger and older users, but it lies less in skill than in patience for things that are unclear. The W3C, which sets the web's accessibility standards, notes that many of the needs of older users — eyesight, precision of touch, short-term memory — overlap with accessibility needs in general. In other words, what you build for them makes things better for everybody.

The test of success: he never phones to ask

Before a line of code was written, we decided what success would look like. Not a number of features, not a design, and not "he said it looks nice". Success was defined like this: a week after he gets the app, he uses it every day — and never phones to ask about anything.

It sounds like a modest test, but it is a demanding one. Any screen that raises a question fails it. Any error message containing the word "server" fails it. Any button that does two different things depending on context fails it. And above all, it rules out the convenient answer, "we'll give him a training session". Training is an admission that the tool does not explain itself; we went into this in our piece on the system that needs no training.

Seven rules we learned from one app

1. One screen, one action. The app does one thing: it records an expense. When you open it, the first thing you see is the place to record it — not a menu, not a dashboard, not a "welcome". Anything that is not that action simply is not on his screen.

2. No password at the door. For most older users, a forgotten password is the end of an app: they will not reset it, and they will not tap "forgot password". The app opens from a personal link installed on the home screen, and the security happens behind the scenes — not as a chore he has to perform every morning.

3. His words, in his language. Not "category", not "sync", but the words he himself uses when he talks about the expense. And the whole interface is in his mother tongue, even though the developer thinks in another one. Every word that has to be translated in your head is one more chance to stop.

4. Buttons do not move. A new version that moves a button — even for the better — wipes out what the hand already knows. For him, every change goes through one check: is what was in a given place yesterday still there today?

5. Genuinely big, not "fairly big". The action button is almost as wide as the screen, and the text is high-contrast and clear. The WCAG 2.2 accessibility standard sets a minimum size for touch targets — and that is the floor you start from, not the goal.

6. Confirmation you can see. After saving, the screen says plainly that it was saved, and shows what was saved. Someone who is not sure the action worked will either do it again — and now there are duplicates — or phone to ask. Both are a failure of the interface, not of the user.

7. Forgiveness instead of "Are you sure?". A confirmation box before every action teaches people to tap "Yes" without reading. It is better to make mistakes easy to fix afterwards than to frighten people before they act.

What we refused to add

The hard part of building the app was not deciding what to put in, but what to leave out. Every idea that came up made sense — monthly charts, reminders, a settings screen, a searchable history — and roughly half of what we thought of never went in.

We did not reject those ideas because they were bad. We rejected them because each one would have given him something else to look at, somewhere else to tap by mistake, and another reason to pick up the phone. A chart is wonderful for someone analysing; for someone who just wants to record an expense, it is noise. And the person who does need the overall picture gets it on the other side: whoever manages the accounts receives a tidy Excel workbook, without my father ever seeing a row of it. The complexity did not disappear — it moved to where someone actually wants it.

We wrote at length about the cost of every "just one more little button" in more features, more mess.

Simple on the outside, work on the inside

People tend to assume that an app with one button is an easy app to build. The opposite is true. For the user not to have to think, someone else has to do the thinking for them in advance: what happens when the signal drops in the middle of saving, what happens when the button is pressed twice, and how a photo of a receipt ends up in the right place, under a name someone will still be able to find a year from now.

Each of those questions is an engineering decision, and none of them is visible on the screen. That is what it means to treat simplicity as an achievement: not less work, but work the user never has to see. Its price is paid once, when it is built — not every day, in phone calls.

And why this matters for your business

You may not have a parent who needs an app. But almost every business has someone the system has to work for as well: the long-serving employee who has done the job brilliantly for twenty years, the client who fills in a form once a year, the site foreman reporting in from the field in the middle of a long day. They are not "bad with technology". They are simply busy with something else.

The questions are the same: what is the one task they need to do, what do they call it, and what happens when they get it wrong? A system that answers those well will serve everyone, including the people who love technology — nobody is offended when something just works. And if you are weighing what goes in and what stays out, we set out the long-term arithmetic in what it really costs to keep a website or app running.

Is there someone in your business — an employee, a client, a parent — the current system just does not work for? Write to us in two lines about who they are and what they need to do on an ordinary day — and we will tell you honestly whether it can be made simpler.