This project is 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 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, developers and other stakeholders on the global team to redesign the reports & recommendations workflows and interface.
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.
Creating new observations in the recommendation workflow
Reports and recommendations are generated for things like:
Custom reports (versus pre-configured reports) are used more often by engineers because they have more control over the content of the report and what goes into the recommendation. Pre-configured reports don't offer this flexibility and customization.
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 I 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:
How engineers created custom reports before redesign
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.
Creating a custom report after the redesign. Automation is used at the end of the flow to increase efficiency.
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.
An initial idea I had was to use a drag and drop interface that allows people to customize the report easily by using the content blocks on the left hand side.
This idea added "My Recommendation" to the bottom of the report generator so the engineer can describe what the problem is and then give a finalized recommendation before sending it off to the branch technicians.
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 continued exploration for how observations and recommendations would be stored in the portal as well as variations on the report layout.
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 drag and drop idea changed to pre-defined sections where users can still enter the content they need but made development easier.
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 use with this feature, I called it "Document Findings" to encompass these interactions.
For technicians who might only need to annotate a graph and save an observation, I made a separate screen that removes the "Create Recommendation" workflow.
I added in the ability to color code the annotations because engineers said they needed to signify importance by varying the color. This could, for example, be used to call out warnings or safety faults that are more important to observe.
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.
I found out that the regions created observations and reports slightly differently so I had to take those factors into account on my next design iteration. For example, engineers in the European region are using a graph that allows synchronous data on the timeline and gives them real time feedback on what is happening with a chiller component. The US team doesn't have this capability yet so this was the first I learned of it.
This is something I brought up to the development team as a need in the future that would really help their workflow since this graph isn't built into CEP.
I learned that users valued the ability to send recommendations to others without having to know what their emails are offhand. Initially there wasn't a method to share information in the portal directly.
I adjusted the publish recommendation screen to allow them to select people in the portal for sharing which saves time and reduces cognitive load. Their email and phone number would be stored in the database so it would automatically send them a notification by SMS as well.
If the recipient isn't in the portal yet, users can still share recommendations by manually inputting emails.
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.
Workflow from documenting findings, creating observations and recommendations, and then publishing
I modified the tabs on the dashboard view to include Service Requests. This allows the engineers to get a quick overview of the status of service requests without having to dig into individual chillers.
Due to not being able to sync data between CEP and NxGen, the engineer can also view non-CEP generated service requests from here as well. This saves them time because the link will go directly to the chillers they are responsible for without having to navigate there manually.
When the engineer views the service request in CEP, it shows them all of the details in a modal instead of having to navigate to the individual chiller pages and viewing the tab there.
It also shows a status from NxGen if this same service request has had any activity (like somebody working on the chiller). Even though we couldn't sync all of the data between the two platforms, we could still provide this status which is very helpful to remove duplicate efforts.
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 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. It allows analysts on that platform to analyze machines and then generate a pre-configured report but with customizable parameters.
The report editor can be used to manually configure reports after they are auto-generated to add additional comments.
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.
I didn't go with this concept because initial feedback was that users didn't know where to look first and seemed overly busy with the multiple navigation patterns in the left hand column and center.
I decided to explore this idea further because you get the preview of the contents in each card but constrained to the first few items. This decreases loading times so additional data is only displayed when the user clicks on that card to view it.
It also has the added benefit of being able to dynamically change the cards to fit each report without breaking the layout and being able to see the contents of the card before clicking on it (a major problem with the accordions).
I decided to pass on this idea as well because the "checkout steps" pattern wouldn't work for more than 7-8 sections in the report and would cause issues for text translation. The full width for the content area also doesn't allow room for the report history and access to the other chillers at the facility in the left hand column.
