Re-architecting government onboarding by deleting an entire account type.
A national PhD portal was stalling two of every three institutions partway through sign-up — most only got through after rounds of calls to the PhD Cell. The fix wasn't a shorter form. It was questioning whether a whole account type needed to exist at all.
- Role
- Senior Product & UX/UI Designer — end to end: research, architecture, interaction, rollout
- Timeframe
- 2025–26
- Context
- Digital India Corporation, under MeitY · ~350 institutions, ~2,500 scholars
- Team
- Design lead · 2 designers · 4 engineers · PhD Cell (client) · government integration teams
Some details are abstracted to respect government / NDA constraints; figures shown are approved for sharing. Ask for more in conversation.
Where onboarding ended up: a Head of Institute arrives with name, email and mobile already verified against the government's own records — no uploads, no queue. The Government of India accessibility toolbar across the top is standard, not an afterthought.
Shipped, 2026A system can be complete and still fail everyone it was built for.
The system worked. People didn't.
The portal had every box the administration could think of, faithfully turned into a form. On paper it worked. In practice two of every three institutions got stuck partway through signing up, and only finished after calling the PhD Cell — often more than once. I was brought in to make onboarding less painful. After a few weeks with the people inside it, I argued that most of it shouldn't exist.
The scheme is national but deliberately small — around 350 institutions, roughly 2,500 scholars, seats capped by policy. That scarcity raised the stakes. An institution couldn't shop around: it onboarded here or not at all. So a stalled sign-up couldn't be shrugged off as a lost sale. It was an eligible institution stuck at the door of a programme it qualified for, while a support team spent its days unblocking people one call at a time.
“We didn't get stuck on the form. We finished it, then waited weeks for verification — and ended up calling the PhD Cell just to find out if we were even in the system.”
The pain had two shapes: waiting and repeating. Verification depended on government offices that move on their own clock, so institutions sat for weeks with no signal their application was still alive. And because the portal asked the same things of three separate identities, people did the same work over and over before the waiting even began.
- 0167% of institutions got stuck partway through onboarding and needed the PhD Cell to finish.
- 02Median time from sign-up to an active account: ~3 weeks, almost all of it waiting on manual verification.
- 03~3 in 4 institutions contacted the PhD Cell at least once before they finished.
- 04The most common support question was never “how do I fill this in?” — it was “has my verification gone through yet?”
Three doors to the same room.
On paper the portal asked for three identities — an Institute Account, a Head of Institute, and a Nodal Officer. In practice all three led through almost the same steps: verify an email, verify a phone, upload documents, wait for a human. Only then could the institution upload its AICTE and NAAC certificates — and wait again.
You can't streamline your way out of a structure that shouldn't exist.
The fix everyone wanted was the wrong one.
The first instinct in the room was always “make the form shorter.”
- Cut fields
Quick to ship — but length wasn't the blocker, and it wouldn't touch the three-week wait.
- Parallelise the three verifications
Still three identities, still a manual queue. A faster version of the wrong thing.
- Add a status tracker
So institutions could watch verification crawl forward.
- A tracker only treats the symptom. Nobody should have to watch a three-week wait; the wait shouldn't exist.
- Every option that kept the Institute Account kept the duplication alive.
- The leverage wasn't in the screens. It was in the architecture beneath them.
An institute is not a user. It can't sign, verify, or be accountable — only people can.
Everyone treated the Institute Account as fixed — the thing the rest hung off. But an institution can't authenticate an email or stand behind a decision; only the people running it can. The account spun up a full registration journey and produced nothing the Head and Nodal Officer didn't already provide. So I stopped trying to streamline it. I proposed deleting it.
The answer was already in the room: the Head signs up on the institution's official domain, and AICTE confirms the institution against its own records. No standalone account had been doing that work.
Dropping the account doesn't drop the data. With the developers I mapped each institution to its Head and Nodal Officer in a backend dashboard, so the count came straight from the records.
I laid the journey map and the support-call log side by side to make the case — but what actually won them was that the change was lower-risk than it sounded. It applied only to institutions onboarding for the first time: no existing record migrated, nothing live put at risk. A deletion that sounded drastic reached only what hadn't been built yet — and we agreed to pressure-test it with real institutions before committing.
- Create institute accountredundant entity
- Verify email, phone, documents
- Head of Institute repeats itidentity two
- Nodal Officer repeats itidentity three
- Upload AICTE / NAAC certificates
- Wait for verification~3 weeks
- Start application
Seven steps, most of them the same verification done three times over — for one identity that existed only because the database had an “institute” table. The longest wait happened before anyone had seen a single benefit.
67% stuck without help
What I chose not to build.
- 01Remove an entity before redesigning its screens.
- 02Move every check as early as it can possibly go.
- 03Let a trusted system verify, so a person doesn't have to.
- 04Never ask for the same thing twice.
- 05Design around who's responsible — not around database tables.
Collapsing three identities into one.
The new journey starts with the only actor who can carry responsibility: the Head of Institute. They sign up, the institution is verified, and they invite their Nodal Officer.
- Three identities, near-identical onboarding
- ~3 weeks waiting on manual verification
- A support call to finish
- One verified authority — the Head of Institute
- An active account in minutes, no human in the loop
- No call needed
It was cleaner on paper than in the room. Walking it through with the PhD Cell and the first institutions to test it, a real worry surfaced: what happens when a Head of Institute leaves? Hanging everything on one person felt fragile to institutions used to roles changing hands. So the model grew a handover path — a Head can reassign authority, and the Nodal Officer holds continuity in between and can add a new Head at a later stage. The reframe survived; the design got sturdier because the people who'd live in it pushed back.
Designing the wait out of existence.
Weeks of waiting wasn't a design problem — it was a trust problem. The portal didn't need a person to approve a scanned PDF if it could ask the system of record directly. I'd seen DigiLocker do exactly this on a Department of Public Enterprises portal, and it was already live on other Digital India Corporation projects — so rather than invent a verification flow, I pushed to bring that proven pattern here. With the platform's engineers and the government integration teams, we moved verification onto DigiLocker: after verifying their email, a Head authenticates once and identity is confirmed in seconds, pulled from the source of record instead of a queue.
Eligibility moved next. Instead of letting institutions sign up and discover weeks later that they didn't qualify, we wired AICTE and NAAC checks straight into onboarding. Eligible institutions continued immediately; ineligible ones never entered the system at all. This took negotiation — eligibility is policy, so the integration teams and I had to agree what could be auto-trusted versus flagged for a human to confirm.
Even the institution's name was a trap: a free-text field meant typos, duplicates, and records nobody downstream could trust. I replaced it with search-and-select backed by AICTE data. And with the Head verified, adding the Nodal Officer collapsed to a single email — invitation, SMS and a DigiLocker link — with no setup step repeated.
Built and tested with the people who'd live in it.
- Two designers and four engineersThe team I led, from research through rollout.
- PhD Cell administrators (client team)Daily collaboration; owners of the process and the support load.
- Platform engineering & government integrationDigiLocker, AICTE and NAAC feasibility and rollout.
- Participating institutionsA dozen in discovery, five in testing — the handover path came straight from their feedback.
Public infrastructure doesn't get to design for the average user, so I built and tested against the hardest cases first — low-end devices, slow connections, assistive technology — and treated whatever broke there as the brief, not an edge case. The most useful round was the smallest: walking the new flow with five institutions and three administrators caught two things the mockups hid — the handover gap, and that verification was now so fast people didn't believe it had worked, so we added an unmistakable “you're verified” confirmation.
Removing the reason to call was half the job. The other half was giving institutions somewhere to go when they did need help — instead of the phone queue that used to end at the PhD Cell. So support moved into the product: raise a ticket, watch it get routed and staged, see it resolved.
What actually changed.
The biggest improvement was never visual. It was architectural — and the numbers followed. Stalled sign-ups and timing from the portal's own analytics; call volume from the PhD Cell's records, filtered to onboarding queries, measured before vs. after rollout.
And one number that never made the dashboard: the PhD Cell got its days back.
What this taught me.
The instinct on a project like this is to start moving fields around. The real work was upstream — asking whether one of the three accounts had any reason to exist. The best thing I designed here was a deletion.
It changed how I open every project since. Before I touch a screen, I ask what the system is forcing people to do that it should never have asked — and who needs to be in the room for the answer to hold. In systems this tangled, the strongest move is usually subtraction. The hard part is never seeing it. It's having the evidence, and the relationships, to make the case.
Figures come from the portal's own analytics (stalled sign-ups and onboarding time) and the PhD Cell's call records filtered for onboarding queries. Some details are abstracted to respect government confidentiality. Happy to go deeper in conversation.