Struggling to write simple help text? It might not be your fault

Clear, concise copy is one of the quiet foundations of a good interface. The right label or line of help text lets people understand what a control does and what will happen when they use it, without stopping to think and without reading a manual. Throughout my career I’ve watched talented people struggle to write that copy, sweating over a single tooltip for far longer than seems reasonable. Often, the struggle is telling them something the writing can’t fix.

Simplicity is a symptom of understanding

The best interface text reads as though the feature were obvious all along. That ease is the visible result of someone understanding the feature deeply enough to strip it back to its essence.

There’s a line often attributed to Einstein: “If you can’t explain it to a six-year-old, you don’t understand it yourself.” Your users aren’t six, but the principle holds. If you can distil a feature into a sentence a non-expert grasps immediately, you understand it well. If you can’t, you may not understand it as well as you think, or the feature itself may be more tangled than it should be.

So before you blame your prose, get properly to grips with what the feature actually does. Working closely with the developers who built it is the fastest way there. More often than not, the act of trying to explain it simply will expose exactly where the complexity lives.

The warning signs of complexity

Some phrases are tells. The moment you find yourself reaching for “unless…”, “except when…”, or “but only if…”, pay attention. Conditional language is a signal that the behaviour behind the words branches in ways the user now has to hold in their head.

Take a save button whose help text wants to read: “Saves your changes, unless the record is locked by another user, in which case your changes are queued until the lock clears.” You can wordsmith that all day and it will never be simple, because the behaviour isn’t simple. The honest fix is to decide what should happen when a record is locked and design that clearly, so the help text can shrink to “Save changes” and a clear message only when a conflict actually occurs.

The rule of inherent simplicity

Which gives me a rule I keep coming back to:

If explaining a feature requires complex or lengthy instructions, that’s usually a sign the feature itself needs simplifying, rather than the explanation.

In other words, when it’s genuinely hard to describe something simply to your users (allowing for what they reasonably already know), the problem often sits in the design rather than the copy. The writing is just the first place it shows up, because writing forces you to be precise in a way that wireframes let you avoid.

Wrapping up

Writing good help text and labels is really a thinking job that happens to end in words. It means understanding the software, partnering with the people who built it, and being willing to push back when the simplest honest description of a feature is still a mouthful.

When the copy won’t come out simple, resist the urge to keep polishing. Treat it as a piece of usability feedback arriving early, the interface telling you, before a single user does, that something underneath needs to be made simpler. Far from being a failure of writing, it might be the most useful thing your writing does all week.