Case Study 03/04

Varanasi Smart City.

The operator and intelligence layer of a city-scale Integrated Command and Control Centre: the many systems that keep a city of millions safe and running, surveillance, traffic, lighting, waste, environment, public messaging, citizen response, unified into one platform run from a single room. Still in production six years on.

Business challenge
Unify the many systems that keep a city of millions safe and running, each with its own devices, alerts, and workflows, into one command centre that operators across the city's departments could run under pressure, with minimal training, on government timelines.
My authority
The only UX designer on the project, across every module. I set the system direction the build followed, system logic, information architecture, wireframes, prototypes, production screens, and held it consistent by working across the development, testing, and delivery teams running in parallel.
Scale
The city's systems run from one command centre: 2,500+ cameras across 720+ locations, 10,000 street lights across 27 wards, 43 to 45 GPS-tracked waste vehicles, 15 environmental stations, plus traffic, public messaging, and a citizen app.
Outcome
Six years on, still in production, with Intellve on annual maintenance. 87%+ alert-detection accuracy. The architecture became the template for the company's next smart-city build, Dholera, at a fraction of the design investment.
More context Collapse context
My role UI/UX Designer → Senior UI/UX Designer · the only UX designer across all the city's modules · system logic, information architecture, wireframes, prototypes, production screens, cross-module integration, SOP design, and direct client interaction.
Team I owned the UX and design across every module. A graphic designer and a front-end developer, both of whom I made the case to hire and onboarded during Varanasi, contributed as it progressed, rotating across the company's other products at the same time, while development, QA, and delivery ran a parallel pipeline.
Stakeholders The Varanasi Smart City client team · the system-integration partner Intellve delivered the software through · Intellve leadership and the internal project and delivery team.
Duration Roughly 10 to 12 months to design and deliver the modules, then about a year of iterations and tender-interpretation corrections · staggered, pipelined delivery · still maintained in production.
The program A national Smart City Mission program for Varanasi, valued in the hundreds of crores. Intellve delivered the software and the operator platform across the city's systems, published as the only platform in India offering multi-touch interaction with data objects.
What carried forward The dual-view architecture, SOP-guided alert workflows, and cross-module integration became the foundation for Dholera and the company's later multi-site deployments.
Overview

A city of millions. One operator surface.

The Kashi Integrated Command and Control Centre runs Varanasi, a city of millions and one of the oldest living cities on earth, from a single room: a 24/7 government facility built around a 10.8 by 2.6 metre video wall and 25 operator desks. From here the city's own teams watch and act on surveillance, traffic, street lighting, waste collection, air quality, public messaging, many separate systems, each with its own devices and alerts, brought onto one surface.

I was the only UX designer on the programme, across every system, and I set the system direction every module was built on, before most of the screens existed. The hard part was never one system; it was operator cognition. No one can hold a dozen systems, each with its own alerts and workflows, in working memory at once. So the platform was designed around one consistent way to see and to act, the same wherever an operator looked, so someone trained on one system could run any other without retraining. The command centre was inaugurated by the Prime Minister in February 2019 and has run continuously since.

Executive Summary
I set the architecture every city-scale module was built on, before most screens existed: every system on one consistent surface, so a single operator could run any of them. Still in production six years on.
The Kashi Integrated Command and Control Centre in operation, the Intellve platform on the video wall
The Kashi Integrated Command and Control Centre in operation: the Intellve platform on the video wall, the city's live map and consolidated alerts from across the modules driving day-to-day decisions.
Built for the city to run itself

The photo is the platform in everyday use: the city's own operators working a live map and consolidated alerts from every module, from one room. The design goal was exactly that, an interface non-specialists could run under pressure, without the vendor in the room.

The major modules

Many systems. One operating model.

These seven were the major modules that ran the city's daily operations, each a complete system of its own. The platform did more besides, a citizen app, a help desk, COVID-19 management, the analytics dashboard, but these seven were the operational core.

Every module is built on the same two-view structure: a searchable table of every device and its state, and the same data on a live city map. An operator who learns one module can run any other, with no new interface to absorb. That shared structure is what allowed a single operator to move across the entire city.

Module 01

Surveillance

City-wide CCTV across ghats, markets, junctions, and strategic points, feeding live and recorded video into the command centre.

