Digital access is more than owning a smartphone

A service becomes digital when its form appears on a screen. It becomes usable when a person can understand what is being asked, complete the task, and know what will happen next. Those are different milestones.

My family’s shops have made this distinction concrete for me. A tool may offer the functions a business needs and still be difficult for the people doing the work. If using it depends on specialist knowledge or constant assistance, access to the device has not solved the whole problem.

I think we should apply the same care to services that people depend on in everyday life.

Design for the task, including the difficult moments

Consider someone completing an application. The most important question may be whether they can finish it without losing progress when a connection fails. Another person may need a clear explanation of a rejected document. Someone else may understand the subject but struggle with the language used by the interface.

These are design scenarios, rather than findings from a survey. They are useful because they move the discussion from “Can a person open the page?” to “Can a person complete the service?”

A successful submission should produce an understandable receipt or reference. A delay should have an explanation. A correction should not require a person to guess which earlier action caused the problem.

Accessibility is part of quality

India’s Guidelines for Government Websites and Apps explicitly address usability, user focus, and universal accessibility, with accessibility guidance based on WCAG 2.1. There is an established framework to work from; teams need to apply it in the details of the service.

For a product team, that includes readable text, useful labels, keyboard access, and information that does not depend on colour alone. A technical review should be accompanied by testing with the people who are expected to use the service.

When something goes wrong, the error message should describe the problem and give a workable next step. “Invalid input” places the burden on the user. Explaining which field needs correction and what is accepted helps them move forward.

Human support needs a place in the process

Digital services should reduce unnecessary effort. They should also have a sensible route to assistance. A person who cannot complete a task should not be trapped between an automated response and an office that sends them back to the same page.

I would like teams to design support as part of the original service. Who handles an unresolved case? What information do they need? Can they see what the user has already tried, without asking for unnecessary sensitive information?

The aim is to make assistance useful and accountable. A helpline number alone does not establish that someone owns the resolution.

Measure completion and recovery

Page visits and registrations are easy to count. I would also ask how many people finish the task, where they abandon it, and how long a problem takes to resolve. Those measures can reveal friction that a launch announcement cannot.

Teams should examine who struggles, while protecting privacy and avoiding assumptions about individuals. Testing in more than one language and on modest devices can expose different problems from a demonstration on a developer’s computer.

Access is a continuing responsibility. A change in a form, a new verification step, or an updated document requirement can introduce fresh difficulty. Listening to the people using a service should continue after launch.

The standard I would like to see is simple to state: a person can understand the process, finish it with dignity, and obtain help when they need it. Achieving that standard takes consistent work across design, engineering, and operations.