Rebuilding Settings for Enterprise SaaS

The problem

Finding a specific setting was genuinely hard. Everything lived on a few very long pages, so people scrolled, lost their place, clicked back and forth, and frequently gave up and contacted support. Settings had quietly become one of the more frustrating parts of the product, and the support queue showed it.

Starting from the data

I began with the evidence: existing usage data, user feedback, support tickets, and live customer sessions. I mapped all of that against a UX and UI audit of the current settings, which surfaced clear, repeating themes around where people got confused.

The real decision: how should this be structured?

The heart of this project wasn't visual, it was structural. I prototyped and tested three different ways to organize the whole thing: the existing approach of a few long, scroll-heavy pages; a combined variant with a side menu and more clickable options; and a settings landing page that let people drill down into focused sections.

I ran usability tests and customer research on all three, benchmarked against the live product. The drill-down landing page won clearly. It matched how people actually looked for settings: find the area you care about, go in, do the thing, get out, instead of hunting down a wall of options.

Building the winner

With a direction locked, I restructured the entire settings information architecture around core workflows like staff availability and service management, and built a component-based system to support it. I wireframed the full set of pages so we could feel the new structure end to end, then made sure all of it held up across devices.

The result

The final design was tested internally and with select enterprise customers on live feedback calls, and built for performance, scale, and clarity.

Outcome

• Settings-related support tickets dropped by almost 20%.
• Time spent on availability settings fell from 5m 20s to 4m 05s on average, about a 23% speed-up.
• The new component framework let us roll out new settings modules quickly.
• The structure became a proven foundation for future settings work.

My role

I was the sole designer, working with one PM, two front-end engineers, and one back-end engineer. I owned the research, the structural decision, the component system, and the rollout, and I drove the call to rebuild the information architecture rather than just reskin the existing pages.

Impact

Settings 3.0 turned a scroll-heavy maze into something people can actually navigate. Adding new settings is now straightforward, because there's a tested, scalable structure underneath instead of another long page to bolt onto.