2,500+ cameras, 720+ locations
Module 02

ITMS

Signal control, automatic number-plate recognition, e-challan violation tickets, and priority green corridors for VIP convoys and emergency vehicles.

ANPR + e-challan + priority routing
Module 03

Solid Waste

GPS-tracked collection vehicles on geo-fenced routes, smart-bin fill monitoring, and route-compliance reporting citywide.

43–45 tracked vehicles
Module 04

Environmental

Live air quality, weather, and pollution telemetry streamed from monitoring stations across the city.

15 monitoring stations
Module 05

Smart Lighting

Adaptive LED street lighting with remote intensity control, fault detection, and energy telemetry across every ward.

10,000 LEDs, 27 wards
Module 06

Variable Message Displays

Electronic boards pushing public advisories, traffic and safety alerts, and civic messaging across the city.

live public advisories
Module 07

Public Address

Networked speakers at ghats, markets, and public squares for emergency announcements and zoned civic broadcasts.

zoned citywide broadcast
A recreation of the operator interface, split into the table view and the map view of the solid waste module: a searchable bin status table on the left, the same bins on a live city map on the right, with one overflowing bin selected in both.
The operator interface, recreated: the same module read as a table and as a map.
Two views, every module

Each module monitored something different, with its own devices and alerts. The judgment was to refuse a bespoke design for any of them and give every one the same two views: a searchable table for detail, the same data on a live map for context. The system behind the screen changed; the way an operator read it never did.

Key decisions

Three decisions, one platform.

The three calls that shaped how the platform was built, used, and trusted: the traffic corridor, the waste model, and the citizen channel.

Key decisions 01

The one-junction traffic challenge.

The ITMS requirement was specific: when a camera flags congestion at a junction, show the operator that junction's feed. Reviewing it myself, the way I work through anything I design, one question kept surfacing: what happens after the operator sees the jam and turns the signal green? If the next junction is already backed up, turning this one green clears nothing; it pushes the congestion one junction forward.

So a single junction's feed was the wrong unit. The fix was a corridor view: when an alert opens, the system shows five junctions in context automatically, the triggered one, two ahead, two behind, so the operator sees the consequence of an action before taking it. Parallel and intersecting roads stay one click away on the map but do not auto-open: enough context to make a system-level decision, not so much that the decision gets harder. For VIP convoys and emergency vehicles, the same corridor follows the pre-configured route.

The corridor view: one alert opens five junctions in context, the triggered junction plus two ahead and two behind
The corridor view: one congestion alert opens the triggered junction plus the two ahead and two behind, so the operator reads the whole corridor before acting.
Five, not every camera

Every nearby camera could have opened on the alert. Showing them all would have buried the operator. Choosing exactly five, the triggered junction and two each side, was the design judgment: enough to see the whole corridor, little enough to still decide.

Key decisions 02

Waste collection sensor problem.

The original plan was fully sensor-driven: fill-level sensors on every bin, each triggering a dispatch alert. The technology worked; the behaviour it assumed did not. Sensor-only dispatch would have left drivers idling until an alert came, clustered hundreds of alerts at the end of the day as crews went home, and left no one a fixed route to answer for. No interface fixes that. It is a workforce-incentive problem, not a screen problem.

In discussions with the Smart City authorities I argued exactly that, and proposed a hybrid: fixed daily routes as the accountability baseline, with sensor alerts kept only for the exceptions, overflow between scheduled runs. The routes made the workforce accountable; the sensors caught what the routes missed. That became the model the city ran on.

Systems thinking signal
The sensor failure that forced a rethink was turned into a better model. Constraints imposed by the real world produced a more durable solution than the original sensor-dependent design. The system that started with sensors became more accurate without them.
Waste collection in three models: sensor-only rejected, hybrid of fixed routes plus exception alerts adopted, and data-driven prediction after the sensors failed
One problem, three models: sensor-only (rejected), the hybrid of fixed daily routes plus exception alerts (adopted), and the data-driven prediction that replaced the sensors after they failed (evolved).
The workers became the sensors

When the hardware failed, the fill-level logs crews already entered through the field app, with the historical record, fed the prediction model. The data the work produced replaced the sensors it was meant to capture.

Key decisions 03

Citizen's app no login, by design.

