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.
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.
Analyzing business needs in addition to user needs is a critical differentiator for lead product designers
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
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.
Goals and Pain Points for both the client and the end users, an important balance to strike in product design
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:
Reduced down to the high level goals by focusing on the business and user needs
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 level goals branching from the three bins of the aforementioned high level goals
User level goals branching from the three bins of the aforementioned high level goals
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.
Affinity diagramming session to figure out feature sets and beginning of architecting the features
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
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.
Information architecture diagram, showing main navigation "hubs" as full-sized boxes and the tabs within as half-sized boxes
Information architecture diagram, showing main navigation "hubs" as full-sized boxes and the tabs within as half-sized boxes
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.
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
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
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.
Examples of low-fi wireframes to determine basic page layouts and interactions
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.
Cross-platform filtering hi-fi mockups
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
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.
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.
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
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.
