White circle
Case Study

Custom Reporting

Feature Add-on for Connected Equipment Portal

Custom reporting tools feature addon for Connected Equipment

Overview.

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.

Objectives.

Our goals for this project are:

  • Increase efficiency of generating custom reports and analysis to send over to internal stakeholders and customers.
  • Make the process easier to generate a report, create observations based on diagnostic findings, and then create a recommendation to submit as a service request.
  • Give engineers similar functionality in the portal that they use in external programs so they can operate on the same mental model and don't have to relearn processes.
  • Offer a better value proposition to customers viewing the insights from the recommendations sent from JCI. The current report sent over to customers is not user friendly, meaning they are full of data points and technical terminology that can be hard to understand. We need to give them a reason to act upon recommendations to maintain their chillers.

Who is creating reports and recommendations?

I already had familiarity with the people who would use reports and recommendations 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 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 metric engineers use to combine multiple statuses of how a chiller is performing into a single score that can help them identify problem areas faster.

Technician working on equipment

How and why do digital chiller experts create reports?

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

Creating new observations in the recommendation workflow

Reports and recommendations are generated for things like:

  • Monthly service visits and service agreements (these are opportunities to upsell for preventative maintenance as well)
  • Notifications to technicians that a chiller needs to be worked on
  • Communicating with customers why maintenance should be done

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.

Investigating the current workflow for report creation.

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.

“Seeing how they made reports using diagnostics from the chillers in real time allowed me to envision the frustrations they encountered at each stage.”
White quotes

Diagramming existing user flows and improving.

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:

  • Pre-configured report (saved to PDF)
  • Custom reports (currently done in Word based on a user created template)
  • Chiller Snapshot (generated data for a chiller based on an asset point from a trend graph) that shows when right-clicking a graph
How engineers created custom reports before redesign

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.

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.

  • Pre-configured report (previewed in the portal, add notes/recommendations, and THEN save). This means they don't have to download and reupload.
  • Custom reports (created in the portal using a drag and drop method similar to Squarespace that is based on a template)
  • Screenshot & Annotate (a new feature that allows the technicians to screenshot a graph, add annotations/notes to it, add recommendations and then save to the My Files area of the user account).

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.

Ideas for combining reports and recommendations.

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.

Drag and drop customized report
Drag and drop customized report

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.

Combining recommendations with the report
Combining recommendations with the report

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.

More workflow exploration for report creation.

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 continued exploration for how observations and recommendations would be stored in the portal as well as variations on the report layout.

Reworked aspects due to technical constraints.

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 drag and drop idea changed to pre-defined sections where users can still enter the content they need but made development easier.

Screenshot and annotate became document findings.

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.

A separate screen for non-power users
Non-power users

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.

Additional options for annotations
Options for annotations

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.

Usability testing the new workflows.

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:

  • Adding an existing observation
  • Adding a new observation (by graph, fault or already downloaded image)
  • Editing annotation summary
  • Adding attachments
  • Publishing the recommendation and sharing it with others

Overall, they were able to complete these tasks with no issues. I learned some interesting information from them as shown below.

Variations in chiller diagnosis by region
Variations in chiller diagnosis by region

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.

Updating publish recommendation screen
Reworked publish recommendation

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.

Finalizing recommendations.

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

Workflow from documenting findings, creating observations and recommendations, and then publishing

Viewing service requests on the dashboard
Viewing service requests on the dashboard

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.

Service request details screen
Service request details

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.

Creating the chiller report editor.

The report editor can be used to manually configure reports after they are auto-generated to add additional comments.

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:

  • Decreases the time it takes to generate a pre-configured report. The way it works right now is that you have to generate out the full report with every section included and it takes too long to load all of that information and generate a PDF.
  • With the report editor in the backend, it would load the content sections for the report one at a time as you clicked on them to edit. This alleviates the problem of having to load all of the content at once while doing diagnosis and decreases load times.
  • When clicking "Generate Report" at the bottom of the report editor to output a PDF, it would only be compiling the sections you selected versus compiling data that isn't necessary which reduces load times.

Report editor design exploration.

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.

Concept 1 for the chiller report editor was too busy
Report editor concept 1 was a little too busy

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.

Chiller Report Editor Idea 2 was the chosen idea
Report editor concept 2 was the chosen idea

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).

Report editor concept 3 wasn't flexible enough
Report editor concept 3 wasn't flexible enough

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.

Impact and insights.

1
Work in progress

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.

2
Exploration

I am 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.

Get In Touch.

Thank you for getting in contact with me. I look forward to speaking with you.
Oops! Sorry but something went wrong with sending your message. You can also contact me at alex@alexgcreative.com