Team
Nandini Inani ( thats me ;) ) Fariya Hasan . Deshna Deora
Role
Research · UX/UI · System Design
Duration
1 month
Tools & Technologies
Figma
Fusion 360
Arduino
WHERE IT ALL BEGAN
Mumbai’s monsoons are familiar — waterlogged streets, overflowing drains and infrastructure struggling to keep up. But when something goes wrong beneath the surface, we often notice it only once the problem has already reached the street.
And that’s where I started looking closer.
Mumbai’s identified flooding spots have grown more than twelvefold since 2014.
Reporting of infrastructure problems still relies heavily on people noticing and flagging them before action can begin.
Mapping the system
Mumbai’s monsoons are familiar — waterlogged streets, overflowing drains and infrastructure struggling to keep up. But when something goes wrong beneath the surface, we often notice it only once the problem has already reached the street.
And that’s where I started looking closer.
Breaking down the process — tracing where the system falls short.
Field Study
We conducted field studies across Santa Cruz East and Bandra East, then zoomed into frequent flooding spots in Vile Parle East. These often occurred at junctions where multiple sewer lines converge.
Key gaps
The system is reactive, with action often beginning only after flooding or overflow becomes visible.
Before inspection, there is limited visibility into what is happening underground.
Workers may enter sewerage systems without knowing the conditions they will encounter inside.
Findings and progress rely heavily on manual communication with BMC.
With fragmented updates and paperwork, progress and accountability are difficult to track.
Problem Statement
Introducing DrainGuard
From a reactive system to a connected one.
DrainGuard is a connected sewage monitoring system that enables earlier issue detection, safer field inspections, and smoother communication between workers, supervisors, and BMC.
What shipped
60+ components across 8 categories — forms, navigation, data display, feedback, overlays, layout, typography, and actions.
Every component was documented in Storybook with live examples, prop tables, and usage guidelines written for engineers — not designers.
The thing that made adoption fast wasn't the quality of the components — it was the documentation.
Engineers didn't have to ask questions because the answers were already there. The system went live to the first team in week 14. By week 16 all four product teams had migrated their active sprints onto the new components.
What worked
Auditing before designing saved weeks of rework. Building tokens first made everything downstream faster. Writing documentation as I built — not after — meant the team could adopt it immediately.
What I'd Do Differently
Involve engineers earlier in token naming — had to rename variables later. Ship a smaller v1 faster instead of covering every edge case before launch.
// Other works
Have a look at my other work
Aarambh
1 month
2025
In India, there’s always something to celebrate. So why is finding the right setup a hassle? Aarambh makes last-minute celebrations easier, quicker and more accessible.
Service Design · UI/UX · Interaction Design
Frontend + designer
The Office Hours
1 month
2025
What happens when “I’ll do it later” becomes a habit? Designed a board game for ages 7–15 that explores procrastination through playful choices and consequences.
Behavioural Design · Game Design · Experience Design
Design engineer