Designing Systems People Can Actually Use

It’s common for a genuinely well-thought-out system — a process, a piece of internal software, a workflow — to be quietly abandoned within weeks of launch, while everyone involved keeps using the messy spreadsheet it was supposed to replace. The system wasn’t wrong on paper. It was designed for how people were supposed to work, not how they actually did.

Correct and usable are different claims

A system can be logically correct — every edge case handled, every field accounted for — and still fail, because correctness and usability are answering different questions. Correctness asks whether the system produces the right output. Usability asks whether a tired person, on a Friday afternoon, will actually use it the way it was designed to be used. Systems get built for the first question far more often than the second.

Where good systems quietly fail

The failure point is rarely the core logic. It’s almost always somewhere smaller and less glamorous: a required field nobody has the information for at the moment they’re filling out the form, a step that has to happen in an order that doesn’t match how the work actually flows, or a system that assumes a level of attention nobody has by three in the afternoon.

• Requiring information before it’s naturally available, forcing people to guess or skip it.
• Matching an idealised process instead of the one people actually follow under time pressure.
• Punishing small mistakes so heavily that people route around the system entirely.

Designing for the tired version of the user

It’s tempting to design for the most attentive, motivated version of the person using a system. In practice, most usage happens under ordinary conditions — distracted, rushed, doing the minimum required. A system that only works well for someone giving it their full attention will fail for most of its actual use.

The systems that survive contact with real use are usually the ones designed for exactly that ordinary, distracted case — not the exceptional one everyone imagines while designing it.

Technology Decisions Without the Jargon

Non-technical leaders are frequently talked out of trusting their own judgment on technology decisions, on the theory that the subject is too specialised to reason about without a technical background. Some of it genuinely is. Most of the decisions that actually land on a leader’s desk aren’t — they’re ordinary trade-off decisions wearing unfamiliar vocabulary.

Jargon often hides an ordinary trade-off

Strip away the specific terminology, and most technology decisions reduce to familiar shapes: speed versus reliability, cost now versus cost later, flexibility versus simplicity. A leader who has made a hundred ordinary business trade-offs already has the judgment to make this one — what’s usually missing isn’t the reasoning ability, it’s a translation of the jargon into terms that judgment can actually be applied to.

Questions that cut through the vocabulary

A short set of plain questions tends to surface what actually matters, regardless of how technical the underlying system is:

• “What happens if this breaks at the worst possible time?”
• “What does it cost to change our mind about this in a year?”
• “Who has to understand this well enough to fix it if the original team leaves?”
• “What’s the simplest version of this that would still work?”

None of these require technical fluency to ask, and all of them tend to produce more useful answers than “is this the right architecture,” which mostly invites a confident-sounding answer that’s hard for a non-specialist to evaluate.

The real risk isn’t asking a naive question

Leaders often stay quiet in technical discussions out of concern that a question will sound naive. In practice, the more expensive mistake is the opposite: approving a technology decision without understanding its trade-offs well enough to own the consequences later. A plainly-worded question that gets a plainly-worded answer is worth far more than a nod along to language that wasn’t actually understood.

Technology decisions don’t require a technical background to make well. They require the discipline to keep asking until an answer makes sense in ordinary language — and the confidence to treat that as the standard, rather than the exception.