India's Digital Rails Work. The Last Screen Often Does Not.

India's digital public infrastructure is the most studied thing in govtech. Aadhaar has crossed 1.44 billion enrolments. UPI moves more transactions than any comparable rail on earth. Twenty four countries have adopted parts of the stack. DigiLocker, API Setu, UMANG, GeM, e-Courts and e-Hospital sit on top of it.

The rails are extraordinary. The counter is uneven.

We have built inside this system, including ordering systems for the Parliament of India and a compliance platform for the Bureau of Energy Efficiency. The pattern we keep meeting is the same one anyone who has renewed a certificate at a state portal already knows. The identity layer works. The payment layer works. The service sitting on top of them was built by a different team, to a different standard, in a different decade, and that is the layer the citizen actually touches.

The gap is not infrastructure, it is the last screen

A citizen does not experience DPI. They experience a form.

They experience whether that form tells them, before they start, which documents they need. Whether it saves what they typed when the session expires. Whether the error says "invalid input" or says which field and why. Whether the status after submission is a number they can act on or a number they can only quote back to a helpline.

None of those are infrastructure problems. Every one of them is a service design problem, and they are decided at the department or municipality that owns the service, which is why the experience varies so sharply between two states using the exact same national rails.

Four failures that repeat

The form that mirrors the file. Most government forms are the paper form, transcribed. The sections follow the internal filing order, not the order the citizen has the information in. A citizen holds their documents in one order and the form asks in another, so they scroll back and forth and abandon.

Status that is not status. "Under process" is not status. Status is which stage, who holds it, what happens next, and roughly when. Citizens call helplines because the screen refuses to answer a question the system already knows the answer to. Every one of those calls is a design bill paid by the department.

Rejection with no route back. An application rejected for a fixable reason should say what to fix and offer the way to fix it. Instead it usually ends the journey, and the citizen starts again from a blank form, often making the same mistake, because nothing told them what it was.

Language that is translated, not written. Multilingual delivery frequently means the English was written first and machine translated. The result is grammatically present and practically unusable, especially for the exact users the multilingual requirement exists to serve.

Consistency is a design system problem

MeitY has been running UX4G awareness and design system workshops across states, and that direction is right, because the underlying issue is not that departments lack designers. It is that every department is solving the same twenty interface problems separately.

Date of birth entry. Aadhaar and PAN field validation. Address capture with pin code lookup. Document upload with size and format limits. OTP entry and retry. Payment confirmation. Application status. Grievance filing. These recur across effectively every citizen service in the country, and each one gets rebuilt, badly, per portal.

A shared, accessible, tested component set is the highest leverage intervention available in Indian govtech. Not a style guide as a PDF. Working components, with the accessibility already inside them, that a department can adopt in a sprint. GIGW 3.0 gives the standard; components are how a standard actually reaches production.

Design for the hardest case, not the average one

The user who defines the quality bar for a government service is not the median user. It is a first-time applicant, on a low-end Android phone, on an intermittent connection, in their second language, applying for something they need.

Design against that person and the service works for everyone. Design against the average and it fails precisely the people it exists for. This is the single most consequential framing decision in public service design, and it costs nothing to make.

Practically it means: keep pages light and forgiving of dropped connections, save progress by default, state document requirements before the first field, write errors in plain language that names the fix, and make every screen work with a keyboard and a screen reader because a meaningful share of applicants need that and have no alternative provider.

What we would measure

Not portal visits. Not registrations.

Completion rate for a first-time applicant. Time from submission to a decision the citizen can see. Share of applications rejected for a fixable formatting reason. Helpline call volume per thousand applications, and what those calls ask. That last one is the cheapest usability study any department already owns and almost nobody reads.

India built the rails. The work now is the last screen, and that is design work.

We build public-sector software that has to hold up under scrutiny. If you are responsible for a citizen-facing service, we should talk.