From a complex manual backend to self-service interface
.svg)
The Challenge
Clients couldn't self-serve
Product couldn't scale
Comprehensive UX expertise
.svg)
.svg)
.svg)
Before...
.svg)
Hard to glance through a list to find the one you are looking for
Everything happens in one space, hard to distinguish between actions
.png)
Working manually in Excel is time-consuming and could lead to errors
Mauel edit can not be done in real time
.svg)
Old design which is not inviting to use
The hierarchy and dependency of actions is not clear
The approach
The Process
Discovery and requirements
The project manager led the discovery and gathered requirements. I collaborated on shaping those requirements into usable structures and workflows.
Foundational exploration
I sketched options on paper and figma to early concepts to establish direction and explore tradeoffs before committing to flows.
Exploration and technical alignment
Regular brainstorming sessions with the PM and lead developer before finalization. Discussed technical constraints early—understanding limitations, feasibility to shaped better solutions.
Founder collaboration
Once a foundation existed, the founder was able to articulate vision more clearly.My role was translating high-level intent into concrete, actionable product decisions.
Iteration & refinement
Designs evolved through feedback and engineering constraints. Adjusted designs as needed based on technical realities.
Building the Product Surface
Design system
I created a design system to give the product a clear, unified look and feel.
The founder brought strong product instincts and domain expertise, which needed to be translated into a clear and consistent design system. I based it on Material Design 3 foundations using MUI’s library, then customized with Ben Manage’s typography, colors, and tone, translating intent into a repeatable system.
.svg)
Admin and client environments
The product served internal teams and external clients with different responsibilities.
Admin work focused on company-level operations. Client work focused on client-specific actions. Both shared the same design foundations, with clearly separated capabilities and expectations. Distinct visuals made it clear which environment users were in and what they were responsible for.
.svg)
Navigation & structure
I shaped how functionality was organized so users could do their work without thinking in terms of backend architecture.
The structure reflected how work was actually done, not how the system was built. Making complex capabilities easier to access without oversimplifying them.
.svg)
Interaction patterns
Behavior adapted to the level of complexity, with clear preview and edit modes that made state and responsibility explicit. Users couldn’t accidentally change data — editing always required a deliberate action and an explicit save.
The goal wasn’t to spoon-feed users, but to make ownership clear.
.svg)
Product mapping
.svg)
Product mapping lived entirely in backend code. Defining company codes, conditions, multiple rules, and field-level logic required developer involvement for every change.
Most setups were simple, but the system also had to support complex conditional scenarios. The interface needed to support both without overwhelming the users
An inline editing model so that the setup was directly within the workflow, not in separate screens or modals.
- Simple setups remained lightweight
- Complex logic expanded within the same space
- Users never lost their place or context
This enabled power users to configure the mapping themselves quickly, accurately, and without relying on developers.
Dashboards & reporting
.svg)
Data existed, but it wasn’t visible or comparable in a usable way. There was no clear way to see what was happening across enrollments and campaigns.
Founders and account managers needed to understand performance at a glance, compare periods over time, and drill into specific cases—without relying on spreadsheets or reports.
I worked with the project manager on data priorities and designed dashboards that made enrollment trends, campaign performance, and case metrics visible and understandable.
Eligibility window
.svg)
Eligibility logic existed, but it was difficult to understand how rules affected outcomes. Changes required careful coordination, and it wasn’t always clear when or why a rule applied.
Account managers needed to control eligibility with confidence—understanding what rules were in place, when they applied, and what impact a change would have—without introducing mistakes or hidden side effects.
I designed a clear eligibility setup that made rules, conditions, and outcomes explicit. The interface surfaced when a rule applied and what it affected, so changes were intentional and traceable rather than implicit.
.png)
Results & Impact
Manual ops → product building
Dependency → self-service
opaque → measurable
Adoption & feedback
From the client
How did we manage without this?
.webp)
