Case study

Aquinto: IoT Water Management Application

Product Design

IoT

Design Systems

Low-Literacy

Mobile

Overview

Overview

Aquinto is a mobile application engineered to bring remote visibility, automated control, and actionable analytics to physical water storage infrastructure that have an overhead and sump setup.

Aquinto is a mobile application engineered to bring remote visibility, automated control, and actionable analytics to physical water storage infrastructure that have an overhead and sump setup.

Role

Role

As the sole designer I led every design decision on the product and worked closely with development, product, and leadership.

As the sole designer I led every design decision on the product and worked closely with development, product, and leadership.

Contents

Discover

Discover

01

01

Define

Define

02

02

Develop

Develop

03

03

Deliver

Deliver

04

04

Detect

Detect

05

05

Delight

Delight

06

06

Reflect

Reflect

07

07

Business goals

Business goals

1

Expand Reach Across Property Segments

Expand Reach Across Property Segments

Scale adoption across high-density residential, commercial, and small properties using a single flexible 4-app ecosystem.

2

Minimize Onboarding & Support Costs

Minimize Onboarding & Support Costs

Design an intuitive, low-literacy UI apps to maintain low user training overhead and reduce support calls.

3

Accelerate Delivery & Reduce Maintenance

Accelerate Delivery & Reduce Maintenance

Unify development across all four apps with a 50+ component design system in code to speed up shipping and cut maintenance costs.

Discover

01

I used the double diamond method throughout the project. Before jumping into research, I tried to understand the IoT devices.

I conducted user interviews and surveys which I analyzed to find the following:


  • The on-ground member does basic daily tasks whereas complicated tasks are handled by a society member / facility manager

  • More than one person takes care of water in a building (at least 1 on-ground)

  • Users tend to forget about running motor very often

Every building in India is currently facing water supply, storage and management issues that span over wastage, consumption, pricing, availability and accountability especially during scarcity.

Context

Operator needs

Product response

Gated Communities & High-Density

High volume, automated motor scheduling, low staff dependency.

Multi-tank monitoring views, automated pump schedules, quick-action status controls.

Commercial & Healthcare (Hospitals, Hotels)

Zero downtime, water quality visibility, fault & incident tracking.

Modular support for quality sensor readings, detailed usage logs, system event breakdowns.

Independent Houses & Small Buildings

Simple visibility, cost savings, minimal technical interaction.

High-contrast visual level checks, streamlined tanker re-ordering.

Define

02

Defining what needs consideration for the MVP.

Here's what I deduced:

  • Every building has their own custom tanks and nomenclature

  • Different building types have different requirements

  • Designing for low-literacy is priority while keeping it data-rich for alternative users

Design Strategy

Design Strategy

3

Explain the app's own decisions

Explain the app's own decisions

A system that acts on the user's behalf needs an

explanation when it does.

2

Simple and linear flows

Simple and linear flows

Structured processes so the user only has to make one decision at a time before moving to the next screen

1

Visual first, text last

Visual first, text last

A tank state should be readable at a glance, not parsed.
No jargon, minimal reading.

Develop

03

Collaborating with developers and stakeholders from the initial stages has given me insight into the technical limitations. This ensured less revisions and smoother implementation.

Deliver

04

Building a design system that is scalable across applications, systems and brands also keeping in mind the unified language system between product, development and design teams.

Designing the primary feature

The start/stop motor is the function used by the primary target audience and is required to be as simple as possible.

Worked on the design to reduce the number of steps to complete the action from 6 to 7 steps to
3 to 4 steps.

Automation flow
The automation flow required smooth and seamless set up over repetitive tasks

Designing for all use cases
The automation flow required smooth and seamless set up over repetitive tasks

Detect

05

After an initial round of testing with 4 users, I noticed that the users were never actually going to the water

As the sole designer bridging research, UX, and cross-functional work with frontend and IoT teams, I had to simplify without oversimplifying, since a missed alert has real financial and safety consequences. Looking back, I'd push for earlier user testing, since my confidence in these decisions came more from technical understanding than direct validation with the people using it.

Detect

05

Reflection

Aquinto taught me that good design starts before you touch a screen. The real work was understanding water storage systems well enough to know tanks connect in non-obvious ways, and that the person managing them varies from a security guard to a time-strapped facility manager. Starting with the data structure instead of screens meant every decision was grounded in what the system could do and what users could actually act on.

As the sole designer bridging research, UX, and cross-functional work with frontend and IoT teams, I had to simplify without oversimplifying, since a missed alert has real financial and safety consequences. Looking back, I'd push for earlier user testing, since my confidence in these decisions came more from technical understanding than direct validation with the people using it.

Reflect

07

Aquinto taught me that good design starts before you touch a screen. The real work was understanding water storage systems well enough to know tanks connect in non-obvious ways, and that the person managing them varies from a security guard to a time-strapped facility manager. Starting with the data structure instead of screens meant every decision was grounded in what the system could do and what users could actually act on.

As the sole designer bridging research, UX, and cross-functional work with frontend and IoT teams, I had to simplify without oversimplifying, since a missed alert has real financial and safety consequences. Looking back, I'd push for earlier user testing, since my confidence in these decisions came more from technical understanding than direct validation with the people using it.

The build I inherited was a diagnostic tool: sensor readings piped onto screens to prove the

hardware worked. That was the right thing for the team to build first. It just had not been designed

for anyone outside the team.

The users.

Security guards and facility managers. Low smartphone familiarity, reading quickly

while on the move, often not comfortable in English. The team knew this. What it meant for the

interface was the part nobody had worked on.

No research budget.

Interviews and formal testing were not sanctioned. So I worked with what I had: structure, and watching people use the thing. I started by mapping the existing information architecture and marking where a user's intent and the app's structure diverged. I presented it to the founder, we aligned, and I rebuilt from there.

4

DESIGN & HANDOFF

Building a design system that is scalable across applications, systems and brands also keeping in mind the unified language system between product, development and design teams.

Designing the primary feature

The start/stop motor is the function used by the primary target audience and is required to be as simple as possible.

Worked on the design to reduce the number of steps to complete the action from 6 to 7 steps to
3 to 4 steps.

Automation flow
The automation flow required smooth and seamless set up over repetitive tasks

Designing for all use cases
The automation flow required smooth and seamless set up over repetitive tasks

Reflection

Aquinto taught me that good design starts before you touch a screen. The real work was understanding water storage systems well enough to know tanks connect in non-obvious ways, and that the person managing them varies from a security guard to a time-strapped facility manager. Starting with the data structure instead of screens meant every decision was grounded in what the system could do and what users could actually act on.

As the sole designer bridging research, UX, and cross-functional work with frontend and IoT teams, I had to simplify without oversimplifying, since a missed alert has real financial and safety consequences. Looking back, I'd push for earlier user testing, since my confidence in these decisions came more from technical understanding than direct validation with the people using it.

Create a free website with Framer, the website builder loved by startups, designers and agencies.