My first approach focused on creating a clean and structured representation of the steam network based on process logic and energy-flow direction. Since I initially had limited access to the real operational process, I independently researched similar industrial systems and organized the layout around the system architecture itself. Although the structure was technically coherent, reviews revealed that its visual hierarchy communicated the wrong operational priorities. Collectors became the most visually dominant elements, while turbines and generated energy, the parts operators cared about most, felt secondary and visually compressed. The interface also used shades of blue to distinguish steam-pressure levels, which unintentionally made the network resemble a water system rather than a steam network.

An early network layout used pressure-level colors and prominent collectors; reviews helped identify where that hierarchy diverged from operators’ priorities.

By that point, the direction had already gone through multiple rounds of refinement and interactive prototyping. In a more conventional design process, the underlying representation model would ideally have been validated with operators through wireframes before moving into detailed visual refinement. In this project, however, the compressed timeline and limited direct user access meant that validation and refinement often happened in parallel. As with several other complex B2B projects in my portfolio, higher-fidelity prototypes were necessary to make the operational concepts concrete enough for stakeholders to evaluate and discuss. Although stakeholders already had existing industrial diagrams, I initially treated them as references rather than established mental models operators regularly used. As the project progressed, it became clear that the directional structure of these diagrams carried important operational familiarity. The challenge therefore shifted from reinventing the representation to improving its readability, layout, iconography, and interaction clarity while preserving the logic operators already understood. Although setting aside a refined direction was costly, the prototypes also functioned as research artifacts. They helped build a shared understanding of the system, surface hidden assumptions, and progressively align the interface with the operational reality.

Once the overall representation direction became clearer, the next challenge was deciding how much of the operational network to show at each level. The platform needed to provide an overview of the entire network across multiple sites while still supporting the operational differences and detailed decisions within each individual site. Displaying every producer, consumer, collector, turbine, valve, and transfer in a single diagram would have recreated much of the complexity we were trying to reduce. I structured the visualization around two levels of detail. The network-wide view aggregated each site into its main operational blocks and surfaced the totals and exchanges needed to understand the overall energy balance. Users could then move into a dedicated site view where the same model expanded to reveal its specific production and consumption sources, collectors, turbines, valves, and connections. This progressive disclosure preserved a recognizable relationship between the two levels while preventing the overview from becoming overloaded.

The network overview summarizes the main exchanges, while site views reveal the equipment and connections needed for more detailed decisions.

Deciding what to aggregate was not purely a layout problem. Some production and consumption values needed to be combined into totals to make the overall balance understandable, while others had to remain separate because their source, destination, or operational role affected the decisions users could make. Equipment also required different levels of information depending on context. At the overview level, users primarily needed to recognize significant exchanges and overall system conditions. Within a site, they needed more detailed information about turbine output, valve state, equipment availability, and whether an element was active, inactive, or experiencing a problem. The layouts continued to evolve as additional blocks, constraints, and operational relationships became clearer through reviews. New production and consumption details sometimes appeared after screens had already been refined, requiring parts of the flow to be reorganized. Rather than treating each diagram as a fixed composition, I progressively developed a modular visual system that could accommodate site-specific differences while maintaining consistent components, spacing, directional logic, and status patterns.

An alternative direction favored by several operators used a more technical schematic treatment of equipment, connections, and flow values.

Visual iterations balanced the technical schematic operators preferred with other stakeholders’ preference for a more modern interface, leading to the direction shown in the solution.

Once the representation and hierarchy became clearer, the challenge shifted toward interaction design and operational inputs. What initially seemed like a simple distinction between editable and fixed values became increasingly complex as we better understood the workflow. Operators needed to immediately understand which values they could modify and which were generated, calculated, or constrained by the system. Some inputs needed to display the current operational value before allowing a change. Others existed primarily as parameters for the optimization model while still remaining editable when users created alternative scenarios. Certain values also behaved differently depending on the equipment state or operational context. The interaction system therefore had to communicate more than whether a field was editable; it also needed to clarify the role of each value within the process.

I began structuring values according to their function in the workflow: current operational values, editable parameters, system constraints, calculated outputs, and optimized recommendations. Current values provided the reference point, while proposed changes needed to remain visually distinguishable without disconnecting them from the part of the diagram they affected. Recommended values also needed to be recognizable as model outputs rather than direct system measurements. To avoid turning the monitoring interface into a large form, frequently adjusted values remained connected to their operational context, while less frequent configuration choices could be handled through dedicated settings or scenario controls. The interaction model continued to evolve alongside our understanding of how operators reasoned through constraints and scenarios. Establishing a consistent system for these value types became essential for supporting both optimization and simulation without requiring users to relearn the interface between modes.

Value components distinguish edited inputs from optimized recommendations and define default, focused, and disabled states across operational categories.

After the structural model became more stable, the visual direction needed to communicate a large number of values and equipment states without making the diagram visually noisy. The interface had to distinguish current conditions, editable parameters, recommended values, transfers, electricity generation, warnings, and inactive equipment while maintaining a coherent operational view.

Several visual approaches were explored before settling on a more restrained system. Neutral treatments were used for the underlying equipment and structure, allowing color to carry operational meaning rather than decorate the interface. Different treatments helped distinguish current values from optimized recommendations, while turbines, valves, and other equipment needed recognizable states for active, inactive, constrained, or problematic conditions. The iconography was also refined to represent the main types of production sources, consumers, collectors, turbines, valves, and transfers consistently across sites. Because each site had different equipment and operational relationships, the visual system needed enough flexibility to accommodate local differences without creating a different design language for every configuration. The goal was not to reproduce the appearance of traditional industrial control software. It was to preserve the logic and familiarity operators relied on while improving hierarchy, scanability, and state recognition. The resulting direction used consistent equipment components, value treatments, status patterns, and connections so users could interpret unfamiliar site configurations through the same visual language.

Equipment-state explorations combine flow values, symbols, and color to distinguish operating conditions without relying on color alone.

Once the operational structure became more stable, the project expanded to include dashboards and reporting for monitoring performance over time. Compared with the process-visualization phase, this work progressed more quickly because the underlying data model, operational terminology, and priorities were clearer by then. The reporting experience needed to go beyond showing historical production and consumption. It also needed to help teams understand how the network had performed, how much electricity had been generated, and whether operational decisions had moved the system closer to or further from the optimized scenario.

Industrial sites can share equipment types and operational concepts while differing in their connections and constraints. I designed reusable components and layouts that could accommodate these differences without forcing every site into the same diagram. The network and site-level structure provided a consistent foundation, while the details of each configuration remained visible where they mattered.

This influenced how I organized equipment components, value treatments, states, and layouts. Shared patterns stayed consistent across views, while site-specific details could vary without requiring a separate visual language for each configuration.