Case Study

Honeywell Forge is a SAAS cloud-based application aimed at real estate portfolio owners and operators who need to optimise the performance and efficiency of their building portfolio. This case study focus on new functionality that allows a Portfolio Operator to remotely manage, investigate and resolve building maintenance issues faster without sending a maintenance team to site. This capability allows for -

• Faster response to building issues through direct control changes at portfolio level

• Reduced truck rolls for maintenance due to the ability to fix many problems without a site visit

• Re-focus workforce on value add activities – management is no longer needed at every site

The challenge

Traditionally Honeywell’s products in the building space split the control / configuration functions and the executive reporting into separate applications, the challenge was to combine the two in a seamless experience while mitigating the risk of an incorrect control change through the UI

Project duration

12 months and on going at the time of this case study.

Skills 

• Research and interviews

• Presentation of research to stakeholders

• Journey map and user task flows

• Iterative Prototyping

• Usability Testing

Tools

• Microsoft Teams

• Sketch

• Miro

• InVision

• Camtasia

• Jira and Confluence

Our Approach

The UX-team facilitated a discovery workshop with stakeholders from operations across the Honeywell business. As a starting point the team was provided with a poster depicting existing customer data and stakeholder knowledge. Targeted personas were identified.

The next step was to break the customer journey down into steps. Each step consisted of customer high points and pain points, Honeywell innovation opportunities, pain points; tech needs and key KPI’s. Based on these needs and pain points, stakeholders identified different scenarios and the UX-team created experience outcomes.

Final workshop artefacts were 3 posters with an 1) elevator-pitch; 2) product FAQs and a 3) product-in-a-box ensuring everyone could articulate the workshop outcomes. Based on the deliverables Project Managers and Product Owners created initiatives, epics and drafted a roadmap for delivery for the next 4 financial quarters.

Deliverables

The UX-team had to present a report-out of the workshop back to stakeholders, based on workshop outcomes the team created a prototype that would be tested with customers.

User Research

The business needed to validate the assumptions made in the workshop and UX needed to assess if our design concepts were correct and resonated with the market. We were looking for —- customer input on what features would be useful and what checks and balances would be needed to ensure a fail-safe user interface. As we were under deadline we had to follow an iterative approach to our research. We planned the sessions in different stages and updated our questionnaire and prototype as we received feedback. Due to COVID-19 we had to adapt and change our normal tools and process to collaborate remotely. We used Teams to setup and record the interview sessions, all artefacts were uploaded and documented in Confluence, collaboration and ideation were conducted in Miro.

RESEARCH GOALS

• Verify personas

• Verify validity of overall concept

• Verify MVO feature set

OBJECTIVES

1. Establishing the scope of responsibility for the selected personas and confirm the type of tasks that could be done remotely through the UI

2. Using a prototype validating our assumptions by testing various workflows with the participants.

EXAMPLE of research questions

• What type of customer want/need to centralise their operations?

• Is Portfolio Operator a valid persona?

• Is the ability to resolve a service case or alarm remotely valuable?

• What kinds of changes would an operator/tech make remotely?

• How large a region would a single operator manage?

METHODOLOGY

• Generative research - VOC

  • Facility Managers of customer sites

  • Portfolio/Building Operators at customer sites

  • Honeywell data scientist team – use a similar triage process for analytic alerts to determine which should be converted (or grouped) to a service case

  • Honeywell Supervisors and Service Technicians – currently responsible for triaging and responding to service cases on sites

• Usability testing

We conducted iterative testing, updating our prototype as we received feedback.

• Test using an Invision prototype for a POC product

• Test using an Invision prototype for a MVO product

INSIGHTS

We created a journey map to highlight user pain points, needs and opportunities across the on-boarding process. All our research was documented on Confluence to ensure that stakeholders had access to the research and the UX-team could justify design changes made to the prototype.

DELIVERABLES

• Confluence page with all research artefacts and findings

• PowerPoint presentation with research findings

• A report out session to stakeholders

• Identify new and update current personas

• Amended prototype incorporating feedback from various sessions

• Journey map documenting user needs, pain points and business opportunities

• User flows focusing on the high-level scenarios and specific tasks

• Update high-level design intent (prototype) based on feedback from customers

Outcomes

The UX team presented the results internally to Honeywell Forge stakeholders. Product Owners used the findings of the journey map to create epics. Based on the epics the scrum teams estimated the work and committed to what could be built from quarter 1 to quarter 4. This formed the delivery roadmap for the new feature.

Opportunities were identified for Honeywell through our research -

• Sales could identify potential business opportunities e.g. the solution would be better for a “cookie cutter” site where equipment are made to specific specifications rather than an old site / building.

• If the system is configured correctly at on boarding, Honeywell will save time and money in sending out maintenance teams

Takeaways:

• In order to make a successful control change, the user needed a lot of contextual information

• Research identified the key pieces of information that needed to be instantly available in the UI, no progressive disclose

• There was a need for feedback mechanisms from the system without too much intrusion.

• The ability to make and access “notes” when making control changes was critical

• The role and permissions allocated to a user would have impacts within the system, as not everyone’s equally capable of safely making changes.

• Remote work has been done before – but we designed the UI to make it easier, safer and more relevant for the user.

Next Steps

Need to validate our findings with more research