Whose Life Does an Innovation Make Easier?

A process can now be completed by phone. We welcome the news: less travelling, no queue, no papers to carry. Then we stand beside someone trying to complete it. They enlarge the text, ask what belongs in a box and struggle to understand why the code they received has been rejected. The system is running. That person’s task has not yet become easier.

I am not looking for a reason to dismiss innovation. Many tools create real possibilities in everyday life. But a possibility being available and a person being able to use it are different things. Expecting the user alone to close that gap can quietly transfer the responsibilities of design and institutions onto somebody else.

Watching the people most comfortable with a system provides some answers. We can see its speed and count the steps needed to finish a familiar task. Watching the person who struggles raises other questions. Where do they stop, which instruction do they interpret differently and how do they recognise a mistake? The limits of the promise of convenience often become visible at these pauses.

A tool should also make sense to somebody who does not possess its designer’s knowledge. Knowing in advance which document will be requested, recognising a file format or immediately understanding a small symbol are not universal everyday skills. Assuming that every user arrives prepared and knowledgeable can mean expecting people to know what they need to learn before they begin.

Without having to ask for help

Completing a process with somebody else’s assistance may seem sufficient. When help becomes a permanent requirement, however, a person’s room to act independently can shrink. Calling a relative for every application, showing every detail to somebody else or asking another person to access an account involves more than time. Privacy and independence belong within the experience too.

Plain language, text that can be enlarged and a clear explanation of an error should therefore count as substantial design decisions. They can allow a person to finish a task independently. Explaining why information in a field was rejected provides different assistance from merely displaying a red warning. A system should also make clear how to continue after something goes wrong.

A good explanation need not talk down to anyone. Explaining something simply differs from assuming the listener is simple. Describing why a step is needed, where information will be used and what happens next gives the user an opportunity to think. It invites participation instead of demanding blind obedience to an instruction that has not been understood.

Sometimes the difficulty lies in too many options rather than too few. A screen may contain several similar buttons, different names for the same task or unnecessary details obscuring essential information. More features do not always create more usable possibilities. Being able to distinguish the route we need is also an outcome of design.

Listening to those left outside progress

Closing an old method the moment a new one is introduced may assume that everybody can adapt at the same pace. Every method cannot be maintained indefinitely. A transition period, a route to support and a way of handling exceptions can nevertheless be considered. The day a change is announced and the day people can use it do not always coincide.

Age alone is an inadequate explanation here. A young person may struggle with a complicated task while an older person completes it comfortably. Language, education, devices, connectivity, fatigue and the circumstances of a particular day can all alter the experience. Rather than assigning people to fixed groups, a more useful beginning is to notice what they need at each step.

Listening to users requires more than collecting favourable comments. Someone who abandons a task, never starts it or hands it to a relative has an experience worth understanding. These people do not appear as completed transactions. Their absence can nevertheless show whom the system is failing to reach. Recording success should include looking for the traces of withdrawal.

The experience of staff belongs in the same picture. An unclear system may bring the same questions to a desk again and again. The user’s difficulty becomes the employee’s workload. Asking only for more patient answers leaves the recurring ambiguity intact. Improving an instruction or a sequence can make the day easier for both sides.

When assessing an innovation, I am interested in more than the time saved. I also want to know who has fewer explanations to give. Who can now finish their own task, and who has become continually dependent on somebody else? These questions do not oppose improvement. They help us examine how its benefits are distributed through real lives.

A good tool does not need to display all its complexity to the person using it. However much happens behind the scenes, it can offer an understandable path. Perhaps the value of innovation becomes clearest when somebody previously left at a doorway can now pass through independently. Progress becomes tangible in the lives where that passage is possible.