UX DESIGN

SENIOR PRODUCT DESIGNER

multi-year project

B2B ENTERPRISE SAAS

Designing a Client Self-Service Platform for complex Administrative Workflows

A multi-year initiative to give enterprise HR and benefits clients direct control over their own platforms, replacing a supporting-ticket model with tools that made complex, rules-based configuration approachable for non-expert users.

4 -> 40

Tools built as the platform scaled

~10

Tools personally designed end-to-end

2

Tools built as the platform scaled

Tickets Replaced

Tickets that once required a support request are now self-service

PROBLEM

Clients had no direct control over their own platforms

THE SITUATION

The company provided benefits administration platforms to large enterprise clients, but even minor updates required clients to contact an internal team, open a support ticket, and wait. The process was slow, prone to miscommunication, and frustrating for clients who needed to respond quickly to changing organizational needs. It also created a significant operational burden internally and contributed to high call center volume.

THE SITUATION

The underlying capabilities already existed, built for internal teams with deep system knowledge. Simply giving clients access was not going to work. The workflows needed to be rethought from the ground up to be understandable, forgiving, and trustworthy for non-expert users.

THE OPPORTUNITY

Design tools that gave clients genuine confidence to act independently. Not by hiding complexity, but by making it legible. Each tool needed to help users understand what they were configuring and what it would affect, without watering down the functionality underneath.

GOALS

Four priorities that shaped every tool

Each tool started with a requirements walkthrough covering what it needed to do, how existing workflows were functioning, and where the pain points were. Weekly reviews with product and development stakeholders kept decisions grounded in both user needs and technical reality

01

Reduce reliance on internal support

Give clients the ability to complete common administrative tasks on their own, so that getting something done did not require opening a ticket and waiting for an internal team to act.

02

Make complex configuration approachable

Break down multi-step, rules-based processes into interactions that helped users understand what they were configuring and what it would affect, without simplifying away the functionality they needed.

03

Prevent errors without removing flexibility

Build in validation, guardrails, and clear system feedback so clients could work confidently in high-stakes workflows without needing expert knowledge to avoid costly mistakes.

04

Build something that scaled consistenly

Establish shared patterns that made each new tool feel familiar, so the platform could grow from a handful of tools to dozens without becoming harder to navigate or learn

Approach

How the work actually got done

Building consistency without a formal system

When the platform launched, there were four tools and a company-wide design system that was still maturing. Many components we needed did not exist yet, and there was no playbook for how the platform should look, feel, or behave. Each designer owned their tool end-to-end, but we met weekly to share what was working, surface point points, and align on patterns so the tools felt cohesive even while being built in parallel

As the platform grew, informal alignment was not enough. I pushed for creating a shared documentation file that captured the common patterns, interactions, and conventions that would define the platform. Not a formal design system, but a working reference that kept decisions visible and consistent as new tools were added and new designers joined. By the time the platform reached roughly 40 tools, the consistency was intentional, not accidental.

Making complex configuration understandable

Many of the workflows I designed involved multi-step, rules-based configuration with dependencies that could cause real problems if misunderstood. My approach was to use clear information hierarchy, progressive disclosure, and inline guidance so users could reason about eligibility rules, visibility settings, and system outcomes as they worked, rather than being confronted with everything at once.

Contributing back to the broader design system

Several components the platform needed did not exist in the company’s design system. Rather than building one-off solutions, I identified patterns worth contributing back. I personally led the design and delivery of a date picker and an upload component, writing documentation, presenting to the design system council, running accessibility reviews, and working directly with developers on interaction requirements and edge cases. Both were adopted into the broader system, extending their value well beyond the tooling platform.

DESIGN DECISIONS

Three patterns that defined the platform experience

Across ten tools, a set of consistent decisions emerged that reduced relearning, surfaced complexity at the right moment, and gave clients the confidence to act without support.

PATTERN 01

Shared patterns that reduced relearning

