The usefulness test

The ideas I trust most usually start with a small irritation: some ordinary moment where a system makes people do more work than they should have to.

Small friction is still friction

The ideas I trust most usually start with a small irritation. Not a grand market opportunity. Not a pitch deck. Just some ordinary moment where the system underneath daily life makes someone do more work than they should have to.

Checking which bin goes out after a public holiday. Finding a toilet nearby without opening five tabs. Looking at the water and wondering what is actually moving out there. None of these are dramatic problems, until you are the person who needs the answer.

That is the usefulness test for me: does this remove a real piece of friction?

Quiet tools are often the best tools

I like software that earns its place quietly. The best tools do not need to explain themselves for very long. You arrive with a question, the interface understands the shape of that question, and the answer appears without making you feel like you have entered someone else’s business process.

That sounds simple, but simple usually means the mess has been moved somewhere else. Behind the calm surface there is often a council endpoint behaving strangely, a dataset with missing fields, a UI decision about what not to show, or a bit of automation keeping the whole thing from becoming manual labour.

Useful does not mean plain. It means the design has a job, and it knows what that job is.

The mess belongs behind the curtain

The part I enjoy is finding the awkward join between the real world and the digital version of it, then making that join feel less awkward. That might mean turning segmented council data into one address lookup, or turning live AIS information into a map someone can scan without decoding technical fields.

The work is not just technical. The interface has to decide what deserves attention. The copy has to explain enough without turning into documentation. The visual design has to feel calm even when the data source is not.

I think that is why small public tools are such useful practice. They force you to respect ordinary context. Nobody is sitting down with a cup of tea to admire a bin-day app. They want the answer, probably late, probably on a phone, probably because the normal rhythm has broken.

Knowing when not to build

Not every idea needs to become a product. Some are too narrow, too temporary, or only useful to me. Tinkering is good, but publishing something means accepting a little responsibility for the person who finds it later.

When a small tool keeps coming up in conversation, though, I pay attention. If someone else says, “actually, I could use that too,” the idea has crossed a useful line. It has stopped being only a private workaround and started becoming a shared piece of infrastructure, however small.

Useful things deserve care

Useful is not the opposite of beautiful. Useful things deserve good type, fast loading, clear language, accessible controls, and an interface that respects the person using it. A practical tool still creates a feeling. It can feel rushed, indifferent, and bolted together, or it can feel considered.

But usefulness comes first. If the thing does not make life easier in some concrete way, polish is decoration. The goal is not to make small problems look important. The goal is to solve them well enough that people can stop thinking about them.

That is the standard I keep returning to in my own work: make something that earns its place by being useful, then give it enough craft that the usefulness feels trustworthy.

← How much does a custom web app cost in NZ? What tinkering teaches you →