Indian Government Websites Don't Just Have a Design Problem. They Have a Structure Problem.

ಪ್ರತಿ ಅರ್ಜಿಯ ಹಿಂದೆಯೂ ಒಂದು ಆಸೆ ಇರುತ್ತದೆ, ಅದನ್ನು ಸುಲಭ ಮಾಡುವುದೇ ನಮ್ಮ ಕೆಲಸ. — Behind every application is a hope. Making that easier is the work worth doing.

A friend was filling out a teacher recruitment form on their phone last night. I watched them scroll sideways to read a form label. Then scroll sideways again to find the submit button. What struck me wasn't that this one site was broken — it's that I could've predicted roughly how it would break before I even opened it, because I've seen similar patterns on other government sites too.

Published: August 30, 2026 · 11 min read · By Veeresh Bashetti

This Isn't Just a Frontend Problem, and It's Not Only One Website

It's easy to screenshot a bad government form and call it a one-off, or file it under "the frontend needs work." I don't think either framing quite captures what's actually going on. This post is centered on one real, currently-live portal, examined closely — Karnataka's PST/PE-Grade-II/GPT/AM/PE-Grade-I Teachers Recruitment portal at sts.karnataka.gov.in. I'm not claiming to have audited other government sites with the same rigor. What I can say is that the shape of what shows up here — a site that clearly works, was clearly built by capable developers, and still has very little structure holding it together — is one I've recognized, in outline, on other Indian government portals I've used casually as a citizen. That's an impression, not a survey, and I want to be upfront about the difference.

The layout issues are the easiest thing to screenshot, so that's usually what critiques like this focus on. But the case study below points at something a layer deeper too: what I can observe as an applicant suggests the problem isn't contained to CSS and responsive breakpoints alone.

Case Study: Karnataka's Teacher Recruitment Portal

This is where applicants across the state fill in personal details, education history, TET scores, post preferences, and eventually pay and submit. It's a real, live application form — not a demo. Applicants across Karnataka are using this portal to apply for these teaching posts.

Layer One: The Layout

On a laptop, the form technically works. You can tab through Personal Details → Reservation → Education → Professional Education → TET → Post → Photo & Sign → Declaration → Preview → Payment → Print. Bilingual labels (Kannada and English) are stacked in every field, which is genuinely useful for accessibility — that part deserves credit.

But even here, the cracks show. The tab bar itself needs a horizontal scrollbar just to see every step — on a desktop monitor. That's usually a sign the layout was built to a fixed pixel width rather than to the available space.

On a phone, the layout doesn't meaningfully reflow for a phone-sized viewport. The page renders at what looks like its full desktop width, just squeezed into a 6-inch screen. In my testing on a phone-sized viewport, applicants have to scroll both vertically and horizontally to read a single form section. Tab labels get cut in half — "Bachelor Degree" becomes an unreadable fragment unless you scroll sideways first. A registration button is visibly clipped down to "Regis." This is what I encountered when accessing the application on a phone-sized viewport, on the very first tab, on a government job application.

Layer Two: The Interaction Design

The subject dropdown is its own problem, separate from layout. Selecting an "Optional Subject" opens a plain, unstyled native <select> list — over twenty subjects long, from Chemistry to Bio Chemistry, no search box, no grouping, tiny click targets stacked one after another. If your hand isn't perfectly steady on a trackpad, you'll pick the wrong subject. On a form that determines your job eligibility, that's not a small thing.

