Demonstration critique · UX teardown
What a broken public-service form teaches us about usable design
A form can technically work and still fail the people using it. This test article examines five common points of friction and turns each one into a practical design improvement.
Written by Rwanda Free Space
Published
Reading time 8 minutes
The worst forms rarely look completely broken. They load. Their inputs accept text. A button eventually sends something somewhere. The failure appears in the gap between technical completion and human understanding.
01
The core problem
People arrive at a public-service form with a specific goal. They may need a document, an appointment, or permission to continue an important process. The interface should reduce uncertainty. Too often it adds more.
A weak form asks for unfamiliar information without explaining why, marks errors only after submission, and clears useful work when something goes wrong. None of these failures is visually dramatic. Together, they make the service feel unreliable.
A working submit button is not the same as a usable service.
02
Where the form creates friction
The first issue is language. Labels written for the database or internal office process force the visitor to translate the system before answering. Plain labels, short examples, and a sentence explaining unusual requests can remove that burden.
The form hides its requirements
Required documents and accepted formats appear only after an upload fails.
FixShow requirements before the visitor starts.
Errors arrive without a recovery path
A red border signals a problem but does not explain what changed or how to continue.
FixName the error and place guidance beside the field.
Progress is invisible
Visitors cannot tell how much work remains or whether they can return later.
FixShow scope, progress, and save behavior from the start.
03
A better approach
Start by writing the journey in the visitor's language. State the outcome, list what is needed, and divide the form only where the steps match a real change in the task. Keep completed information safe when validation or the network fails.
Before startingExplain the outcome, documents, time, and cost.
While completingUse familiar labels, useful defaults, and visible progress.
When errors happenPreserve input and explain exactly how to recover.
After submissionConfirm what happened and what the visitor should expect next.
04
The wider standard
Better forms do more than improve completion rates. They communicate respect. They tell people that their time, data, and attention matter. That should be the baseline for every digital service built for the public.
The useful question is not whether the page shipped. It is whether someone can understand it, complete it, recover from a mistake, and trust what happens next.