Key Decisions & Tradeoffs

An anonymized view of the previous interface shows how repeated cards and a horizontal layout spread the network across a large canvas.

The water distribution network comprised pumps, large reservoirs, tanks, and numerous downstream clients, each with its own readings, states, and operational properties. The previous interface gave most assets similar visual weight and exposed too much information at once, so operators had to scroll, zoom, and move around the canvas to understand the network. Discussions with users clarified that their immediate priorities were to 1) see how the network connected and 2) quickly identify problems that required attention. The redesign therefore focused on fitting the core network into one view, with further details available when needed.  

A top-to-bottom layout gives the main reservoirs greater prominence and groups smaller assets so the network and its issues can be read in one view.

I reorganized the network from top to bottom, instead of left to right, according to the distribution sequence, with pumps above the main reservoirs, followed by downstream tanks and clients. Assets at equivalent stages shared the same horizontal level, while their visual weight reflected their importance to the overview. Pumps became compact status symbols with their operational grouping communicated through proximity, and the main reservoirs remained prominent.

Collapsed client groups retain their issue counts, so operators can identify the branch that needs attention before expanding it to locate the affected client.

Clients accounted for a large proportion of the original cards, so their details were placed beneath expandable group controls. This reduced the initial density, but early testing showed that operators still had to open each group to discover whether a client had a problem. A visible issue count was therefore added to the collapsed state so that the overview could remain compact without concealing information that required action. Operators could then open the relevant group to identify the affected client rather than inspect every group in turn.

Pump symbols combine color and status icons, while reservoir levels are shown against minimum and maximum thresholds so abnormal conditions can be recognized directly on the network.

The asset graphics also carried more of the operational information directly. Pump states distinguished running, stopped and unavailable equipment, although maintenance and faults had to share the unavailable state within the available data model. Reservoir graphics reflected actual water levels against visible minimum and maximum thresholds. Normal water remained blue because it was a more intuitive representation of the content (instead of semantic green), while red and warning symbols drew attention to levels outside the operating range.

After these improvements, feedback from testing was strongly positive. Operators could see the overall distribution structure, distinguish pump states, and identify reservoir or client issues from the initial view. Detailed inspection remained available, but it was no longer a prerequisite for understanding whether the network needed their attention.

The selector explores flow, percentage, temperature, and pressure on the same network. This direction was left out under the development deadline because the readings remained available in asset details.

Once the network fit into one view, another challenge was how to show flow, percentage, temperature, and pressure for each relevant asset without overcrowding it again. A metric selector allowed operators to change the readings displayed across the diagram while its structure remained familiar. Although the concept was well received during design, early testing suggested that switching metrics would be less frequent than initially expected. Under a tight development deadline, it was left out of implementation because the additional readings were already accessible through each asset’s detail panel. The concept remained an exploration of a pattern that could be useful in other products.

Reservoir, pump, and client panels share a consistent structure, with readings and properties adapted to the selected asset.

Although the overview exposed the information needed for initial monitoring, operators still needed access to the detailed readings and properties of each asset. Selecting a reservoir, pump, or client opened its information in a side panel whose structure adapted to the asset type. The network remained visible beside it so operators could inspect an item and move to another without losing their place or navigating between separate pages.

The same panel hosts alerts from across the network, where asset symbols, issue descriptions, and timestamps help operators choose what to inspect next.

Once that panel became part of the workspace, the same area could support broader monitoring needs whenever no asset was selected. It displayed metrics for the overall network by default and could switch to alerts when operators needed to review issues across different assets. The panel therefore adapted to the current task while the diagram remained a consistent point of reference.

Performance tables, historical trends, contributions, and utilization were brought into one reporting workspace. This remained a design exploration outside the implementation scope.

Once operational data was centralized, the platform could support comparisons across the entire network, from pump availability and utilization to storage trends, consumption, and water loss. Existing reports were reviewed first to establish which information operators already relied on and where additional analysis could add value.

Contribution cards use the same layout across pumping, storage, distribution, and consumption, while controls within each card switch between individual assets and operational groups.

The challenge was to make that analytical depth intuitive within the project’s timeline. Several iterations explored the report selection, chart types, information hierarchy, and layout before the structure settled into five tabs for pumping, storage, distribution, consumption, and water loss. Each used the same arrangement of report cards and interaction patterns, although the measures and content changed with the subject. Detailed tables supported asset-level comparisons, while history, contributions, and period summaries offered complementary perspectives. Controls within the cards allowed operators to switch between totals, individual assets, and operational groups without requiring a separate report for each level.

Filter hierarchies follow pump groups, tanks, and clients. This direction was deferred because consistent filtering across the reporting views exceeded the implementation scope.

The reporting work took a different turn when some stakeholders reviewed the designs and explained that they did not reflect the reports they needed. Until then, “reports” had been understood as performance analysis, as it had been in similar projects, but these stakeholders were referring to the records operators completed at the end of each shift. Because both needs had been discussed under the same term, the difference only became clear once the designs gave everyone something concrete to react to. These shift reports followed established templates whose required content could not change within the project’s scope. Stakeholders were open to revisiting those practices later, but the immediate need was to support them within the platform. A dedicated shift-reporting flow therefore allowed operators to view the relevant readings and manually complete information that still required their input, such as instructions, manoeuvres, events, and anomalies.

The retained shift-report direction reorganizes the entity’s existing template into clear panels for readings, pump states, instructions, manoeuvres, and anomalies.

Four templates covered the different operational contexts, with the fields and sections of each preserved rather than forced into one universal report. The layouts reused card components that had already been built, which reduced development effort and provided a consistent presentation across station conditions, reservoir readings, client consumption, and pump availability. Where required by the original template, the reports also retained comparisons between the beginning and end of a shift.