Usable citizen service platforms
Severe usability and accessibility barriers on Indian eGovernance portals
A lightweight browser extension for rapid prototyping with preset design interventions
-> UI/UX researcher and designer
-> Full-stack developer
-> Capstone project, advised by Prof. Sudheendra Hangal
-> 4 months
In a rush?
Skip ahead to ->
Research
Indian eGovernance has become notoriously known for practically unusable and unmaintained portals.
Usability concerns are overlooked because of time/resource constraints, and a propensity to share as much information as possible.
Additionally, there is a large gap in digital literacy and access to high-end technology across the country.
The 2015 “Digital India” campaign and a recent slip in the E-Government Development Index (EDI) rankings make this a critical time to take action.
+73
To understand the scope of usability issues, I designed a survey catered towards Indian citizens in the 18-60 years old bracket. This was a consciously broad sample because eGov portals are used by most adult citizens.
76 respondents were asked:
to select their most frequently used eGov portals
to describe their experiences on the same
to suggest fixes or feature requests
about their browser extension preferences
Access the form here
The survey illuminated how IRCTC might be an ideal choice for a case study as many feature requests and complaints were specific to the site. For context: IRCTC is a train booking service owned by GoI and used by millions. Thus, I tried to experientially gauge the critical issues associated with a foundational user flow on the site — purchasing a ticket.
Pulling together results from the user survey and my case study, I noticed a thread of common errors reported across eGov portals. At this point, I had to pick between 2 directions moving forward:
1) Statically redesign the most problematic portal (IRCTC) and provide a wide range of design consultancy
2) Create a dynamic redesign system based on a limited but recurrent set of issues
This would also determine the nature and degree of a user's interaction with the final product.
I picked 2) with the hopes of maximising utility through flexibility and an open-source framework, just as Dr. Narasimhan advised.
->
This shifted my target audience from the general public to web developers and portal users that have basic HTML/CSS knowledge.
I mapped each issue category to a design intervention that would mitigate it.
This formed a rough set of task flows and expected interaction (create, update, delete).
To successfully implement a dynamic redesign system, the product requirements would be as follows:
Direct access to web content: need to interact with the Document Object Model (DOM) and modify the interface without backend access
Lightweight and focused functionality: should take up minimal system resources and solve for eGov-specific issues
Usable by a broad audience: platform-independent and flexible usage for developers and casual testers
Ease of distribution and improvement: lower the barrier for adoption and allow for participatory design
A browser extension is the best-fit solution that matches these requirements. Explored alternatives include stand-alone web or desktop applications and Bookmarklets.
Clicking the browser extension icon opens a popup where users can specify changes to the webpage, like selecting elements or entering identifiers (e.g., ID, class).
The extension sends these instructions to a background script, which communicates with a content script running directly on the webpage.
The content script modifies the webpage’s structure (DOM) based on the user’s input, applying the requested changes. The browser then displays the updated webpage instantly, showing the edits made by the user.
The content script also informs the extension about the changes, keeping track of the current webpage setup for future adjustments.
Main screen (closed)
Proto
Flow
towards India eGov
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Expand feature to specify and apply desired adjustments
Quick access to critical functions: refresh and power off
Call-to-action to get involved in the design of Protoflow
Feature-specific information that opens in an overlay
Link to Protoflow’s documentation and user manual
Landing screen instructions
Accordion menu layout to reduce visual clutter
Proto
Flow
towards India eGov
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Parameter 1
Parameter 2
Parameter 3
Call-to-action to apply requested feature
Minimise feature when desired adjustments are applied
Feature-specific parameters
Main screen (open)
Help overlay
Feature 5
Parameter 1
Parameter 2
Parameter 3
Information on each parameter and its effect on adjustments
I conducted a small-scale usability test with 3 developers (college and entry-level experience) to pinpoint initial usability issues before the initial roll-out. The following feedback was raised and implemented in a second iteration of the prototype:
Participatory design feature was hidden away
-> Changed 'Contact' button to 'Contribute' button and added emphasis styling
Intervention 'Apply' button was sometimes contradictory and confusing
-> Changed universal 'Apply' button to feature-specific action button
Unclear when to use each design intervention
-> Added a 'Usage' section in the help overlay with exemplar use case
I conducted summative testing in 2 ways:
First, an internal test to apply Protoflow to the IRCTC case and evaluate how minor changes can improve overall experience and performance. This resulted in quicker loading speeds and task flows (numbers below).
The second phase investigated satisfaction and likelihood of adoption by the developer community. For this I reached out to personal developer circles for a quick run-through of the plugin. Then, I floated an NPS survey which resulted in an impressive 83 score. Junior developers were keen to collaborate on the project as well.
Numbers
Decrease in loading speed, closer to the 2-3 second benchmark
Quicker navigation of the ticket booking flow:
3:47 minutes
NPS score with 15+ respondents
This project allowed me to understand and implement a traditional HCI research cycle. I started with defining a problem statement and then supplementing it with user research. Here, I understood the importance of context and regional research, as India’s political and economic background played a significant role in my design choices.
During development, I went through multiple rounds of ideation and sourced an expansive list of enhancements but it was crucial to cover the bases first. Instead of attempting to introduce fancy features, I tried to first ensure that fundamental usability requirements, such as removing and restyling elements, were satisfied.
-> Including developer input: While my research extensively logged the requirements of standard portal users, it left out a major stakeholder – front-end developers. By including their insights, this tool can be made better suited to a development environment.
-> More focus on optimisation: Currently, the tool prioritises usability over optimisation. However, by implementing optimisation features, we can resolve more technical user pain points such as loading time and the lack of local storage, which eventually contribute positively to usability.
-> Extend the use-case: In addition to a live prototyping tool, this can act as a robust feature suggestion pipeline, especially for the GoI. For example, automatically converting modifications into a comprehensive proposal report.
Protoflow
by Nishtha Das