case study 03 / traact modules settings_
Redesigning configurable systems for a legal operations SaaS that outgrew its original design, without breaking what was already in production.
Role
Product Designer
Focus
Timeline
2025 – 2026
Status
● Shipped
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.
context
A platform built for speed, not scale
Traact 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.
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
/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 Settings
Status 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
Filters
Custom Fields
Saved 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 Export
Licenses & 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.
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.
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.
Next case
Perle AI →