Defining Common Objects across EPM Product Suite
Events, Root Cause Analysis, and Work orders
This project was about designing for common objects that cross over multiple verticals (Warehouse, Buildings, and Industrial) within Honeywell Connected Enterprises. This project was an enhancement of a larger product initiative. This endeavor was part of a grander initiative to create a unified, intuitive 'single pane of glass' interface, enabling customers to seamlessly manage global operations and asset performance.
The Challenge: At the heart of this project were 'Events' - a crucial set of rules designed to alert users to system fluctuations. These events, coupled with comprehensive root cause analysis, empowered users to issue timely and effective work orders to address arising issues. The focus was on three pivotal objects: Events, Faults & Trends, and Work Orders.
Gone were the days when an alarm sounding off for temperature anomalies or toxin levels sufficed. Modern businesses demanded a deeper understanding of their operations. This project's narrative was about enhancing the lifecycle of an event - from mere notification to a holistic operational insight.
My role & responsibilities: Design researcher and strategist in a team of 2 designers. Time Spent – Approximately 2 months
Orchestrated the research and design strategy, shaping decisions that influenced the business and product architecture.
Led a three-week design workshop, a melting pot where stakeholders from product, design, and development converged. Dived deep into the world of our users, conducting usability studies, journey mapping, and contextual inquiries.
Worked in tandem with product teams across Honeywell, harmonizing our efforts to pinpoint and prioritize user research needs.
Conducted a thorough audit of existing applications to unearth users' pain points in two distinct domains.
Collaborated with content management teams to shape the product's information architecture.
In this role, I merged the art of storytelling with technical research, creating a narrative that not only informed but also transformed the way Honeywell approaches its enterprise solutions. This case study is a testament to the power of strategic UX research in driving product innovation and cross-functional collaboration.
The Approach - Workshop to create a common design strategy
8 sessions (Over 3 weeks) - 6 Teams, 6 - 20 participants
I partnered with the content management and information architecture team with the goal to bring the team to share a common taxonomy and ontology for the new product. . As part of preparing for the workshop, we created artifacts to be used in the workshop to bring visual hierarchy alignment to the objects.
Artifact for the team to understand the basic event workflow from the existing products
We conducted exercises that would help us understand, different teams and the way these objects are defined in the products they use. This helped us bring the ideas on one plane and gave us an opportunity to abstract these objects to create higher level definitions and a common object model.
After agreeing on common terms and definitions the next goal of the project was to start thinking about these components in the context of the product. We followed the Google Design Sprint framework and kicked off the two product teams to achieve a common challenge.
This phase started with setting a common goal that we wanted to achieve from this exercise and sharing user insights
Worked with the group to align expectation for what they are looking for, from this engagement and set a common challenge to keep the focus through the sessions
Understanding the current landscape:
In collaboration with another researcher, we did contextual interviews with SMEs and the sales teams from two verticals on how they think about the objects of events, faults, notifications, and work orders in their current products. Some of the questions asked for the interview were:
How do you define events in your organization?
Do you have the concepts of alarms and how is it different from events/faults?
What information do you have to know about events to be successful in your role?
Do you need to see past events? Why? What research do you do with the past events?
What are the current pain and frustrations (event/faults/alarm) in the product/s you are using today?
When do you expect to be notified about an event?
How do you prioritize multiple alarms on the same asset?
What existing event features are they using? Are they working well or poorly, and why?
Aligned on the personas we were solving for
User issues from two industries
Warehouse
Weekly event/fault readouts to the customer are difficult to generate.
Need to be on the floor to identify the problem.
No way to let the user know what problems are happening and when they happen.
Triaging faults and events.
Need to use multiple software to figure out the holistic picture.
Sorter operators can't always see issues on the line until there's a backup.
Site maintenance technicians don't notify appropriate parties in a timely manner.
Current warehouse journey
Industrial
Onboarding a new SME on the existing tool is difficult due to the lack of columns and the absence of user-friendly filters in the event log.
Absence of logical grouping of faults and symptoms.
Absence of action based on event category to assign it either to HW team or site.
Events generated during silent hours are lost.
Unattended events are increasing day by day.
The process is mostly manual and needs to be automated.
Need to hop on different applications to get the job done.
Current industrial journey
Current Root Cause Analysis Techniques
Mapping differentiation in how two industry users react to an occurrence of an event and gets to a problem resolution.
The Challenges:
The goal for the new product was to create a common understanding of these objects across two industries and collaborate with PMs and TPOs to manage complexity in their individual verticals.
Make the PMs empathize not only with the jobs users do use these objects in their industry but visualize the user’s journey across one Honeywell product.
Define the value of creating common objects across verticals and leverage functionality and scalability of development from other teams.
The next activity was to take common problems from the two industries and apply the ‘How Might We’ framework. This framework is a good way of constructing how-might-we questions while keeping teams focused on the right problems to solve.
How Might We and Prioritization Matrix
Based on the ranking we created the opportunities in Jobs to be done that would allow the user to use our product to accomplish the tasks that they are trying to do. This framework helps the team formulate a statement that explains the concrete value we intend users to gain from our products. The syntax goes: When [trigger event] happens, I want to [user action], so I can [outcome]. The activity was facilitated amongst three PMs, this resulted in selecting a few high-priority outcomes and mapping a common event journey for users across two domains.
Future State Journey
Current interfaces and future journey
User flows
MVO flow for Mid-fidelity wireframes:
The user gets notified about an event -> view the details -> do root cause analysis on the event -> release a work order for an event -> assign thee work order to technician -> receive notification about the work order completion -> track the $ value and downtime on the entire event -> view historical events and actions taken on them to do future predictive analysis.
Mid-fidelity designs
“Event overview is like a bird’s eye view, so if I am reliability or a maintenance engineer, I would like to look up for the first thing in the morning how many numbers of events are active and plan my work accordingly. ”
“From a tech standpoint, we like to keep it simple. During a downtime event, you’re getting drilled by multiple customers. Keeping it simple helps techs respond in these situations.”
Findings from the Test, Comparison between industrial and warehouse
The findings were taken by the product where they helped the design team work on priorities that matched both industry asks and feasibility from development.
High-fidelity designs
“A lot of events happen. Mx manager would spend all their time closing events. If the system has updated it systematically, Forge should close the event automatically”
“Similar to outlook I would like to see for last one month, what are the work orders we have worked on, what is the status and when it will be closed so that we can keep a track of all in-progress work together.”
Key Learnings
This was a very exhaustive project over a very short period. If given a chance to do this again I would have planned for resources and time in a more organized manner.
The sprint activities could have also been more spread out so that the participants could have also gotten more time to think through the problems and empathized with the user in a more realistic manner.
I would have also liked if the Forge leadership could have emphasized the vision of having one single product across different verticals more strenuously, rather than design carrying the weight of convincing the product of why we need to do this.
The designers were had very limited time to think through the designs because of the complication of the subject and did not get enough time to learn the problem space of warehouse and industrial.
I would have liked more time to surface the discrepancies within the maturity level between the two industries, so we could have had the opportunity to make designs that could have supported both intermediate and expert levels of UI based on the industry of the user.
The goal is to keep making improvements to the designs as it goes into the hands of the users.
Next steps
I am still working with the platform team to help them standardize the definition of these core objects to other industries. Working on collaboration and sharing the learning from warehouse and industrial verticals to cyber and buildings verticals.