Case Study
Connected
Chillers
Connected Equipment - Johnson Controls
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.
Chiller doctor and branch technician personas
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.
Originally, we wanted to combine all of the fault code language (status check, health check, panel codes, etc) and put them into three categories (critical, moderate and low) to simplify categorization.
The goal was to simplify the codes into criticality, but this didn’t make much sense at all to the technicians based on their current mental model, so we scrapped it.
The manage active points window for creating trend graphs was redesigned to remedy some issues with too many scrollbars, wasted white space in between graphs, and lack of labeling on both the selected points and the search functionality.
Lots of work was done on the configuration and sending of custom notifications. Being notified of alarms and faults to diagnose offline chillers quickly is of upmost importance to these technicians to reduce downtime and cost to customers.
The fault rules screen was redesigned to get rid of the previous accordion menu that was difficult to navigate. Instead, I used a left pane menu that would switch between the fault types and then the input points are displayed on the right to make them easier to find.
Fault rules are important for engineers to configure and set thresholds for when a chiller needs maintenance and be notified of it.
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
A preset manager section was added to the manage active points modal. When selecting points on a chiller to monitor, the techs can save presets of the graphs they have open and come back to the same preset later, saving time from setting up the graphs manually again.
They pointed out to us that they have to frequently waste effort re-creating graphs to use on multiple chillers with no way to replicate them.
“Smart Graphs” were added as an automation idea that would update the graph’s points based on which active fault is selected next to the graph timeline. The technician can use this data to see what was happening on the chiller at specific time intervals and pinpoint a cause.
One of the main issues technicians deal with is communicating between team members and other stakeholders that make decisions on how to handle chiller problems. They needed a way to communicate in the portal itself, either to teammates or technical support, to get answers quickly and resolve issues.
Chat messaging solves this problem by automatically assigning a technical support person to their facility. Their team is also available to chat within the portal, and they don’t have to use Teams or Outlook to communicate about diagnostic information. This reduces cognitive load from application switching and helps techs remain focused on the problem at hand.
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:
The events (active faults and historic faults) and graphs are synced together with the timeline so if they select a fault, the information displayed in the graphs is accurate to the timeframe selected.
They really liked this idea of syncing the data which makes it easier to pinpoint the cause of a chiller fault.
Workspaces work in conjunction with graph presets to reduce manual creation of graphs over and over again. The tech creates presets of existing graphs and then saves them into a workspace to retrieve later.
I heard many times how they didn't have the ability to reuse graphs which is inefficient and frustrating. Workspaces along with presets solves this problem on a per-user basis.
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.
I used a full screen infinite modal and popovers to eliminate the need for nested modal stacking. This allows more screen real estate to display data and work in. It refreshes the current modal window with new content instead of opening a new one on each interaction.
I used a popover for certain interactions such as the add notification selection. Popovers can be easily exited, the background isn't dimmed so the content is still seen for reference, and doesn't disrupt the task flow.
The infinite modal has a back button on each step to return to the previous step. The label on the back button changes based on what the last step was and keeps the user notified of where they are in the task flow.
At any time, the user can quickly exit the secondary task by clicking the close button on the infinite modal and if any changes were made to any of the steps, it asks for a confirmation to close so they don't lose progress.
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.
.jpg)
