Usability.ie
What you receiveEngagements & scopePublic-service teamsCapability summaryMethod finderBrief builder

When the person completing the application is not the applicant

A public-sector application assumed that the person at the keyboard was the person seeking support. Research revealed helpers completing applications on someone else's behalf, alongside late eligibility checks and inconsistent guidance. We brought policy, technology and support teams together around the application people actually had to complete.

Key findings

  • The most consequential finding was that the applicant was often not the person completing the form.
  • Eligibility was established too late.
  • Guidance differed between language versions and between the website and contact-centre scripts.
  • Important guidance also lived in documents that were difficult to use on a phone and failed accessibility checks.
Two people, one application: the applicant, and the helper at the keyboard
The brief

An easier application.

The real problem

The form assumed the person typing was the person applying. Often they weren’t.

Usability.ie · Client workA public-sector service

At a glance

The client operated a grant application service. It wanted to improve the online experience and increase digital uptake. The application was delivered with an external technology supplier, while policy, support, language and data-protection teams each owned a part of the service.

We led the research and evaluation across the application, its guidance and the help available around it. The work included people applying for themselves and people helping others, along with the operational teams dealing with questions and failed attempts.

The brief

The brief asked for better usability and accessibility of the online application. At first glance, that could be interpreted as a form review. But people reached the form through guidance, asked questions by phone and sometimes depended on another person to complete it. Treating those as separate channels would miss the service they were trying to use.

The research therefore covered what happened before, during and around the application. We needed to understand not just which field caused a problem, but whether people knew they were eligible, which person held the information and what happened when they asked for help.

Working across the service

Several teams could approve or prevent a change. Policy owned the rules. The technology supplier owned implementation. The contact centre dealt with uncertainty and exceptions. Language and data-protection colleagues needed the service to work consistently within their responsibilities.

We used regular shared sessions to put the evidence in front of those teams together. Otherwise, each could reasonably improve its own part while leaving the application as a whole inconsistent. An application could be clearer on the website but still contradicted by the answer given over the phone.

The agency also required consistent eligibility guidance for applicants. We did not vary the rules or eligibility explanation between live groups to create an experiment. Prototype testing and a staged rollout were better suited to that constraint. Accessibility was considered throughout the application, not as a separate final-page check.

How we ran the research

We observed the contact centre and listened to the questions staff were receiving. Those conversations exposed places where people needed an explanation that the website did not provide. They also showed where staff had developed workarounds or explanations that differed from the published material.

Moderated sessions included older people, people using weaker connections, people using assistive technology, people using different language versions and people completing applications for others. These were different circumstances in which the same service had to work, rather than a single assumed digital user.

We reviewed the full application for accessibility, compared the language versions and analysed application rejection reasons. Bringing those sources together let us connect a recurring call with a piece of guidance, an eligibility rule or an assumption in the form.

What we found

  1. The most consequential finding was that the applicant was often not the person completing the form. Helpers knew parts of the application the applicant did not, while some confirmations belonged to the applicant. The form assumed one person held every piece of information and could make every declaration. Shared access became a workaround for an unsupported role.

  2. Eligibility was established too late. People could invest time in the application before discovering that the scheme did not fit their circumstances. Moving the check was not just a way to shorten a form. It would help someone decide whether to begin at all.

  3. Guidance differed between language versions and between the website and contact-centre scripts. A person could receive different information depending on how they reached the service. Updating a screen alone would not resolve that inconsistency.

  4. Important guidance also lived in documents that were difficult to use on a phone and failed accessibility checks. The form depended on information that some people could not conveniently read while completing it. Those documents were part of the application experience even though they sat outside the form.

What changed in the delivery approach

We developed and tested an earlier eligibility check so that people could understand the basic fit before beginning the full application. We also worked through a route for applying on someone else's behalf, including the point at which the applicant's consent was needed. That made a real user role explicit instead of relying on shared access.

Content work addressed the publishing process as well as the words. Language versions needed to be maintained together so that a policy update did not create different guidance for different users. Support scripts needed to reflect the same information as the website.

We worked with the supplier on moving guidance into accessible web content and addressing the issues identified in the application. Retesting provided a way to check the implemented corrections rather than closing the work when a report had been delivered.

The evaluation followed application difficulties, requests for help and the consistency of the service through the staged rollout. The important delivery change was that policy, content, support and technology were working against the same observed problems.

The principle

A service can be designed around the right applicant and still assume the wrong user. Research needs to include the people who help, the people who answer questions and the handovers between them. The form is only one part of that system.