Shared table structures with advanced search gave users a familiar way to manage data across tools. Horizontal tabs organized complex functionality while keeping a predictable structure platform-wide. Keeping primary actions in consistent locations meant users always knew where to start, regardless of which tool they were in.

Tools featured a shared table structure, advanced search, horizontal tabs, and primary actions in consistent locations

A tab button lets the user switch between table views & a dropdown menu lets the user select the type of message. The design allowed for features to be added when complexity required it but the overall structure remained the same.

PATTERN 02

Stepping through complexity

For longer, rules-based configuration flows, a stepper pattern broke the process into understandable stages and helped users orient themselves within a complex task. Related inputs and guidance were grouped into subsections so users could process information incrementally.

Stepper creation flow used to help focus and orient users during more complex creation flows

For tools with simpler configuration flows, a single-page view is used to avoid adding complexity when it wasn’t needed. The pattern needed to match the task, not the other way around.

Single page creation flow

PATTERN 03

Guardrails that support autonomy, not limit it

Inline validation surfaced issues at the point of interaction so users could fix mistakes immediately without losing context.

Inline success message

Inline error message

Upload component states

An exit warning modal protected users from accidentally losing work.

Upload component states

A final review state before committing changes gave users a clear picture of exactly what they were about to do, which was especially important in high-risk workflows where a misconfiguration could have downstream consequences.

Final step in the creation process lets you review before completing

“Knowing there was a safety net, that the system would catch mistakes before they became problems, gave users the confidence to move forward rather than second-guess every decision.”

“Knowing there was a safety net, that the system would catch mistakes before they became problems, gave users the confidence to move forward rather than second-guess every decision.”

OUTCOMES

A platform that kept earning investment

The clearest signal that the platform was working was that it kept growing. What started as four tools expanded to roughly forty over the course of the project, with continued investment in building out new capabilities. Clients were moving from a model where even small changes required a support request, toward one where they had direct, confident control over a meaningful part of their own experience.

4 to 40

Platform growth as a signal of confidence

The platform’s expansion from four tools to forty, adopted across both private and public sector enterprise clients with complex compliance requirements, reflected sustained organizational confidence in what was being built.

Self-serve

Support dependency replaced with direct ownership

Tasks that previously required opening a support ticket and waiting for an internal team became things clients could complete on their own, on their own timeline. The tools shifted the model from reactive support to proactive client control.

2 Shipped

Components contributed to the design system

A date picker and upload component I designed and documented were adopted into the company’s broader design system, extending their value across product surfaces well beyond the tooling platform.

Consolidated

Third-party tools replaced

Several of the tools I designed replaced existing third-party applications, consolidating workflows into the platform and reducing external dependencies for clients.

OUTCOMES

A platform that kept earning investment

ON COMPLEXITY

Hiding complexity is not the same as solving it

The instinct when designing for non-expert users is to simplify by removing. What worked here was making complexity legible instead. When users could see what they were configuring and understand the downstream effects, they were more willing to act independently, not less.

ON CONSISTENCY

Consistency has to be maintained deliberately, especially as teams grow

Early on, alignment happened through conversation. As the platform scaled to 40 tools and more designers joined, that stopped being enough. Pushing for a shared documentation file was one of the more impactful things I did on this project, not because it was glamorous work, but because it meant every tool that came after benefited from decisions that had already been worked through.

ON HANDOFF

The handoff is part of the design

Having a dedicated meeting for developers to ask questions and get clarification after handoff changed the quality of what got built. Design decisions that might have been quietly interpreted away go discussed and resolved. The work does not end when the file gets handed over.

ON GUARDRAILS

Guardrails make users more confident, not more cautious

Validation, previews, and confirmation states did not limit what clients could do. They made clients more willing to do it. Knowing the system would catch mistakes before they became problems gave users the confidence to move forward rather than second-guess every decision. 

OTHER PROJECTS

Want to see more?

Check out my other work