008Studio Carbon · 2022
Ubuntu Waterhub Africa
A UX audit of the dashboard behind Kenya's water ATMs
Summary
Co-led an eight-week UX audit of the dashboard Ubuntu Waterhub Africa's operators use to run their water ATMs, reconstructing the product's architecture from the outside and rebuilding it around the decisions its four user roles actually make.
- Role
- Co-lead designer
- Client
- Ubuntu Waterhub Africa
- Team
- Two designers with the client's product team
- Timeline
- 8 weeks
- Platform
- Web dashboard and mobile app
My role
I co-led the engagement at Studio Carbon: mapping the existing product, analysing its architecture and flows, writing the audit, and designing the wireframes and mobile dashboard that came out of it.
The client was in Kenya, we were in India, and we never had a login. Everything we knew about the product had to be reconstructed from walkthrough recordings, exported screens and conversations.
Impact
7 → 5
top-level branches after the architecture was consolidated
8
documented recommendations across architecture, functionality and visual style
4
user roles sharing a single dashboard, mapped and separated
Context
A cash register bolted to a water tap
Ubuntu Waterhub Africa builds water ATMs: IoT-connected vending units, some of them on satellite links, that dispense drinking water, community water and livestock water and collect payment without cash. A finalist at ASME ISHOW Kenya in 2022, the hardware was working and deployed.
The software around it was the problem. A small entrepreneur running two or three units, an NGO sponsoring a village, and Ubuntu's own admins were all being served by one dashboard that had grown a page at a time as features shipped.
Method
Auditing a product we could not log into
We had no access to a live account, so the first three weeks were archaeology. We rebuilt the product from walkthrough recordings and real dashboard exports into a complete map: every page, every sub-page, every path between them.
That map became the instrument. Once the whole system was visible in one frame, the problems stopped being opinions about individual screens and became structural facts we could point at.
Can operators look at this dashboard and know what to do next, rather than only what happened?
System
One dashboard, four people who need different things
Before critiquing anything, we separated who the product was actually for. Each role touches the same data with a different question in mind, and the existing navigation treated them as one generic user.
- 01Admin — Ubuntu's own team, with full control of devices, sites, clients and customers.
- 02Partner — NGOs sponsoring units for a community, who care about consumption and reach rather than revenue.
- 03Client — the device owner running it as a business: revenue, pricing, uptime, top-ups.
- 04Customer — the person at the tap, who never sees the dashboard but generates everything in it.
Findings
The structure described the company, not the work
Transactions, revenue and reports lived in three separate branches, so answering one question meant visiting three places and reconciling them. “Generate Reports” was a set of pages rather than what it actually is, a download. And “Water ATM Management” named the current product instead of the category, which would break the day Ubuntu shipped a second kind of device.
The screen-level issues followed the same pattern: signifiers used inconsistently between lists, colours applied without semantic meaning, and the numbers an operator opens the dashboard for buried below the fold.
- 01Consumption and revenue moved to the top of the screen, with a time filter and an all-time figure beneath.
- 02Latest transactions and top-ups surfaced on the home screen as the entry point into analytics.
- 03Transaction modes colour-coded consistently, and customer acquisition shown as columns rather than a line.
- 04All transactions, revenue and reports consolidated into a single Transaction Reports branch.
- 05Report generation demoted from a destination to a download action on the data you are already looking at.
- 06“Water ATM Management” renamed to “Device Management” so the architecture survives the next product.
Reframe
The finding that changed the deliverable
The audit was commissioned for a web dashboard. What the walkthroughs and client conversations kept showing was that the people running these units were not at a desk; they were at a site, on a phone, checking whether a machine had earned anything today.
So we ended the engagement somewhere other than where it started: a mobile dashboard built around consumption, revenue, latest transactions, customers, devices, tags and reports, with the same structure scaling up to desktop rather than being cut down from it.
An audit is only useful if it is willing to question the brief. The most valuable finding here was about the device, not the design.
Outcome
What I took from it
The client left with a documented audit, a proposed architecture and a wireframed mobile product, each recommendation tagged by type so their team could sequence the work against their own roadmap.
It also taught me how much leverage there is in naming. Half the confusion in that product came from labels inherited from internal vocabulary, and fixing them cost nothing but changed how the whole system read.
