The Connected Equipment Internal Portal is a dashboard for HVAC chiller engineers and technicians to perform remote diagnostics on chillers that are located at offsite customer locations.
The portal saves time and money for Johnson Controls through automation and instant access to problems like faults and alarms to diagnose issues without having to be on location.
Note: A chiller is similar in theory to an air conditioner for a house but used for a large building. It can be used for additional cooling purposes as well.
Timeline: 4 months to project completion, extended time for development delivery in phases
My Role: I was the primary UX and UI designer on the project where I collaborated with a Principle UX Designer, Senior UX Researcher, Product Manager, and other stakeholders on the global team to redesign the portal workflows and screens.
By speaking with internal stakeholders and doing primary research with my team, I identified that chiller engineers and branch technicians for facilities are the main users for the Connected Equipment portal.
They use the dashboard to diagnose chillers, generate reports, create recommendations for further actions on problem chillers, and communicate with team members on solving chiller issues.
I created personas based on the data I received from user interviews for the two main user types:
The personas created alignment among my team for the CEP portal and made it easier for me to make decisions on how to approach designing new workflows and screens going forward.
We needed to know how our users used the connected equipment portal to diagnose chillers in their current workflow.
By conducting six user interviews with engineers and branch technicians on the North America team and three interviews abroad, we were able to understand on a deeper level what their workflows were and problems I could start ideating how to solve.
Some things we learned were:
The chiller engineer/branch technician communication loop is essential to successful connected chiller service and the CEP doesn't currently support it.
It is a multi-step, time consuming process for an engineer to do a chiller analysis, document the findings, share them and then log billable time.
Using multiple tools to diagnose chillers increases cognitive load and efficiency loss due to application switching.
I researched how the current portal worked and how the information architecture was structured for modules and content. How did the different areas of the portal fit together and how did it function?
I made assumptions about specific graphs and other functionality because at this time I didn’t know what they were for and needed to figure out the workflow that the chiller docs were using for their tasks of diagnosing alarms and faults.
I later validated these assumptions by conducting additional interviews with the engineers and using contextual inquiry to see in real-time how they diagnosed faults and other issues.
The old Connected Equipment Portal
I examined the portal page by page and looked for problem areas with usability as well as questions I had about functionality. There were lots of issues with lack of labelling, consistency from tab to tab, error prevention on pages like alarm configuration, and visibility of system status regarding completing notifications.
In general, the interface gave off this feeling that there is a lack of context and not enough descriptive text to tell the user what each page’s purpose is. With the new designs, I wanted to make sure these problems were addressed.
By analyzing the current user flows, I was able to figure out where friction points were for tasks and remove unnecessary steps.
Based on data I received in the interviews, I created new flows that illuminated how many steps it takes to complete their tasks and how time consuming it becomes with hundreds or thousands of chillers in their portfolio. I was looking to pinpoint inefficiencies that could be addressed with automation using the dashboard.
Task flows analyzed included:
Along with creating user flows for key tasks, I assembled a sitemap for the current portal to visually identify the connections between navigational elements and how the portal pages worked together.
This was helpful in identifying areas where functionality overlapped or didn’t make sense. I corrected these issues in the updated designs and grouped similar functionality and content together.
After research and defining workflows, I began ideation for new portal designs based on the data we assembled. I wanted to explore variations and multiple design concepts in the low-fidelity wireframes before spending a lot of time on visuals to match the Johnson Controls Element design system.
I setup three rounds of usability tests with five participants each to gauge their comprehension of how to use the portal with the redesigned functionality. I tested the overview page as well as the trends & comparative page (which used to be separate tabs) and got their overall thoughts on the information contained therein.
It was important to test these ideas with our users in the early stages of design to make sure we were on the right path with our solutions and thereby reducing re-work later in high-fidelity design and development.
Some changes made after testing
The current workflow the techs use to diagnose chillers involves jumping back and forth between multiple applications, creating comparative graphs and trend graphs that don’t correlate with each other, and then somehow matching that up with events (active and historic faults) to make sense as to why chillers are displaying problems.
None of this information was in the same timeline, so they had to manually piece together bits of information from various sources to construct a maintenance recommendation to their team. The updated diagnostics page solves these problems by addressing key functionality such as:
We showed the designs to the Principal Engineer and other members of the Building Services North America team, who initially declined to be involved in research efforts due to time constraints and found that the chiller status table workflows did not fully meet their expectations.
They need to work with thousands of chillers in their portfolios and later asked for specific requirements in the designs that we hadn’t considered related to isolating which chillers to focus on.
Even though we had users from other global regions who we gathered data from and were able to design solutions with, we should have pushed back more when we couldn’t gather enough research from BSNA. Each region has slightly different ways of working and this caused issues later in the process that could have been alleviated if we were able to speak with them.
To resolve this problem, we brought these key members from BSNA onto the project right away and communicated with them much more frequently to ensure that their needs were met. I went back to the drawing board on some aspects of the chiller status table, including filtering, various table columns for statuses, and an improvement to the drawer slide-out that shows the fault information on chiller rows in a tabular format.
After these changes are implemented, they were much happier with the outcome.
I moderated usability tests on the MVP build of the portal to learn whether specific workflows were intuitive and easy to use. Specifically, I wanted to know if the primary task to secondary task flow for more complex interactions was effective and not burdensome with the modal interactions I had in place (such as going from chiller diagnosis to notification rules).
The reason I used modals to accomplish this was that if the engineer had a lot of data setup doing chiller diagnostics and then they wanted to setup a notification rule, they could accomplish this secondary task without losing their place.
From chiller diagnosis primary task to setting up notification rules
Development noted to me that this data could not be saved to come back to, so to preserve it I used modal windows. However, since there are multiple interactions in the secondary task that can be done, it involved using nested modals.
I learned through testing that using nested modals wasn’t the optimal solution to this problem because:
In order to solve this problem, I looked into nested modal alternatives and came up with a solution using an infinite modal and popovers to achieve multiple interactions in the secondary task.
After multiple rounds of ideation, testing and feedback from stakeholders, I began creating the high-fidelity design concepts for the portal to match the Johnson Controls’ Element design system.
Since CEP is part of a larger application framework called OpenBlue, I needed to make sure that it matched the other applications visually and felt like a cohesive part of the platform.
Even though I routinely communicated with developers during the design process to get their feedback, I wanted to make sure that the design concepts I gave them were clearly annotated and they understood the new workflows.
I annotated functionality on all the key screens for the application and then used Zeplin flows to show the connections between them and how interactions worked. The regular communication we had as a team and this documentation significantly reduced the usual back and forth questions about functionality that can come up.