Device Support Portal

Company:

Eaton Corporation

Role:

Senior UX Designer

Tools:

Figma, Miro, Jira

Shipped:

2026

The Pivot

Recognizing When to Stop and Rebuild From a Stronger Foundation

The Device Support Portal began as a proof of concept built by an engineering team. What was delivered functioned technically but lacked the user-friendliness and scalability needed for a real product. The right move was to stop, evaluate the gaps through research and stakeholder alignment, and start over with a proper UX foundation, which is exactly what we did.

Background

A Product Already in Motion

When I was brought onto the Device Support Portal, engineering had already started building. The product was meant to give Eaton Support staff and internal developers a single place to manage device issues, run diagnostics, and access support tools across Eaton's IoT ecosystem.

The initial build worked technically. But the requirements had been gathered without validation through any UX methods, and the support and development staff who would actually use the tool were never looped in at the start of the process. As a result, the workflows were fragile, the information architecture was built around system logic rather than user mental models, and there was no clear path to scaling it as the product suite grew.

Research

Getting The Right People In The Room

Before proposing anything, I needed to validate the problem beyond my own read of the existing build. I ran interviews with Eaton Support staff and internal developers, the two user groups the portal was built for, and structured the sessions to surface how they actually worked, not how the system assumed they worked. Through those conversations I was also able to identify the existing tools each group relied on, understand how they used them day to day, and recognize that consolidation was the real opportunity. Bringing those tools together into a single, unified interface would allow users to send commands and diagnose issues without jumping between systems, and do it in a way that was actually user friendly.

The user interview findings were consistent across both groups. Workarounds had become the norm, and it became clear that what was really needed was one unified system. Users knew where things were only because they had learned to navigate the existing complexity over time, not because the process was intuitive or easy.

A significant gap that surfaced was how support staff actually handled customer calls. The existing system allowed users to jump directly into device troubleshooting, which worked in isolation, but when a support person is on a call with a real customer, the natural starting point is the customer themselves, finding their account, their home, their schedules, and their devices before ever getting to diagnostics. The original build had no path for that. Building the portal around that mental model, starting with the customer and working inward, became one of the most important structural decisions of the redesign.

The Decision

Making the Case to Rebuild

I brought the research findings to the product and engineering team with a clear recommendation: the existing build wasn't a foundation we could design around. It needed to be rebuilt from the ground up, with the user workflows driving the architecture rather than the system logic.

That wasn't an easy conversation. Engineering had already invested significant time. The proposal meant accepting that work had to be redone. There was real pushback.

But the research was concrete. The friction points were documented. The gap between what users needed and what the product currently offered was specific and measurable; not a matter of opinion. The team eventually aligned, and we started over with a shared understanding of what the product actually needed to do.

Process

From Research to Rebuild

Outcomes

Reflection

What I Learned

The biggest design decision on this project happened before I designed anything in Figma. Recognizing that the existing build was the wrong foundation, and presenting UX findings so clearly that the team agreed to pivot, required a different kind of design thinking than wireframing does.

Research gave the argument its weight. Without specific, documented evidence that users were struggling in measurable ways, the recommendation to rebuild would have been an opinion. With it, it became a business case. That distinction matters, and it's one I carry into every project now.

It also reinforced something about working on small product teams: the people building the thing are capable of hearing hard feedback when it's delivered with evidence and respect. Pushback isn't a sign the argument is wrong; it's a sign the stakes are real.

A note on process: this page was built with the help of Claude and Claude Code. I actively use AI tools to move faster and focus my energy on the design decisions that matter most.