ENTERPRISE PLATFORM
MITRATECH
Distributor Configuration Templates
As Tracker's partner channel grew, every new client onboarding required a distributor admin to rebuild ~50 API arguments from scratch, with no way to save prior work. They called support—every time. I led the UX design of Distributor Packages, which allows for configuration once and onboarding at scale.
MY ROLE
Product Designer
TEAM
PM · Engineering · QA · Services
PLATFORM
Internal Admin Tool
TIMELINE
0 to 1, single phase
FOCUS
Systems Design, Enterprise UX
Before
Open client record
↓
Set 50+ JSON arguments
↓
Validation errors
↓
Call support team
↓
Repeat for next client
After
Create Distributor Package once
↓
Assign package to client
↓
Configurations auto-applied
↓
Client ready for I-9
↓
Repeat: assign only
~50 args
→
3 args
Manual every time
→
Configure once, reuse
Support dependent
→
Self-sufficient
01 — Where It Started
Quarter after quarter. The same signal.
The same themes kept appearing in quarterly reports: onboarding delays, support overload, go-lives slipping. The brief I received: the API is too complex, simplify it.
Working with the PM and implementation team, we went back to the actual conversations behind those reports. What I found: distributors weren't confused by the API. They'd figured it out. They were calling because they were setting up the same configuration for the third time that month and missed one argument. The product had no memory.
The reframe
The quarterly reports weren't saying the API was complex. They were saying the product had no memory. Distributors needed a way to encode a standard setup once and apply it without rebuilding every time. That reframe changed the entire direction.
Current state — 8 clicks before configuration begins
1
Log in, open Admin Control Panel
2
Open Client List View
⚠ Growing client list means more time before any work starts
3
Open the client record
4
Navigate to Client Configuration
⚠ Multiple tabs — admins regularly clicked the wrong one first
Open the Features tab
6
Scroll to find the relevant section
Set all ~50 arguments manually
From memory, a previous project, or a personal doc kept outside Tracker
⚠ No way to copy a previous client. Every field from scratch, every time
8
Save and wait for QA
Errors surface days later. Repeat from step 1 for the next client.
⚠ Late error discovery. Support called. I-9 go-live delayed.
Why this problem first
Configuration similarity across clients
Client
Args configured
Similarity to previous
Support touchpoints
Client A
48
92%
3
Client B
50
89%
2
Client C
47
91%
3
Client D
49
94%
2
Teams repeatedly rebuilt nearly identical configurations. The variance was noise, not intent. The product had no way to encode what "standard" looked like.
Severity: High / Every onboarding
Manual configuration repetition
No way to save or reuse setups. Every client starts from zero even when nearly identical to the last ten.
Priority 1 — solved
Severity: High / Growing volume
Support team dependency
Every stuck distributor called in. Volume grew with the partner channel. Couldn't scale headcount to match.
Priority 1 — solved
Severity: High / Frequent
Configuration errors discovered late
Errors surfaced in QA, not at input. Client can't process I-9 forms until fixed. Compliance gap.
Priority 1 — partially solved
Severity: Medium
Deep navigation to configuration
8 clicks before any work begins. Time lost — not directly revenue-critical on its own.
Priority 2 — future iteration
02 — WHO WAS EFFECTED
2 Admins. 1 Bottleneck
This is an internal admin tool not a consumer product. Both users are technically proficient. They work under deadline pressure. They don't need onboarding.
Design context
Internal tool. UI budget was limited — the expectation was to reuse existing Tracker admin patterns, not design a new system.
Design Approach
Reused existing Distributor Roles components: same table structure, same accordions, same settings hierarchy. Familiarity over novelty.
Component reuse
No net-new UI patterns introduced. Every element maps to something already in the Tracker admin design system, making engineering delivery faster and adoption immediate.
User 01 — Primary
Tracker SysAdmin
Goal
Maintain consistent configurations across distributors without becoming a bottleneck as partner volume scales
Observed behavior
Keeps a Slack channel of recurring answers ready topaste. Context- switches between 4–6 distributor conversations simultaneously with no system support
Pain point
Answers the same configuration questions every week. Is the product's unofficial memory. No way to enforce standards systematically
Constraint
Cannot scale headcount to match partner growth. Expected to maintain quality as volume increases indefinitely
User 02 — Primary
Distributor Admin
Partner configuring clients. Resells Tracker and manages onboarding for their own client base under I-9 compliance deadlines.
Goal
Onboard new clients correctly without calling support. Keep configurations consistent across their growing client base
Observed behavior
Maintains a Google Doc titled "standard staffing client setup" and copies from it every time. Opens a previous client in a separate tab to compare line-by-line when debugging
Pain point
8 clicks to reach configuration. No way to copy a previous setup inside Tracker. Errors surface in QA after deadlines are already at risk
Constraint
Compliance risk if one argument is wrong. Client cannot process I-9 forms until the configuration is corrected
Indirect
Tracker Support Team
Goal
Focus on high-value enablement work, not repetitive configuration questions that the product should handle
Observed behavior
Has a copy-paste library of the 10 most common configuration questions. Recognizes repeat callers before the conversation begins
Systemic risk
Volume grows with the partner channel. Headcount does not. Every self-service failure in Tracker lands here
03 — WHAT WE FOUND & CONSIDERED
Discovery Firsr. Then Direction
This is an internal admin tool not a consumer product. Both users are technically proficient. They work under deadline pressure. They don't need onboarding.
Starting assumptions
We assumed
Simplifying the payload would reduce errors
Distributors needed better documentation
Support load was a training problem
The API was too complex for distributors to use correctly
What surprised us
Distributors had mastered the API. Complexity wasn't the issue.
Errors came from copying old setups — not misunderstanding fields
Most had documentation — kept outside Tracker in personal docs
Support was absorbing a product gap, not a knowledge gap
What changed
Stopped designing around API complexity
Started designing around operational repetition
The product needed memory, not simplification
Solution became Distributor Packages — not a simpler API
Research patterns
5/6
Admins reused previous setups
When onboarding a new client, most started by copying from a previous one. None had a way to do this inside Tracker.
4/6
Kept personal docs outside Tracker
Notion, Google Docs, Slack messages. The product's memory lived outside the product. When those docs drifted, errors followed.
73%
Support tickets from copied configs
Most errors weren't from misunderstanding the API — they came from copying a setup with one stale value.
2.3
Avg support touchpoints per onboarding
Even experienced admins needed support more than twice per new client. Not a competence problem — a product memory problem.
How I reached the insight
Observed
Repeated support calls with identical questions
Similar JSON payload structures across clients
Admins are keeping external setup docs
Implementation delays at the config stage
Pattern
Distributors recreating known configurations from memory
~90% field overlap across onboarded clients
The product has no memory of previous work
Insights
Problem = repetition, not payload size
The API wasn't too complex. The product was stateless
"I have a Google Doc with my standard setups. I've been using it for two years. Half of it is probably wrong now but I don't know which half."
Distributor Admin — discovery interview
Tradeoff matrix
Rejected
Concept A — Simplify API payload
Why it seemed right
Directly addressed the surface complaint. Fewer visible fields, cleaner integrations, better documentation.
Why we moved away
Removes enterprise flexibility distributors genuinely need. Doesn't address repetition at all — a 20-argument API still has to be rebuilt from scratch every client.
Rejected
Concept B — Progressive disclosure wizard
Why it seemed right
Reduces visible complexity. Good for first-time users who need guidance through unfamiliar arguments.
Why we moved away
Experienced admins already knew the arguments — a wizard slows them down. Still rebuilds from scratch every client. Reduces visual complexity, not operational complexity.
Selected
Why this was inevitable
Why this was inevitable
5/6 admins were already recreating known patterns every time. Packages formalized what they were already doing informally. Backward compatible — existing API still works. ~50 arguments reduced to 3.
Tradeoffs accepted
More engineering complexity. New governance flows for inheritance, overrides, and deactivation. Worth it — repeated patterns outweighed the flexibility cost of every alternative.
Tradeoff matrix
Direction
Flexibility
Complexity
Scalability
Support touchpoints
Reduce API fields
Low
Medium
Medium
Breaks existing
Progressive wizard
Medium
Medium
Low
Partial
Distributor Packages ✓
High
Medium
High
Full
Principle 01
Configuration knowledge belongs in the product
Any solution had to make Tracker the single source of truth removing the need for external docs and informal memory.
Principle 02
Governance must surface consequences before commitment
73% of errors came from actions taken without understanding downstream impact. Show consequences first.
Led to: Deactivation modal with client count
Principle 03
Extend existing mental models, don't introduce new ones
Internal tool. Technically proficient users. Familiarity over novelty. The feature should feel like it was always there.
Led to: Distributor Roles as the design foundation
Teams repeatedly rebuilt nearly identical configurations. The variance was noise, not intent. The product had no way to encode what "standard" looked like.
Before and after
Before — every client onboarding
1 Open API docs. Rebuild the JSON payload from scratch or copy from a previous project
2 Map ~50 arguments to the client's specific needs. Submit. Debug validation errors
3 Contact Tracker support. Wait. Go through this cycle 2–3 times
4 Client configured after multiple rounds. I-9 go-live is delayed throughout
5 Start the same process again for the next client, even when nearly identical
Delayed I-9 go-live · Support overwhelmed · Revenue idle
After — Distributor Packages
1 Create a package once with all settings a standard client type needs
2 Assign to a new client: ClientName, ExternalClientID, ExternalPackageID
3 Client inherits all configurations automatically. Override only what differs
4 No support call. Client ready to process I-9 forms
5 Next client: assign same package, override if needed. Work doesn't repeattributors recreating known configurations from memory
Faster I-9 go-live · Support freed up · Partner channel scales
04 — KEY DECISIONS
Where Judgement Mattered the Most
Controlled overrides vs strict inheritance
The most contested decision in the project
Engineering and PM both preferred strict inheritance, a simpler system, and cleaner governance. I pushed back after finding that 4/6 admins were already managing client variation in external docs. A rigid system wouldn't eliminate that behavior. It would just make it invisible.
Tension
Strict inheritance meant a simpler system. It also meant every client variation required a whole separate package.
My observation
Variation at the client level wasn't an edge case. A rigid system wouldn't eliminate it — it would push it into spreadsheets outside Tracker.
Tradeoff accepted
More complexity: inherited configs, override visibility, propagation rules. I accepted that cost. A rigid system that gets worked around isn't actually simpler.
Client Features page — Package Details at top, inherited configurations below, Change Package button. The override model live in the UI.
Designing safe deactivation flows
The highest-risk action in the system
Deactivating a package with assigned clients silently changes I-9 configurations for every attached client.
Engineering proposed a standard confirmation dialog. I pushed for something that surfaced downstream consequences before commitment. Here is the full decision flow we designed for:
Operational consistency over UI novelty
A deliberate constraint, not a compromise
This is an internal admin tool for technically proficient users. The brief expected UI to match existing Tracker patterns for faster engineering delivery. I embraced that constraint fully.
Tension
A custom interface might look more considered. For this user and context, it would add training overhead with no operational benefit.
My observation
Build on the existing Distributor Roles UI. Same table structure, same accordion patterns. Admins already knew it. Packages should feel like they were always there.
Tradeoff accepted
Less visual distinction. Faster adoption, lower training overhead, faster engineering delivery. In a compliance product under deadline pressure, familiarity is a feature.
Client level assignment
Not just template level, even from the client level we can assign
Use Change Package option to assign a different Distributor Package to the Client or assign new package if not existed
If no other active Distributor Packages are available for assignment, the Change Package button is disabled.
Export All Records to Excel Report
Generate an Excel report containing Client information and the assigned Distributor Package details
The system generates an Excel report that includes the Distributor Package assigned to each Client, if applicable.
Iterations
Iteration 01
Deactivation modal
V1 Problem
Simple "Are you sure?" dialog. In review, an admin clicked Continue immediately — assumed it was a standard save confirmation. No idea how many clients wereaffected.were affected
V2 Change
Added client count, two explicit radio options, explanation of each. Admins paused, read the count, made deliberate choices. The governance model works.and
Iteration 02
Package Details placement
V1 Problem
Package Details at the bottom of the page. Two admins in review began editing configurations without realising a package was assigned — about to silently break inheritance.
V2 Change
Moved to the top of the page. Admins now see package assignment immediately on load. No one edits configs without first seeing the package state.
05 — WHAT WAS BUILT
4 Sub-Features. One Phase
Edge cases designed for
Transfer client between distributors
Client retains original package assignment. New distributor must explicitly reassign. Prevents silent configuration inheritance from the previous distributor's package.
Deactivate package with active clients
System surfaces client count and requires explicit choice: keep existing assignments or reassign to another active package. No silent state changes.
No active replacement packages available
System warns the admin before allowing deactivation. Designed to prevent orphaned client configurations with no valid package fallback.
Client-level override conflicts with package update
Package updates propagate to all assigned clients except fields with client-level overrides. Override acts as a shield - package changes don't overwrite intentional client customisation.
ExternalPackageID provided alongside individual field arguments
API returns 400 Bad Request. Cannot mix package assignment with individual field configuration in the same call. Forces a clean separation of concerns.
ExternalPackageID set to null
Removes the package association from the client. Client reverts to direct configuration mode. The Assign Package container reappears on the client Features page.
LAYER 01
Distributor Packages UI
Create and manage reusable packages. 7 configuration sections: Product Configs, Email Settings, Site Settings, Password Rules, Logo, System Messages, General Info. Activate, deactivate, export.
LAYER 02
Client Features Page
Package Details container at the top. Assign Package and Change Package modals. Override individual settings at client level. Direct configuration still supported.
LAYER 03
Component reuse
ExternalPackageID reduces Create Client from ~50 arguments to 3. PATCH supports update or removal. Fully backward compatible — existing method still works.
Assign New Package — one dropdown, one selection, entire package applied automatically. ~50 arguments reduced to 3 in practice.
06 — OUTCOMES
What changed…
Single phase, available to all distributors immediately, with no feature flag. Numbers from the API specification or post-launch team observation.
~50→3
Arguments per client
A distributor using packages needs only ClientName, ExternalClientID, and ExternalPackageID. The 50-argument payload became optional. Verified from API specification.
Fewer
Routine support questions
Support team reported fewer repetitive configuration questions post-launch. Distributors who adopted packages were self-sufficient for standard setups.The support
4
Sub-features shipped
Packages UI, Client Features updates, POST and PATCH enhancements, Logo inheritance with a 4-tier System/Distributor/Package/Client model. All in one phase.
Post-launch signal
The implementation team reported a clear shift: fewer repetitive configuration questions, more complex enablement conversations. Distributors who adopted packages reported faster go-lives. Within weeks, distributors who hadn't yet adopted were asking when they could start.
07 - MY ROLE
What I drove. What we built together.
I personally drove
Reframing the problem from API simplification to operational repetition
Advocating for controlled overrides over strict inheritance
Workflow architecture — packages UI and client-level experience
Governance UX: deactivation flows, warning states, reassignment behavior
Implementation reviews and design QA through release
What surprised us
Overall product initiative scope — PM-led with design input
API architecture decisions — engineering-led
Propagation rules and conflict handling logic — engineering with design review
QA test coverage and release criteria — QA-led with design support.
08 — REFLECTION
What I'd do differently.
Override usage exceeded expectations
Most clients had at least one override. This validated the decision. Strict inheritance would have forced a significant share of clients into separate packages.
Bulk reassignment became an immediate ask
The future consideration from the original brief became the top feature request within weeks. Should have been scoped into the first release.
Test override interactions earlier
The override UI still exposes more system complexity than it should. Earlier testing with Distributor Admins before build would have caught this.
Package version history in scope
Admins have no way to see a package before an edit. For a system where changes propagate to every assigned client, audit history should have been in the first release.
09 — TAKEAWAYS
Four decisions worth remembering.
The brief described a symptom. The real problem was underneath it.
The brief said: simplify the API. Accepting that would have produced a simpler API. Going back to the actual support conversations revealed the real problem — operational repetition, not payload complexity. That single reframe changed what got built entirely.
I chose complexity over rigidity — and it was the right call.
PM and engineering both wanted strict inheritance — simpler to build, easier to govern. But 4/6 admins were already working around the product's inflexibility using external docs. A rigid system wouldn't eliminate those workarounds. It would just make them invisible. Accepting more complexity in the data model kept configuration decisions inside Tracker where they belong.
Renaming the feature changed how the whole team designed it.
Configuration Templates and Distributor Packages describe the same thing technically. But templates are blank documents you fill in. Packages are complete things you assign. Changing the name shifted the team from thinking "simplification tool" to "delegation system" — and that distinction shaped every downstream design decision.
Two of the most important UX decisions came from watching, not designing.
Moving Package Details to the top of the Features page came from watching an admin scroll past it and start editing configs without knowing a package was assigned. Adding client count to the deactivation modal came from watching an admin click Continue without reading the warning. Neither was in the spec. Both were critical to the system working correctly.