Image showing a few web screens from the water management app, mocked up in iPad screens

Case Study

Water Utilities Management – Web App Exploration

I was challenged to research and design a water utilities management platform that would utilize smart meter data throughout urban areas to increase revenue, safety, and customer satisfaction.

Deliverables

Problem Discovery, Branded Prototype, Use Case Video

Client

N/A - Use Case Exploration In-House

My Role

Lead Product Designer

Collaborators

None

Project Timeframe

2 weeks

Tools

Figma, pen & paper, and Adobe AfterEffects

Problem Statement

Over the past few years, the public has turned a critical eye onto water management entities.
Between health emergency declarations, aging infrastructure, seemingly endless droughts, and a shift towards more conscious water usage, water utilities are in the spotlight. Many departments deal with issues over poor consumer experience, billing management, and water quality. Luckily, industrial smart technologies have created a wave of possibilities for water utility departments. Internet-connected water meters at a residence or building level can accurately measure water usage, as well as signal for servicing or emergency shut-off.
Water utilities providers need a modern platform to visualize and meaningfully act upon the millions of new data points to improve customer trust, replace aging infrastructure, and prevent emergency costs.
The "Usage" dashboard page, showing an example of how data would be displayed, including a consumption comparison chart and a table calling out high-usage accounts
The "Usage" dashboard page, showing an example of how data would be displayed, including a consumption comparison chart and a table calling out high-usage accounts

Who Am I Building For?

As a lead product designer, I emphasize balancing user goals with business goals.
Without accessible stakeholders, I dove into research about water providers in the United States. Water providers can be public or private entities that work closely with local government. The platform would need to boast an aura of trustworthiness and accessibility to be attractive at a private and public level.  

The users of this platform would be employees of multiple access levels of these organizations, from customer support agents to high level managers responding to water break crises.  The framework would need to be simple, yet flexible enough to support different goals across multiple levels.
Business Needs
Analyzing business needs in addition to user needs is a critical differentiator for lead product designers
The left image details the "Most critical business needs." They are as following: augment and replace aging infrastructure, shift funding towards capital improvement projects, ensure long-term water availability, and improve consumer sentiments and relations. The image on the right highlights that every day, nearly 6 billion gallons of treated drinking water are lost due to leaking pipes.
Analyzed the business case through research

Roles & Responsibilities

I worked as the sole designer on this project, from the ideation phase through the final visual design.
Although this was a use case exploration rather than a client contract, I took each step in a full design process to ensure that user goals were researched, determined, and ultimately met via the platform design. I bounced questions off one of our team’s developers, who had previously published an article on IoT water management solutions, to better understand the potential technological architecture of this use case.

Scope & Constraints

This project had no clients, requirements, budget, or guidelines. My employer, Leverege, works to design and build Internet of Things (IoT) platforms for companies looking to add new business verticals. Use case explorations outside of client work help us explore design patterns and challenges that are outside our current toolbelt.  The final deliverable of a use case exploration is a short video to source business development and are not tested nor further explored until customer interest piques.

The Process

Understanding the User
To better understand and empathize with my users, I created two user personas: Alexis Chang and Dermot Roache. With a grasp on their goals and pain points from two different roles at a water utilities company, I was better equipped to dive into feature discovery.
User Personas
Goals and Pain Points for both the client and the end users, an important balance to strike in product design
To create an experience that allows users to pinpoint weak infrastructure and improve customer relations all-in-one, I needed to break down the most important user goals. The key high-level components I identified are:
Water Management High Level Goals
Reduced down to the high level goals by focusing on the business and user needs
High Level Goals
Reduced down to the high level goals by focusing on the business and user needs
These align to the business goals I identified during my industry research. I found the three bins where I would focus my efforts and further break down the goals associated to each: Usage, Maintenance, and Infrastructure. While high-level goals satisfy some degree of user centric designs, they do not give any detail as to what will be included within these bins. Diving down into more granular user goals help determine the features that will be designed.
User Goals by Feature Bin
User level goals branching from the three bins of the aforementioned high level goals
Focusing on Features
From there, I turned to my good friend Post-Its to discover the features. I find it is best to list out everything that comes to mind on sticky notes, color coordinated based on the feature bin I believe it best fits. This way, I do not narrow myself to the different possible features by focusing too much on scope.

I went through a round or two of filtering after my ideation session to pare the feature set down to a reasonable amount for what I would consider a first cut at a full product. I allowed myself flexibility to add or remove to this set as I continued my design process to allow for goal alignment.
User Goals by Feature Bin
Affinity diagramming session to figure out feature sets and beginning of architecting the features
Water Management Usagel Goals
Examples of low-fi wireframes to determine basic page layouts and interactions
Affinity diagramming session to figure out feature sets and beginning of architecting the features
Architecting the Data
The pilot interfaces had a limited amount of functionality. Some features existed in one interface but not the other, and where they did would completely change how the interface worked.

