contact

enterprise configuration system_

Scaling Configuration in a Live Enterprise Platform

Redesigning configurable systems for a legal operations SaaS that outgrew its original design, without breaking what was already in production.

role
Product Designer
sector
Legal Operations SaaS
focus
Enterprise Configuration UX
type
Redesign · live system
status
Shipped
2
at-risk enterprise clients renewed
4
patterns shipped to production
Live
in active use across enterprise accounts
The Modules Settings, showing a module's status list with trigger configuration separated.

tl;dr / 30-second version

the problem

A developer-led platform grew fast. Configuration, statuses, filters, custom fields, views, became inconsistent and hard to reason about for enterprise clients running real operations on it.

my role

Sole designer on this workstream, end to end: from mapping client requests to shipped patterns, working directly with the PM, CTO and engineers.

what shipped

Modules Settings, Status Triggers, behavior-grouped Filters and Saved Views, live and in active use across enterprise accounts.

the result

Two enterprise clients at risk of churning renewed their contracts. Both renewals involved workflows this work directly addressed.

shipped / in motion

The flows, running in production

→ Real flows from the shipped product. Each recording shows the pattern in use, not a prototype.

Modules Settings overview

Status lists across Matters, Contracts and Licenses, showing the separation between structure definition and trigger configuration.

Filter panel: grouped categories replacing a flat list

Date, amount, people, status and custom field types, each with its own interaction logic.

Export flow

Contextual export action surfaced at the Permits & Licenses section level, tied to the user's current view context.

context

A platform built for speed, not scale

The platform is a legal operations SaaS built to help enterprises manage contracts, entities, and compliance workflows.

Early on, it was developer-led and shipped fast. That speed won clients. But as those clients migrated real operations into the platform, the gaps left behind became blockers.

I joined at this inflection point

Not to redesign from scratch, but to address design debt in a live product with real clients depending on it, every day, in production.

my role

Where I owned the problem

  • Mapped recurring client requests and support patterns into design problems
  • Defined the interaction architecture for settings, triggers, filters and views
  • Explored and pressure-tested alternatives with PM and engineering before building
  • Designed within the existing design system: extensions allowed, deviations not
  • Followed each pattern through delivery and post-release client feedback

The team around it

Me
Product Design
Product Manager
Priorities / clients
CTO
Architecture
Engineers
Delivery
Customer Success
Client signal

constraint landscape

Four forces that shaped every decision

These weren't obstacles. They were the actual design problem.

/01

Interconnected modules

A change in one module cascades into others. Statuses, fields and views cross module boundaries.

/02

Mixed user sophistication

Same interface, different mental models: legal admins, paralegals and ops leads configuring the same system.

/03

Live system

Nothing could break existing client workflows. Every change shipped into active enterprise operations.

/04

Design system

Extensions, yes. Deviations, no. New patterns had to be expressible with existing components.

Working within the design system forced me to solve problems through structure and interaction logic, not visual novelty. That constraint shaped everything that follows.

discovery

Reading the system before touching it

There was no formal research team. The signal existed, it just lived in different places.

Client & support signal

Clustered the backlog of configuration requests from enterprise accounts into recurring patterns, and worked with Customer Success to find where clients repeatedly got stuck: filters, statuses and exports.

System walkthroughs

Mapped how statuses, custom fields and saved views actually connected under the hood, with engineering, to see which changes rippled where.

Session recordings

Watched how admins really navigated configuration screens: where they hesitated, backtracked, or abandoned a setup halfway.

What the signal converged on

Clients weren't asking for more features. They were asking, in different words, to understand what a configuration change would do before committing to it.

Each configurable element is a node in a larger operational graph. A status triggers automations and affects visibility. A custom field breaks filter logic if poorly structured. A saved view captures state that can become inconsistent as data evolves. The challenge: users needed to understand not just what they were configuring, but what consequences it would have across the system.

core tension

Enterprise configurability demands depth. Enterprise usability demands clarity. These two goals live in constant conflict, and the design has to manage that conflict, not eliminate it.

design decisions

Three problems, three structural responses

Not just what was built, but why the alternatives were considered and set aside.

/01

Structure first, behavior second

modules settingsstatus triggers
Option A — considered

Single unified screen

Create statuses and their triggers together, in one place. Fewer screens, but every decision carries automation weight from the first click.

Option B — chosen

Progressive separation

Define structure first, then behavior. Statuses exist on their own; triggers attach as a second, deliberate step.

