Dell Product Support

The product support pages are the most visited pages on Dell’s support site. Every Dell owner, from a consumer troubleshooting a laptop to an enterprise IT admin managing a fleet of servers, passes through here. The original ask was narrow: redesign the Overview tab to prevent instances of empty content and increase engagement with what was already there.

That scope didn’t survive contact with the actual problem.

The redesigned product page across user states: consumer and enterprise, tagged and untagged, authorized and not.

The empty tab issue turned out to be a symptom, not the problem. When we started unpacking why content was missing, we found a complex matrix of variables controlling what any given user could see: five levels of user permissions, four distinct product types, and content that varied depending on whether we were showing an individual product model, a series, or a product family. The most valuable content of all, personalized diagnostics and service information, was only available when we had a specific serial number.

The real design challenge wasn’t “what do we put in the Overview tab.” It was: given all these variables, what is the right content to show to which user, in which state, and in what order of priority?

That question had to be answered before any page architecture or visual design could begin. Leading the product team and stakeholders through that content decision-making process became the central work of the project.

Where it started: the original consumer and enterprise product pages.

We started with an audit. At the outset there were three categories of content in play: what was already on the pages, what stakeholders wanted to add, and what we believed users would actually find valuable. Before designing anything, we needed to know which of those overlapped and which didn’t.

User input shaped the priority model. We brought in both consumer and enterprise users early to understand what they were looking for when they landed on these pages, and used that to build a content hierarchy that reflected actual need rather than internal assumptions about what mattered.

With priorities established, we mapped content availability against the full permission and product-type matrix. This produced a clear framework for what to surface, when, and for whom, and gave us the foundation to design page states that never felt empty, because every state was intentional.

The content and functionality matrices that governed every page state.

Testing ran across all four primary user states and both audience types. We validated findability of critical information, usability of key interactions, and comprehension of iconography and color usage. The process ran four rounds of iteration before we reached a result we were confident in.

Authenticated, serialized enterprise product: the richest state the page can reach.

Three months after launch, CSAT was up 28%, the self-support failure rate was down 37%, which took real volume off the support phone lines, and “Service Tag Not Recognized” errors were down 84%, getting people to their personalized page faster. That is what the content framework was for: every page state intentional, including the ones with the least to show.

I led design across the full project lifecycle, from problem definition and content strategy through IA, interaction design, and final UI. My most significant contribution wasn’t the visual work: it was leading the product team through the content logic decisions that made the design possible in the first place.

Who sees what, when, and why has been the recurring question in my enterprise work ever since. The same modeling drove the permission matrix on MyService360, the advisor platform at Schwab, and multi-location account management at Clover.

Lead product designerFunctional & content reqsInformation architectureUser flowsUI designUser researchResponsive design