Perspective
Ask Citizens Fewer Questions and Every Service Redesign Starts From a Stronger Place
Your department's own records show which questions a form can drop. We research with real applicants, redesign the path and measure the live result against your earlier figures.
4-minute read5 November 2026
In Brief
- A form moved online field for field still asks for what the department holds, and sends officers to check scans by eye. Applicants carry the effort, and the department carries the returned files.
- We see four actions: read the rejection and helpdesk records, ask who uses each field, fetch records the state already holds, and test the new path with real applicants.
- Thinqmesh researches with real applicants, maps where they drop out, and brings your first redesigned service path to a working version within four weeks.
When a government service goes online, the paper form often arrives with it, field for field. The applicant still types an address the department already holds, and still uploads a scan of a certificate that another office issued, so that an officer can open it and check it by eye. We believe the most valuable change a department can make to a citizen service is to ask fewer questions, and that this comes before any new design or portal. The evidence for which questions to remove is already in the department's own records.
Every Field Should Change a Decision
Rejected applications, counter and helpdesk queries, and officers' verification work all show where a form asks too much. A field that no officer reads survives from an old paper form. A document that officers check against another government record shows where the department can fetch the record itself.
The applicant carries the cost of each unnecessary question as time, repeat visits and abandoned applications, and the department carries it as returned files and re-keyed data. Removing a question needs agreement from the process owner and little else, so it is the quickest improvement available.
Four Actions That Remove Questions From a Service
The evidence for what to remove already sits in your operational data, so the first three actions need no new research programme.
Read the Rejected and Returned Applications
Group the reasons for return. A large share from one field or document points to a question that has been charged to applicants.
Returned files show where a form is misunderstood or asks for something applicants cannot produce. We group the reasons by field, document and question, and rank them by volume. The top of that list is the first place to redesign, and it comes from your own records.
Get started
- Pull the last quarter's returned applications with their stated reasons.
- Rank the reasons by volume and note the top three fields.
Ask Who Reads Each Field and What It Changes
A field can survive from an old paper form with no one now using the answer. Removing it needs agreement from the process owner and a legal check.
For each field we ask which officer reads it and which decision it changes. A field with no reader goes. This step needs no integration, so it is the quickest improvement available, and it shortens the form before any new design begins.
Get started
- List every field on one service form.
- Ask the officer who processes it which fields they use.
Fetch What the State Already Holds
Where officers compare an uploaded document with another government record, the department pays a person to compare two copies of one thing.
That verification work marks the highest-value place to fetch the record directly from its issuing source. We map where it happens, agree the source with the owning department, and build the connection so applicants no longer upload a scan of something that office already issued.
Get started
- Find the verification checks officers do by hand today.
- Name the department that issues each document being checked.
Watch Real Applicants Complete the New Path
Counter queries, helpdesk calls and a session with a real applicant on an ordinary phone show where the redesign still asks too much.
We watch applicants attempt the service and map the whole path, including the call to the helpdesk they make when a step is unclear. Each redesigned path is released in a small piece and measured against the earlier figures, so the department can change direction on the evidence.
Get started
- Collect the five most common helpdesk questions about the service.
- Arrange a session with three applicants on their own phones.
How Thinqmesh Solves This
We begin with your own records and with applicants using the real service. Design and build sit together, so what is designed can be built. The full engagement runs to eight weeks.
- Week 1
Applicants, Watched on the Real Service
We run research with real applicants on your key path, and read your returned files and helpdesk records beside it.
- Week 2
The Whole Path Mapped, Drop-Outs Found
We map the path across the portal, the counter and the helpdesk, and mark where people drop out and which questions can be removed.
- Week 3
The First Path Redesigned and Built
The first redesigned path is built on shared components from a tested design system that your team can reuse.
- Week 4
A Working Version, With Analytics
Your first path reaches a working version, with analytics that show whether the change worked against the earlier figures.
You finish with a redesigned first path, a map of where people drop out, a design system you keep, and analytics that show whether the change worked. The code is yours.