why this direction

Status triggers cascade into notifications, assignments and visibility rules. Combining both surfaces forces users to think about consequences before defining structure. Keeping them separate also lets the trigger layer evolve independently as automation complexity grows.

/02

Filtering by behavior, not by name

filterscustom fieldssaved views
Option A — considered

Flat alphabetical list

All filters in one list, A to Z. Simple to build, hard to reason about: a date and a person sit side by side as if they worked the same way.

Option B — chosen

Grouped by data behavior

Filters grouped by how they behave: dates, amounts, people, status, custom fields. The structure itself teaches the mental model.

why this direction

Different filter types behave differently: date filters use temporal logic, amount filters use operators, people filters use membership. Grouping by behavior helps users build the right mental model of how the system reasons.

/03

Export as a contextual workflow action

entities exportlicenses & permits
Option A — considered

Export inside existing modal

Keep export where it already lived, buried in a settings modal. Zero new patterns, zero new risk, and zero improvement.

Option B — chosen direction

Contextual action at table level

Export surfaces where the decision actually happens: while viewing the data, tied to the user's current view context.

why this direction

Users decide to export while viewing data, not inside settings. Surfacing it contextually reduces interaction distance. The trade-off was a new interaction pattern: the team adopted it incrementally, preserving existing architecture short-term while treating contextual actions as the future direction.

recurring theme

Many enterprise UX problems are not screen problems.

They are workflow coordination problems: where actions appear, when users expect them, and how much operational context they retain when they act.

validation

How we knew it worked

In a live enterprise system, validation doesn't happen in a lab. It happens in rollout discipline and in what clients do next.

01

Pressure-tested before build

Every direction was reviewed with PM and engineering against real client scenarios before a line of code. Some options died here, which is exactly what this step is for.

02

Incremental rollout

New patterns shipped module by module rather than platform-wide, so any friction would surface in a contained scope with a clear rollback path.

03

Client feedback loop

Post-delivery feedback arrived through Customer Success channels. All shipped features originated from client requests, and the responses after delivery were positive, with clients adopting the new patterns in active workflows.

04

Iteration on signal

Early feedback on filter group labels led to renaming passes so categories matched the vocabulary clients already used internally. Small change, real adoption difference.

outcomes

What shipped and what it meant

shipped

Live and in active use

Modules Settings, Status Triggers, Filters and Saved Views, running in production across enterprise accounts.

validated

Grounded in client demand

All features originated from client requests. Positive feedback via Customer Success after delivery.

scalable

Patterns, not one-offs

Status/trigger separation and behavior-grouped filters are now reusable patterns across modules.

business impact

During this period, two enterprise clients at risk of churning renewed their contracts. Both renewals involved workflows this work directly addressed.

Renewals are never one factor. But when the workflows named in churn conversations are the same ones this work rebuilt, design has a seat in that outcome.

reflections

What this work taught me about designing in live systems

/01

Design debt is structural, not visual

The real debt wasn't in the UI. It was conceptual: mental models that hadn't been designed, inconsistent patterns, configurations that didn't reflect how users thought. Fixing visuals without fixing structure creates cleaner debt, not less debt.

/02

Constraints are design material

Working within the design system forced problems to be solved through information architecture and interaction logic, not new components. Those solutions are more durable and transferable than custom UI.

/03

Configurability and clarity require active management

The real challenge is sequencing: foundational decisions first, operational complexity only when users are ready. Progressive disclosure isn't a technique. It's a philosophy about cognitive bandwidth at each stage of a workflow.

with hindsight

What I'd do differently

measurement

Instrument earlier

Usage analytics on configuration screens arrived after the redesign started. With baseline data from day one, I could quantify the improvement, not just evidence it through renewals and feedback.

access

Push for direct client sessions

Most signal came mediated through PM and Customer Success. Even two or three direct sessions with client admins would have shortened the loop between hypothesis and confirmation.

documentation

Write the pattern rationale down

The reasoning behind each pattern lived in conversations and files. A short written rationale per pattern would have made the system easier to extend after my involvement ended.

Want to discuss the work in more detail?_

Additional context about my process, design decisions, and responsibilities can be discussed during an interview.

Get in touchLinkedIn
vm_
private access
restricted case study

This work is shared privately.

Some project details are protected due to confidentiality. Enter the password provided to you to view this case study.

Press Enter or use the button below.
← back to selected work
confidential case study