With a consolidation of products and incorporation of new features that were all set within differing access levels, the information architecture was a critical juncture in creating a unified product. I spent significant time working how the features, even those not in scope for well over a year, would fit in relation to one another.

In the end, I sat down with our project manager and developers and ran through my recommendation for a scalable architecture to get cross-team approval. We agreed upon a navigation structure that changes along with the access level for security purposes at the lot-level.
User Goals by Feature Bin
Information architecture diagram, showing main navigation "hubs" as full-sized boxes and the tabs within as half-sized boxes
Navigating the Product
To create a user-centered product, I created user flows to find how a user would surface the information or action they need. As I am a product designer in IoT, I also must understand the logic behind the product. Data does not purely get generated by a user on the platform; in fact, hundreds of thousands of data points pour in each day from meters as well as expected application programming interfaces (APIs) to allow other applications to “talk” to the management platform, such as billing platforms. I designed logic flows to help distill where internal and external feeds, forces, and logic come into play to accomplish a task.
User Goals by Feature Bin
Example of a logic flow, one of the critical design practices within IoT due to interactions between physical hardware, gateways,  the backend platform, and the frontend portal
Wireframing
I spent the next significant length of time wireframing the prototype to understand how I would be laying out data and features. Since I work closely with our development team daily, I know how critical scalability and element recycling is to them.
Water Management Usagel Goals
Examples of low-fi wireframes to determine basic page layouts and interactions
I also know from user tests that repeated structures allow a user to decrease the amount of time searching aimlessly for features. I tailored my wireframed screens to reuse similar layouts and components for both reasons as I would in built products.

Accounting for the amount of data that IoT solutions intake and process, I utilized tables in my wireframes to allow for complete access to the data. Dashboard views are built off the same data to show data comparisons or data over time. The table structure is a familiar user experience, and by introducing it across many different features, it lessens the learning curve across the platform. Tables also allow for complex filtering which can tailor the data to the specific user’s needs.

Finally, an important element placed into the wireframes was a cross-platform filter. This functionality gives users the ability to view a certain city, town, or even neighborhood across all of the features without having to filter each individual page
Testing the Prototype
As use case explorations are not frequently tested to keep project time very minimal, I created a small user test that I sat down with two project managers separately to ask them what they understood could be accessed or accomplished on each page after a minute or two of viewing and interacting. This is not my preferred method of testing, as answering questions is not as effective to learn a user’s holdups. If I were to apply this use case exploration to a paying customer, I would build a more thorough click-through prototype and create a user test with 5-8 objectives. I would then observe users individually in action and apply my observations to our user test scoring matrix to find any confusing or issue-causing feature designs.
Applying Visuals
One notable learning from researching utilities interfaces is that a large percentage lack a feeling of modernity. Much like hospital or governmental software, the platforms were developed before user-centered design took centerstage and also have not been redesigned to match current UX patterns or UI trends.
I aimed to give my water utilities platform a modern yet trustworthy treatment from the color palette down to the rounded corners of buttons.
I chose a cool color palette of blues, predictably, as the primary brand color and paired them with a secondary palette of sleek bright teals. By utilizing our team’s early iteration of our design system, I was able to visually design screens rapidly and apply brand colors, standardized drop shadows, and more.
User Goals by Feature Bin
Chosen color palette to reflect the serenity of water and the push towards an eco-friendly future
Chosen color palette to reflect the serenity of water

The Finished Product

Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs
Layout of dekstop screen designs

Project Takeaways

Takeaway #1: Designing for utility companies requires extreme intentionality and empathy for the user experience as the average employee is in the field for over fifteen years.
Fields such as utilities, healthcare, and construction are not known to have the most up-to-date technologies powering their operations. It is crucial to gain both users’ and leadership’s trust to become an integral technology.
Takeaway #2: Use case discovery projects can elicit large amounts of self-imposed scope creep.
Very rarely does a designer work with a project that is 100% open-ended without any other stakeholders. This doesn’t reflect the normal path of client product design, but it is critical to follow the design process as much as possible, even without parameters or a normal timeline.

How Could I Improve This Project?

There is room for significant growth this platform. Were a client to be interested in building out this use case as a proof-of-concept, I would dive deeper into specific user research with the particular client’s stakeholders. Assumptions of users’ needs can make decent products, but they do not make great products.

I would take my current prototype and build out a full user test to find insufficiencies in the design, whether around the UX itself or the UX copy. From my learnings, I would update my designs to better suit the specific client’s needs.

In the vein of competitor research, similar platforms are inaccessible as they store sensitive personal identifying information and often are closely tied to local government. I was able to assess open-source city water information, such as DC Water’s database. These gave me loose guidance in how to lay out water data but lacked insight into tackling business or organizational goals.

See My Next Case Study

VEIC Submetering Platform