UX Design

OnPoint Hydraulic Modeler - Tuner

 
Screen Shot 2020-12-06 at 5.20.51 PM.png

 PROJECT Summary

June 2020 - November 2020

The initial ideation of this functionality set was conceived in the original Hydraulic Modeler Discovery Process. This product aims to complete the hydraulic modeling process so that EMBER can utilize the final JSON. We run a regression on the hydraulic model created in the editor using generated CFD data in order to have a model that is an accurate representation of a real air duct network.

Development began in June 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

The hydraulic model that we create in the editor is meant to represent an air duct network in the real world, but we must train the model for it to be accurate. We must account for many real-world variables to get the most value out of a model, Idelchik elements depict CFD properties in isolation.

We accomplish this by creating generated CFD data to train the model against, utilizing an Idelchik attribute built into our model called Efficiency. The regression results in values being pushed into each element’s Efficiency attribute, which adjusts each element's pressure drop (k-value).

 
John Zink Hamworthy CFD Analysis

John Zink Hamworthy CFD Analysis

 

User Research

The users of this product are the engineers that make up the OnPoint Solution Delivery team. These engineers are responsible for creating the hydraulic model and then preparing it to be deployed to EMBER. This hydraulic modeling is a key piece of the EMBER asset onboarding process.

This tuning was occurring in isolation conducted by the principal engineer that developed the EMBER algorithm. It is vital for the OnPoint organization to streamline the asset onboarding process to provide value through EMBER.

 

I worked collaboratively with the technical product manager, the principal engineer, and the Solution Delivery team members to understand how we could incorporate this process into the Hydraulic Modeler in a sustainable and scalable way. We had numerous meetings and interviews where our subject matter experts (SMEs) shared knowledge that we then synthesized remotely using boards in Miro.

 

User Problem

The defined problem that we hoped to solve with this feature set is to allow the Solutions Delivery team engineers to efficiently tune and deploy hydraulic models after they are created in the editor.

Our team of users needed a scalable process that will allow the team to complete and deploy hydraulic models to meet a demanding onboarding schedule. Due to the manual process of onboarding assets, it currently can take up to 3 months to onboard one asset. OnPoint has a goal of onboarding 5,000 assets by 2025.

 

Solution Statement

We analyzed the manual tuning process that the principle engineer must complete and integrated it into the Hydraulic Modeler. We will allow Solutions Delivery engineers to effectively tune hydraulic models after they are completed in the editor. The engineers will then be able to deploy the hydraulic models to EMBER for consumption.

 

Design

User Flow

Screen Shot 2020-12-15 at 9.09.56 PM.png
 

Wireframes

 

Final Screens

 

Next Steps

This project has been implemented and integrated into the OnPoint Portal. It is currently in User Acceptance Testing (UAT) and then will be available for the Solutions Delivery Team to use. We will conduct regular feedback sessions with these engineers to understand usability issues and identify areas of improvement.

There has been a request by the principle engineer behind EMBER to add an additional visualization for tuning review. This request was made mid-development, so we will be including it in the next iteration of this product.

 

Conclusion

This project was a challenge due to the tight turn around time to get design to development. The product team knew that tuning would be something that we would want to include in the modeling process, but we were not initially aware of the timeline that our leadership had determined. This set of functionality was a natural secondary piece to the editor, but we began development almost directly after completing the modeler. It was challenging for the product manager and I to stay ahead of development throughout the duration of this project. We were defining and designing the product a sprint ahead of the development team, which can cause difficulties due to lack of time to identify edge cases. We were able to be successful due to great inter team communication and support, the development team was great at working with flexibility when the need to adjust arose.