Layer Three: How the Subject Fields Map (or Don't) to an NEP Qualification

Here's the part that made this personal for me rather than just a UX teardown: I applied through this same portal as an NEP-based student, and the subject-selection step didn't map cleanly to the structure of my qualification.

The form presents three separate "Optional Subjects" fields at the degree level. My NEP-based undergraduate programme, however, follows a different academic structure in which the relevant disciplines are organised as major/minor courses rather than simply three optional major subjects. Karnatak University Dharwad's NEP regulations describe students choosing two discipline-specific core subjects, with one becoming the Major and the other the Minor in later semesters — and the university's more recent regulations describe a further revised framework on top of that. The reality is more nuanced than "old system had three majors, NEP has two" — but what I can say directly is that the form's three-optional-subject structure doesn't clearly correspond to the way my own degree was organised.

That creates a practical problem when an application form built around one subject structure asks a current graduate to fit their qualification into fields that don't clearly correspond to how their degree was actually structured. When an application form presents three optional-subject fields but doesn't clearly provide a way to represent a major/minor structure, the issue moves beyond visual design — it becomes a question of whether the application's data model and validation rules accurately represent the qualifications applicants actually hold.

From the applicant's perspective, the result is the same either way: the form exposes assumptions that don't clearly map to the qualification structure I was working with. That suggests the system's data model, validation rules, or requirements specification may not have been fully revisited as academic structures changed — though I can only observe this from the frontend, not from the portal's actual backend logic, so I can't say for certain whether submission is technically blocked or just awkward to navigate. Either way, it's the same underlying pattern showing up one layer deeper than layout: a visual bug is annoying, but a form whose fields don't clearly represent your qualification could make it harder to accurately describe your own eligibility, or push an applicant toward guesswork under a payment deadline.

(A note on precision: the exact major/minor mechanics vary by university and have been revised more than once since NEP's rollout, so I'm describing the structure of my own programme specifically rather than asserting one fixed NEP-wide rule.)

Does This Extend Beyond One Portal? Here's What I Can and Can't Claim

I want to be careful here, because it's tempting to jump from "one well-documented case" to "this is everywhere." I haven't run the same close, screenshot-by-screenshot audit on other government portals that I ran on this one, so I can't present this as a verified nationwide finding.

What I can say honestly: if you've used more than one Indian government website, some version of this probably feels familiar — a residence certificate portal with a different visual style on every page, a utility payment site where the "back" button loses your half-filled form, a land-records lookup that only works if you already know exactly which format to type a survey number in. Those are casual, citizen-level impressions, not documented case studies, and I'd treat them that way until someone does the same close reading on those sites too.

So take the rest of this post as centered on the Karnataka portal specifically, with the broader claim held loosely: this looks like it could be a wider architecture-and-maintenance pattern rather than a single bad build, but the one case study here is the actual evidence — not proof of scale.

Why This Isn't Just "Ugly" — It's a Barrier

It's tempting to file this under "government websites look dated, lol" and move on. But a dated color palette, a broken layout, and a subject field that doesn't map to your qualification are different kinds of problems — and this portal carries more than one at once.

A dated color palette doesn't stop anyone from applying for a job. Horizontal scrolling on a form with a payment deadline can. A subject field that doesn't map to your actual curriculum can push you toward guessing under time pressure. That friction falls hardest on exactly the people least equipped to route around it: first-time applicants, people on older or budget phones, people applying from areas with patchy connectivity, and NEP-trained students encountering fields that weren't obviously built with their qualification structure in mind.

Good civic tech isn't a frontend nice-to-have. For a lot of applicants, this website is the government, for the ten minutes it takes to apply — and if any layer of it is broken, that's what they experience as "government."

What Would Actually Help

The problem doesn't necessarily require replacing the entire underlying application, on the Karnataka portal or on any of the others that share this pattern. In many cases, the existing applicant and eligibility data could potentially be extended with a more flexible representation of education structures and validation rules, rather than rebuilt from scratch. What seems to be missing is structure — and an update process — at more than one layer:

Frontend layer

• Responsive breakpoints, so layouts reflow to screen width instead of staying pinned to a desktop grid.
• A shared component library — one consistent set of inputs, buttons, and spacing rules reused across every form, tab, and department.
• Searchable dropdowns for long option lists, instead of plain native <select> menus with twenty-plus unstyled options.
• Progressive disclosure on mobile, and visible focus states and larger tap targets for real thumb use.

Data and validation layer

• Documented, owned validation rules and business logic, rather than logic that's written once and never revisited.
• A review trigger tied to policy changes — when curriculum or eligibility rules change (as they have under NEP), the systems depending on them could be flagged for review, rather than left as-is indefinitely.
• Data models flexible enough to represent more than one academic structure at a time during a transition, rather than assuming a single fixed shape.

Process layer

• A documented design and data system applied to new forms and portals as they're built, not just the one currently in front of a given team.
• Clearer ownership after launch — someone whose role includes checking whether the system's assumptions still match current policy.

None of this requires a rebuild from scratch. It's standard, well-understood engineering practice across the stack — the gap isn't skill at any one layer, it's that these systems don't appear to get built with structure or an update process from day one, so each new form ends up bolted on separately.

A Brief Note on Hiring

One more thought, briefly: government portals are typically delivered through procurement arrangements where functional requirements get more attention than long-term maintenance — a pattern discussed in GovTech circles generally, though I haven't verified it against this specific portal's contract. Whatever the arrangement here, the rules don't appear to have kept pace with the qualification structure I encountered.

Early-career developers, closer to changes like NEP and often more current on modern tooling, are one underused way to keep these systems from staying frozen after the policy underneath them moves on. Not the only fix — but a real one worth considering alongside better process.

Where I Actually Stand on This

I'll be straightforward about why I'm writing this. I've spent time building and documenting web projects on my own, working across the stack — the functionality has generally worked, but I've been the first to admit my own structure and consistency needed work, in the interface and underneath it. Looking at a live, high-traffic government system like the one in this case study made something click: the fix isn't more features, it's discipline, at every layer — a defined content and data structure, a component system, a process for updating things when the underlying rules change, and consistency applied everywhere, not just wherever I remembered to apply it that day.

If any state or municipal IT team, or a vendor building for one, is looking for people to help bring structure to public-facing systems — frontend, backend, or both — I'd genuinely like to be part of that, and I think there's a real case for governments bringing in more early-career developers for exactly this kind of work generally, not just on one project. Civic tech is exactly the kind of work where good structure, at every layer, has real, measurable impact on real people's day, not just a nicer Lighthouse score.

The Bigger Picture

This kind of gap isn't unique to Karnataka, or even to India — government portals in many countries tend to lag private-sector systems, often because procurement optimizes for "does it technically collect the required data" over "can someone actually use it, and does it still make sense" at any layer. That looks like a solvable, structural gap rather than an inevitability. It would benefit from a documented system — visual, data, and process — applied consistently across projects, a way of catching policy drift like the subject-structure mismatch I encountered before it complicates a real application, and people in the room during the build who are thinking about the applicant on a cracked-screen phone in patchy signal, not just the developer testing on a wide monitor with fast Wi-Fi and a requirements document from a few years back.

Cases like this are useful because they make otherwise invisible problems visible. The goal isn't to single out one department or developer. It's to ask whether the systems people depend on are being designed, maintained, and updated with the same discipline we expect from the policies and services they deliver.

This post reflects my own personal opinion and experience as an applicant, based on what I could observe from the frontend of one live portal. It isn't an audit, an official critique, or a verified account of any vendor's contract, backend logic, or procurement process — treat it as one developer's perspective, not a definitive claim about how these systems are built.

I'm also working on a before/after video showing an optimised version of this portal — I'll attach it here on YouTube once it's ready.

Written By

Veeresh Bashetti

PythonDjangoReactAI

Veeresh Bashetti is a Python Full Stack Developer who writes practical tutorials about Python, Django, React, AI, productivity, and software development based on hands-on experience.