ResolveNow is a citizen complaint platform for Indian municipalities. The interesting question wasn't "how do we let citizens raise tickets" — it was why citizens had stopped raising them in the first place, and what the design could do to repair that loop.
Every Indian city has a complaint helpline, a website, or a half-shipped municipal app. People still call relatives in the corporation. People still pay extra to get sewage cleared. People still give up.
The failure isn't that complaint forms don't exist. It's that the system around the form — who gets the complaint, who's accountable, whether anything happens next — is opaque to the citizen and ungoverned on the inside. So citizens learn that raising an issue costs effort and returns nothing, and they stop.
A digital form on top of an unaccountable system just makes the failure faster.
The design problem isn't "how do citizens complain." It's "how does a system earn the right to be complained to."
Before scoping a product, I needed to understand the surface — what citizens actually face — and what's underneath it. The starting map plotted the visible failures (water shortage, traffic congestion, road maintenance, electricity, pollution, education) against the underlying issues people had only hinted at: laid-back attitudes, funding gaps, socio-economic bias, lack of information among citizens, and a transparency vacuum.
The Municipal Corporation of Delhi context grounded this. MCD covers ~1,397 km² and serves ~32 million people across three sub-municipalities. Only 11.8% of property tax was deposited online — meaning even the paying side of the citizen relationship was still mostly offline. If that's the baseline, complaint-raising is even further behind.
To get past surface complaints into the structural failure, I ran the same problem through multiple research instruments — each one designed to reveal a different layer.
Two mind maps scoped the question. The first asked who is raising tickets, what are the problems, what advantages does a system give, why is it needed. The second pulled out the harder strands: socio-economic background, escalation paths, payment systems, e-governance in India, and the transparency of the system itself.
Then four lenses pointed at people:
This is the moment the research landed. Synthesising the interviews and focus groups produced two parallel walls of findings.
Citizens described an unaccountable system from the outside. Officials described an undocumented system from the inside. Both descriptions point at the same hole — there is no shared, transparent record of what's been raised and what's been done about it.
The empathy maps surfaced something the demographic data couldn't.
The pattern: a 28-year age gap, a 12-lakh income gap, and very different relationships to digital tools — but identical emotional states. Anxious. Confused. Dissatisfied. The system fails the same way at both ends.
A complaint app could address the top of the pyramid. The strategic move was to design something that could reach down a few levels.
The causal loop diagram mapped these forces against each other. The reinforcing loops are the dangerous part: laid-back attitude + no accountability + people stop raising issues + funds get misallocated → more civic issues → more laid-back attitude. Once a citizen drops out of the system, they don't return.
The system map lays out the full cast: citizens, devices, kiosks, app notifications, mail/messages, the central database, municipality, supervisors/surveyors, zonal officials, respective officials, zonal offices, targeted departments, and the workman/team on the ground. The complaint-registering core (the yellow centre) is small. What surrounds it isn't.
The service blueprint made the implications concrete:
The IA was deliberately conservative. After Log-in/Sign Up → Home, the user has six places to go:
The low-fidelity wireframes tested this hierarchy before any visual design happened — putting Raise / Track / Profile / Auth side-by-side to confirm that the "Raise a complaint" affordance felt obvious from the home screen, but that tracking and ward identification surrounded it rather than getting buried.
The high-fidelity flows shipped against the four mental-model beliefs identified earlier. Each design decision below maps back to a specific finding.
A ward-finder lets the citizen identify their ward by state → city → block, by pincode, or by device location. The ward list then exposes Ward Name, Cluster, and Zone for every locality in the city. The mental-model effect: the citizen no longer needs a relative in the corporation to know who's responsible for their street.
The Raise a Complaint form captures: who the complaint is raised for, type of complaint (electricity, water, sewage, street issues, pollution), contact number, address with map-pin, and a save-as-draft option for citizens who can't complete in one sitting. Every complaint receives a ticket number, time-stamped and routed by department — the documentation gap the BESCOM engineer flagged as the system's biggest internal failure.
The track screen is the most important behavioural lever in the product. By giving the citizen a persistent, queryable record of every ticket they've ever raised — open, closed, abandoned — it converts the system from a black box into a ledger. The mental-model effect: the citizen no longer has to trust the system in the abstract; they can audit it.
Two complementary surfaces. The ward officer directory exposes the relevant area head and department leads — making accountability nameable, not theoretical. The emergency contacts surface gives urgent issues (electrical hazard, sewer overflow) a direct path that bypasses the standard queue.
The home screen leads with the user's open complaints (e.g., No Electricity – Wire Cutoff, Street Lights Issue, Water Issue), not with a marketing banner. The product respects that a citizen opens the app because something is wrong — and tells them what's already in progress before asking them to file another.
A few things I took away from this work.
Running interviews + diary studies + empathy maps + mental model + causal loop + system map + service blueprint isn't a methods checklist — each method points at a different depth of the problem. The mental model and the causal loop diagram are the ones that changed the brief. Without them, the product would have been "a better form." With them, the product became "a ledger and an accountability map that also has a form."
The most uncomfortable finding — that priorities are fixed from higher-ups and that frontline officials have no real authority — only came out of the interview with the BESCOM engineer. If the research had stayed on the citizen side, the design would have over-indexed on raising complaints and under-indexed on documentation, routing, and visible accountability.
The same feature has to work for a retired government official who finds mobile apps "not user-friendly" and a data analyst who is fluent in tracking dashboards. That constraint pushed the IA toward fewer top-level destinations, larger touch targets, persistent ticket records, and a home screen that leads with status rather than promotion.
You can ship a beautiful complaint flow into a system that ignores it. The interesting brief — and the one I tried to design against — is whether a product can change what a citizen believes about whether raising a concern is worth their time. That's a longer arc than this case study can prove. But the design moves above are an attempt at the first move in that arc.