Residents needed a direct line to the command centre for civic emergencies: burst water pipes, flooding, garbage overflow, road damage. The most consequential decision for the citizen app was one of the first: no login, no registration, no account to raise a complaint. The people most likely to open it are in the middle of something going wrong, the exact moment when patience for forms and passwords is lowest.

So the flow is built for someone who may not type well, may not read easily, or simply has no time. Enter a mobile number, attach a photo or video of the problem, then either type a short note with the location or just record a voice note and send. Voice was expected to be the primary method for a large share of residents, not a fallback, and both Hindi and English were supported from launch.

The app passes the phone's location to the operator automatically, so even when a citizen types nothing at all, the operator can place the spot from the location and the attached media and dispatch a team that finds it without a follow-up call. Checking back is just as light: open complaint status, enter the same number, verify by OTP, and see every complaint from that number with where it stands.

The citizen complaint flow: no login, attach photo or video, type a note or record a voice note, location sent automatically to the operator who dispatches a field team
The citizen complaint flow: no login, a photo or video, then a typed note or a voice note, with the location sent automatically so the operator can place the spot and dispatch a team.
Voice, not as a fallback

For a resident who cannot type easily, or has no time, a voice note replaces the form entirely. It was planned as the primary way a large share of people would report, not an accessibility extra bolted on.

The integration layer

The city as one system.

The design decision was how

The city required these systems to work together; the design decision was how.

Every alert, from any module, opens in one panel: the details, the relevant camera feeds, and quick-action buttons for the systems it touches, with nothing to navigate away to.

A crowd-gathering alert from surveillance opens the camera feed, a public-address broadcast button, and the local environmental readings, in one window, mid-incident.

Surveillance cameras link to street-light locations to verify a reported failure; environmental readings feed the public display boards; a traffic-congestion alert pushes a warning to the boards upstream of the affected junction. An incident in a city does not stay inside one system's boundary, so the operator's response was designed not to either.

Constraints

The realities the brief didn't name.

Tender interpretation

Government tenders are written in broad language, and what was specified diverged from what was operationally expected in places.

That surfaced as a correction cycle in the year after delivery. Earlier, more frequent client alignment would have caught most of it before it shipped.

The dual-system transition

At go-live, the city's old methods, radio, phone dispatch, paper schedules, kept running alongside the platform through training, leaving operators unsure which was authoritative.

A structured, per-module deactivation timeline would have shortened that ambiguity instead of letting it resolve itself.

The documentation gap of government work

The administration never disclosed which incidents the platform resolved, so specific outcomes couldn't be published, even where press and police records showed its role.

The impact was real; the proof stayed with the client. In government work, you design knowing you may never be allowed to show your own results.

Impact

Still live, six years on.

6+ yrs
In live production
Still running and maintained by Intellve under annual maintenance, six years on and across changes of city administration.
87 %+
Alert-detection accuracy
At or near industry-best for real-world video analytics at this scale, with false-positive triage built into the operator workflow.
2,500 +
Cameras
Across 720+ locations: ghats, junctions, markets, and strategic points citywide.
10,000
Street lights
Adaptive LED lighting under remote control across all 27 wards.
43–45
Collection vehicles
GPS-tracked, on geo-fenced daily routes with exception-based alerts.
15
Environmental stations
Air-quality, weather, and pollution telemetry across the city.

Why it's still running

A smart city is engineered in deliberate layers.

From the UX layer operators work in, down through development, integration, and the hardware beneath. One operating model across every system meant operators trained once, and the knowledge lived in the platform, not in the people, which is what outlasts staff turnover and changes of administration.

Leadership signal

Built to outlast the people who run it.

What designing a national-scale system demanded of me as a leader, not only as a designer.

I built one operating model, not a screen per system.

Resisting a bespoke design for every module was the leadership call: harder upfront, decisive long-term. Operators learned one way to work, and the architecture held for six years.

I designed for tenure change, not launch day.

Operators and administrations turn over. The platform was built so the knowledge lived in the system, not the people, which is why a handover never reset it to zero.

I built patterns the company reused.

The dual-view architecture and operator workflows became the company standard, and Dholera, the next national smart city, was built on them at a fraction of the investment. The work outlived its project.

Read all twelve principles How I lead