The dashboards reliability engineers actually needed

CompanyHoneywell
RoleUX Designer
Problem

Broken affordances, unclear hierarchy, and no way to drill into individual asset health. Asset Details didn't exist.

Outcome

SUS scores reached the high 80s on Asset Health and Asset Details through research-driven iteration

Three years on Honeywell's APM platform meant working on tools that reliability engineers at companies like Shell depended on to prevent equipment failure. The work I'm most proud of is the research I led for Asset Health and Asset Details: two dashboards I took from low usability scores to high, through primary research, iteration, and usability testing at every step.

Final screens are de-branded recreations. Honeywell NDA prevents showing real client data. This page covers the research process and design decisions behind the work.

The problem

Reliability engineers at companies like Shell depend on these dashboards to catch equipment failures before they happen. A missed signal doesn't just mean a delayed report. It means unplanned downtime, costly repairs, and in industrial settings, potential safety incidents. The existing Asset Health dashboard was getting in their way. The visual hierarchy was unclear, affordances were broken, and the KPI organization made it harder than it needed to be to see what actually needed attention. Asset Details didn't exist at all. Engineers had no way to get a complete picture of an individual asset's health in one place. Every drill-down was a dead end.

The work

Led research for both Asset Health and Asset Details. Used the research team's past screeners as a starting point, then wrote new interview scripts and usability test designs for UserTesting, including concept testing and moderated sessions. Completed Dovetail's course on writing interview scripts and running moderated tests to sharpen the process. Ran usability sessions at each major iteration to validate design decisions before moving forward. For Asset Details, research and early testing supported a tab-based information architecture, breaking Reliability, Maintenance, and Performance into separate views to reduce cognitive load. The PM and subject matter experts pushed for a single-page layout showing all data at once. Advocated for the tab approach based on user research, but the decision went to single page. That tension directly shaped the three-level modular structure: a way to manage that complexity on one surface without overwhelming the user. Worked within an Agile team across sprint planning, design reviews, and dev handoff. Also supported other designers across the platform with iterative design feedback throughout.

Research: Screener & Interview Script

Asset coming soon

Photo: recreated screener or interview script in Figma or Notion

I wrote the screener and interview script from scratch, using the research team's past work as a starting point. I took a Dovetail course on writing moderated test scripts specifically to sharpen this. I wanted to make sure I was testing the right things and asking questions that didn't lead participants.

Synthesis: Affinity Mapping

Asset coming soon

Video: Miro affinity map walkthrough

After each round of sessions I'd pull all the observations into Miro and run an affinity mapping exercise, grouping findings by theme to surface patterns across participants. This is where the actual design decisions got made. If users kept stumbling on the same thing, that became a priority.

Asset Details: 3-Level Modular Structure

Asset coming soon

Photo or video: system diagram or annotated Figma frame

The three-level structure covers Reliability, Maintenance, and Performance. It came out of a combination of research, SME conversations, and iteration. My research supported a tab-based layout to keep cognitive load manageable, but the PM and subject matter experts wanted everything on one page. This modular breakdown was how I designed for that constraint without overwhelming the user.

Asset Health: Redesign Iterations

Asset coming soon

Video: Figma frames showing redesign progression

Asset Health already existed when I got to it: broken affordances, unclear hierarchy, KPIs organized in a way that buried the most important signals. I redesigned it, updated the color usage, fixed affordances, and reorganized the KPI hierarchy. Mid-fidelity designs started in the low 70s on the SUS. Each round of testing pushed them higher, reaching the high 80s.

Key design decisions

Push back with data, then redirect when the call is made

Problem

Research with maintenance and reliability engineers supported a tab-based IA. Users valued compartmentalization and the ability to scan each domain without visual interference from the others. The PM and SMEs pushed for a single page: users needed to compare Reliability, Maintenance, and Performance data without navigating between tabs.

Decision

Pushed back via calls and emails, with user quotes, documented Dovetail data visualizations, and firsthand findings. When the decision stayed with single-page after sustained advocacy, redirected the design energy into the three-level modular structure as a way to manage that complexity on one surface.

Why

The research position was defensible and worth arguing for. But when a decision is made and doesn't move, the job shifts from advocacy to problem-solving. The modular structure addressed the stakeholders' comparison goal while using clear visual hierarchy to manage the cognitive load tabs would have handled through navigation.

Test at every major iteration, not just before shipping

Problem

Asset Health had broken affordances and unclear hierarchy when I got to it. Asset Details didn't exist at all. Without a structured testing cadence, there was no way to know whether changes were actually improving usability or just changing it.

Decision

Ran usability sessions on UserTesting at each major design iteration. Tracked SUS scores across rounds to measure progress, not just collect qualitative feedback.

Why

Scores don't improve through intuition. Each round surfaced specific friction points that directly shaped the next design. The progression from the low 70s to the high 80s was cumulative: every session produced findings, every finding produced a change.

Reflection

The tab vs. single-page debate is the decision I think about most from this project. I had the data. I had quotes from engineers saying they wanted their domains separated. I pushed back on multiple calls and in writing. The decision still went the other way. What I learned is that research advocacy and stakeholder decision-making operate on different timelines, and sometimes the right move is to stop fighting the constraint and start designing through it. The modular structure was a better answer to the real problem than tabs would have been anyway.

Available for work

Let's build something great together.