This project was a feature add-on for the OpenBlue Connected Equipment portal after it's initial launch. Chiller engineers use reports and recommendations to communicate their diagnostic findings on machines to other stakeholders and customers of Johnson Controls.
The manual steps they need to follow for creating custom reports and recommendations reduce efficiency, which costs Johnson Controls time and money. In addition, there is the risk of losing data or having trouble finding information because recommendations and reports are scattered across teams and computers and not centralized in the CEP.
Client: Johnson Controls
Timeline: Work in progress
My Role: I am the primary UX designer on the project where I collaborate with the Principle UX Designer, Senior UX Researcher, Product Manager, Commercial Program Manager and other stakeholders on the global team to redesign the reports & recommendations workflows and interface.
I already had familiarity with our users from doing initial research on the main Connected Equipment Portal design. On that project, I interviewed subject matter experts from Building Services North America to find out who were the primary users of CEP and learned about additional users from global regions. Then, I conducted user interviews with these team members to identify pain points and struggles in their workflows. I also observed how they completed tasks and where problem areas occurred.
Chiller engineers are the people diagnosing issues on assets for customer facilities that need maintenance. They do this by filtering down to chillers with a red CPI (Chiller Performance Index) to isolate alarms and faults that contribute to downtime and cost customers money.
The CPI is an internal tool engineers use to combine multiple statuses of how a chiller is performing into a single score that they use to quickly identify problem areas.
After engineers diagnose chiller issues and find out what problems need to be looked at, they communicate these findings to other stakeholders to get approval and buy-in. Then they can send the recommendations over to the customer and build a service request from them.
The reason for generating reports is to document what is happening on the chiller, pull out raw data from assembled graphs on the trends & comparative views, and then add in their analysis/comments to explain why maintenance should be completed on the chiller. It helps on-site technicians clarify to the customer why a service request is needed at the customer facility.
It also helps the branch technician understand what is going on with the chiller before they arrive so they already have familiarity with the problem and can fix it more efficiently.
Reports and recommendations are generated for things like:
By conducting user interviews and contextual inquiry, I researched how chiller engineers communicate asset information to stakeholders. Seeing how they made reports using diagnostics from the chillers in real time allowed me to envision the frustrations they encountered at each stage, and where they had to do a lot of repetitive manual work.
Since their portfolio of chillers is so large (sometimes over a 1000 chillers), manual tasks to create reports add up quickly over the workday. Inefficiencies in this workflow can cost them an extra 15-30 minutes per chiller to generate a recommendation, so it's really important to make this process more efficient.
Common issues we heard from engineers:
Lots of repetitive work that involves copying and pasting the same information into multiple locations for each report. Creating the custom report in word, copying and pasting that information back into the CEP, then copying that same information into Microsoft Teams for each chiller being diagnosed.
In order to communicate with other team members and schedule technicians to service customer locations, they use Nxgen or Servicemax (depending on the region) as their service request software. Currently, reports and recommendations cannot be connected to Nxgen or Servicemax.
I needed to find a way to integrate the reports with other functionality that they are tied to in the portal. Reports are accompanied by analysis/recommendations, notes, and graph screenshots for illustration purposes. However, they are not streamlined and work differently depending on the context of the report.
There are 3 methods technicians currently use for generating reports:
The problem is that the pre-configured reports and custom reports require a lot of manual work to create using tools that are not in the portal. They have to generate the report, download it, add their analysis/recommendations at the bottom, re-save it, go back into the portal, copy and paste the analysis/recommendations into the notes tab for the chiller, go into Microsoft Teams, paste the notes... you get the idea.
A lot of extra steps that wouldn't be needed if the portal automated that work for them, especially when there are so many chillers to work on.
The redesign could save the report, analysis/recommendations, and notify the relevant people when it was saved.
There are 3 methods that I came up with to solve these problems, the screenshot & annotate feature being the completely new addition.
All of these methods remove the need for external tools and then automates the process of saving the reports in the portal and then communicating out to team members about their status.
After speaking with members of the building services team, we realized that they don't create recommendations without reference and analysis to a particular part of the chiller they are servicing. They usually use a report or multiple graph screenshots to indicate what the problems are and what should be done about them.
Since the reports and recommendations functionality use basically the same content inputs, it made sense to combine these two features together and create one area where users can generate reports and also create recommendations for them.
Some great ideas came out of this exploration of combining the recommendation with report generation, particularly with the "customized report" features.
I explored more ideas for how observations, reports and recommendations would be handled in the portal instead of external applications.
The process for creating a report or observation was more complicated than I originally thought so I had to routinely include chiller engineers and technicians in our discussions to come up with solutions and get their feedback.
I wanted to keep the process to create recommendations very similar to the mental model that chiller experts already had to reduce confusion and learning time, so I designed it to be very similar to creating a template in Microsoft Word and annotating images using a desktop screengrab tool.
I ran into some issues when I showed these designs to developers on how the custom reports should work. Some features I worked on such as drag and drop and built-in image annotations were difficult for them to implement so I had to brainstorm how to solve these same problems but with a simpler workflow.
I came up with an idea that unfortunately removed some of the flexibility that users could use to arrange content in the custom report template using drag and drop but made it much easier to implement saving development time and money. I didn't remove any of the core functionality necessitated by the engineers but had to simplify the entry of content into the template for the portal backend.
By using pre-made content sections in the recommendations template, user error was reduced and database entry was simplified because the sections were standardized and didn't have so many combinations of content blocks that could be entered.
The custom reporting feature was more simplistic in scope earlier on in the project but after more investigation I found that there was a need for a more complex workflow for power users versus branch technicians. The engineers need more flexibility in how they generate reports versus branch technicians so two methods were created.
There is a workflow for creating only observations (using Screenshot & Annotate) which branch techs would use and then there is a power user workflow for creating an observation, creating a report, and then publishing options after that to share.
Initially, we called this graph screenshot feature to make observations "Screenshot & Annotate" because it's only purpose was to mimic the desktop snippet tools they used. However, since there is more functionality an engineer can do use with this feature, we called it "Document Findings" to encompass these interactions.
I ran usability testing with both engineers and branch technicians to find any problem areas with the newly designed workflows. I focused on creating an observation from scratch using a graph on the trends & comparative view, annotating it, and then making a recommendation based on it.
When they arrived on the recommendation screens, I was looking to see if these interactions were intuitive and easy to use:
Overall, they were able to complete these tasks with no issues. I learned some interesting information from them as shown below.
After more discussion and feedback from the engineers, I ended up on the final designs for the recommendations workflow. They can create their observations, insert them into recommendations, and then share it with people inside and outside the dashboard without using external tools.
Even though engineers usually use custom reports to communicate findings, there are times where they still need to use the pre-configured reports generated by CEP. Examples of this would be to get an idea of how a facility's chillers are performing over time quickly without having to create the graph images themselves or add their own observations. This is where the chiller report editor comes in.
The chiller report editor is based on a tool used in another OpenBlue Energy Manager product called Vibration Analysis. This tool allows analysts on that platform to analyze machines and then generate a pre-configured report but with customizable parameters.
These are some of the benefits the report editor offers:
I came up with three initial concepts to explore how content could be displayed in the editor that offered better usability than the accordion layout used in Vibration Analysis. One common complaint I heard was that users have to keep opening and closing the accordions to see what contents are inside and don't have a holistic view of the report being generated.
This project is still being worked on but I know from discussions with various stakeholders that the chiller report editor functionality I'm currently designing will be very valuable in generating automated reports that don't require a lot of user intervention.
Similar to how I designed the templated custom reports to automate manual repetitive steps, the report editor will do the same for pre-configured reports as well.
My team and I are exploring the benefits of how recommendations can be relayed from the technicians to the customers and what information will be most valuable for them to make decisions on how to address chiller issues.
For this project to be successful, we need the diagnostic findings on chillers to be actionable insights that customers will feel compelled to act on.