PROJECT Summary
November 2019 - June 2020
This project is a desktop application that provides the ability for industrial process engineers to model air duct networks that supply air in fired heater assets. This tool is used in the asset onboarding process of EMBER.
The initial research and design of this project occurred over a four-month period. I was the principal designer, with some support from a consultant during the research and wireframe stage. I worked with the product manager throughout the design phase to prepare for handoff to development.
Development began in March 2020, and I supported the development team throughout the project. The development team comprised a diverse group of engineers from my company, Slalom, and AWS.
Tools:
Sketch
Miro
InVision
Research
Domain Research
This project was my first introduction to the world of fired heaters. It was initially conceived as a joint venture between EFT Analytics and John Zink Hamworthy. This project would focus on modeling air networks for fired heaters, but I needed to gain a base understanding of computational fluid dynamics (CFD) to understand the application of this product. I also needed to understand EMBER and how this product would fit into that digital ecosystem. EMBER can calculate the optimal burner settings for a heater, but it is dependent on certain inputs, such as airflow and fuel flow(stoichiometry), to output accurate setting recommendations.
It was decided to utilize the Handbook of Hydraulic Resistance by I.E. Idelchik to create the models that would represent air duct networks that exist on each heater. Idelchik’s Handbook includes geometric elements and attributes used to calculate the pressure drop when a fluid passes through the element; air would be the fluid in this instance. By modeling the air duct network with these elements, we would understand how air behaves and determine the pressure drop at each burner.
Excerpt from Handbook of Hydraulic Resistance by I.E. Idelchik
User Research
I traveled to Tulsa, OK in November 2019 to begin an initial research meeting and meet the product's users. This product has a particular use-case and user base. We chose to approach the user research similarly to IBM’s Sponsor User Program; the end-users were deeply involved in the initial discovery and research phase.
We were hoping to create a product that would streamline the manual steps that the process engineers were doing on paper and in Excel. We examined each manual step to determine which were the most time consuming and inefficient.
User Problem
EMBER (OnPoint’s Fired Heater Product) requires accurate burner air-side and fuel-side modeling to provide air damper setting recommendations effectively. Initially, process engineers accomplished this through a very manual process that is heavily time intensive and inefficient. This manual process resulted in a bottleneck in the on-boarding of assets into the EMBER digital ecosystem, a problem for process engineers (users) and OnPoint’s growth(business).
I interviewed the process engineers who comprised the Solution Delivery team to understand how they were completing this process using Excel and how we could deliver the greatest value in an initial MVP for this product.
Written Node Representation of Air Duct Network
Solution Statement
We will create a digital product that allows process engineers to build air duct networks quickly. The completed models will calculate individual and combined k-values (pressure drops) consumed by EMBER without manually processing the resistance calculations. We will utilize Idelchik elements that contain dimensional data for properties such as height, width, depth, diameter, radius, etc.
Design
Feature Prioritization
We created a hybrid user journey map and priority matrix while in Tulsa to scope out the MVP. We worked with the technical product manager to determine which features would need to be included in this first iteration. The red line on the whiteboard illustrates this process; everything above the line would be necessary to provide value.
Feature Summary:
Must support model assignment (Client/Site/Asset)
Flexibility for different model types (Air Duct Network only for V1)
Flow Elements based on Idelchik Library
User input values for flow element attributes
The final model would output in JSON format
Interaction Design
The desire was for an intuitive interface that easily enabled process engineers to build an air duct network using Idelchik flow elements. Each Idelchik flow element has inherent attributes, like area or friction, that change the k-value of air as it flows through the element. As values are input for each attribute, the k-value of the flow network will change; in a manual process, this equates to time spent making adjustments to calculations.
This product's design allows the user to drag a flow element from the library, move it around the canvas to the needed place, and attach it to other elements to build the flow network. As the user builds the network utilizing the UI, the backend actually constructs the required JSON format. The “Preview” feature allows the user to actually see the network’s JSON format in a user-friendly format; each parent-child relationship is shown in the hierarchical format along with the visual representation.
Wireframes
Iterations
Final Product
I delivered the final mockups to the development team through InVision. Throughout the development process, I worked with the developers on the team, revising designs based on feedback to reduce the complexity of implementation and creating new screens to promote clarity for QA acceptance criteria. This screen recording is of the current product that is in UAT.
Next Steps
The project was developed as a progressive web application that is integrated into the larger OnPoint Portal. At this time, the editor has passed UAT and is available for the Solutions Delivery to utilize.
We will have periodic feedback sessions to identify usability issues and ways that we can improve in future iterations.
In the future, we will look to incorporate burner models and possibly support other flow element libraries (Crane).
There is a second “phase” of this product that is currently wrapping up initial development. Click here to view my case study for the Hydraulic Modeler - Tuner.
Conclusion
This project was an incredible learning experience for me; it was the first product that I designed end-to-end. I worked very closely with the development team throughout implementation, and this taught me several things.
I learned that design could be greatly enhanced and effective when there is open communication between designer and developer. Collaborating with the developers during implementation resulted in a reevaluation of numerous design decisions that eventually led to more elegant solutions for the end-user.
I learned that a designer’s job is far from over when handoff to development occurs. This product had so many interaction design complications that I often needed to revise or provide new screens. This helped clarify how the product should behave and address edge-cases that came to light during implementation.