Client:
Government Agency
Workstream 01
User ID Management
Unified 5 disconnected admin systems into a single management platform. Admin task completion time dropped approximately 60%. Bulk onboarding—previously impossible—now handles 500+ users in one operation. Wrong-user-assigned support tickets fell 42%.
The Problem
Enterprise admins on a B2B2C financial IWMS platform managed thousands of employees—but user management was fragmented across five separate systems: a user directory, a permission manager, an account linker, an assignment portal, and an authentication manager. Every task requiring more than one action forced 3–5 system navigations, averaging 8 minutes per operation.
The real cost: wrong users were routinely assigned to tasks because lookup surfaces showed names only—no department, role, or status. In a financial services context, assigning the wrong person to an access-controlled function is a compliance risk, not just an inconvenience. There was also no audit trail spanning all five systems, meaning no single view of who changed what.
My Role
Lead UX Designer
End-to-end ownership
Timeline
5 months
Discovery through handoff
Collaborators
Cross-functional
PM, 4 engineers, ops leads
Scale
10,000+ users
Across enterprise clients
Constraints
•
Technical: AG Grid Enterprise license already procured—the data grid was non-negotiable
•
Data: Legacy systems had conflicting user records; some fields were nullable or inconsistently populated
•
Accessibility: Section 508 required—all interactions must function without a mouse
•
Organizational: Could not restructure the underlying data model in v1—design had to accommodate the backend as-is
Impact
~60%
Reduction in task completion time
42%
Fewer wrong-assignment tickets
500+
Users in single bulk import
8
Platform modules adopted the pattern
Research & Insights
Three findings that directly shaped design decisions
Research Finding
In contextual inquiry sessions, admins averaged 4.2 navigation steps per user management task. Assigning a single work order required opening three separate systems in sequence. Users maintained a mental "breadcrumb trail" of context across system transitions.
Method: Contextual inquiry with 8 power admins over 3 sessions
Insight
The friction wasn't the number of clicks—it was the context-switching overhead. Each system transition forced a mental reset. Error rates were highest after 3+ navigation steps, when working memory was most taxed. The systems weren't designed together, so they didn't share enough context for admins to maintain orientation.
Design Decision
Design data architecture before UI. The unified API aggregation layer—pulling all user data in a single call—made single-surface management technically viable. Designed the API shape with backend engineers before wireframing. UI followed data architecture, not the reverse.
Research Finding
Support ticket analysis revealed 73% of "wrong user assigned" errors occurred when admins searched by name only. Multiple employees shared first names. In two enterprise clients, 12+ employees shared a last name. There was no disambiguation in the lookup surface—just a list of names.
Method: Support ticket analysis (n=340) + 6 admin interviews
Insight
Admins think in terms of names (social/human identifier) but need uniqueness from email + department (technical identifier). The cognitive model and the data model were misaligned. Fixing the lookup surface required aligning both—showing the human identifier users think in, plus the technical fields that disambiguate.
Design Decision
Contextual disambiguation pattern: All user lookup surfaces display name + email + department + status together. Users can search by any identifier. The display always includes enough context to distinguish ambiguous cases without overwhelming the interface. This pattern was codified in the design system and adopted platform-wide.
Research Finding
Usage analytics revealed two distinct admin profiles: power admins managing 100+ users per session (4 people, 12% of admin logins but 68% of actions) and occasional admins managing 1–5 users per month (40+ people). Their workflows and error profiles were nearly opposite.
Method: Usage analytics segmentation + role mapping
Insight
Power admins needed information density and keyboard efficiency—a Bloomberg Terminal model. Occasional admins needed guardrails, confirmation flows, and clear labeling. One interface had to serve both without overwhelming new users or slowing down experienced ones. This is a classic expert vs. novice tension in enterprise UX.
Design Decision
Progressive disclosure architecture: Default view optimized for occasional admins—clear labels, confirmation dialogs, conservative density. Power features accessible via secondary controls: keyboard shortcuts, bulk selection mode, column customization, saved filters. Enterprise density without forcing it on new users.
Key Decisions & Tradeoffs
The choices that shaped the system — and what I explicitly chose not to build
1
AG Grid as the data grid — accepting constraints rather than fighting them
Options Considered
A.
Custom table component (~6 months, full visual and accessibility control)
B.
AG Grid Enterprise — already licensed, immediate capability
C.
Simple HTML table with custom business logic
Why Option B
Timeline was 5 months. A custom table would have consumed 6+ months of engineering alone. AG Grid provides server-side filtering, virtual scrolling, and column management out of the box—exactly what 10K+ user datasets require. The license was already paid; rejecting it would have been waste, not principle.
Tradeoffs & How I Addressed Them
Limited visual customization — addressed with custom CSS token layer on top
Default keyboard behavior didn't meet Section 508 — required custom ARIA overlay and focus management override
Server-side sort/filter/pagination at 10K+ scale — would have taken months to build custom
2
Tabbed detail pages — depth over breadth
Options Considered
A.
Separate pages per section (profile, permissions, assignments...)
B.
Tabbed detail page — all sections in one place
C.
Single long-scroll page with anchored sections
Why Option B
Research showed admins rarely needed all sections simultaneously in one session. Tabs enable deep focus without scroll management. A single scroll page would have been ~2,000px with all 6 data domains. Separate pages would have reintroduced navigation overhead — contradicting the core design goal.
Tradeoffs & Mitigations
Risk: users miss content in non-active tabs
Mitigated: summary card at top of page surfaces key status from all tabs
URL-based tab state allows deep-linking from notifications and alerts
3
Full unification now vs. phased migration — the harder right
Options Considered
A.
Migrate all 5 workflows at once — high risk, complete behavior shift
B.
Phase: ship 2 workflows, add others over 3+ releases
Why Option A
Validated directly with 6 admins: a partial solution wouldn't change their behavior. They would still context-switch to old systems for uncovered workflows, negating the value of the new interface. Full unification was the minimum viable change to shift workflow patterns—not a feature, but a paradigm shift.
Tradeoffs (Honest)
Larger engineering lift and integration risk
In hindsight: phased with hard timeline commitments might have reduced risk without sacrificing the behavioral shift
Complete workflow adoption — no "fallback" to old systems meant full commitment
What I explicitly chose not to build — and why
Real-time collaborative editing
Proposed by engineering. Rejected for v1: conflict resolution for concurrent admin edits adds 6+ weeks. The use case—two admins editing the same user simultaneously—was extremely rare in session analysis. Deferred to post-launch roadmap with a trigger condition (concurrent edit collision detected).
AI-assisted user matching
Suggested for disambiguation. Rejected: the problem was solved by contextual display (name + email + department). Adding ML infrastructure for a problem with a simpler display-layer solution would be over-engineering and introduce latency in lookup flows.
Full mobile-optimized view
Raised by product. Analytics showed 0.3% of admin sessions on mobile. B2B admin tools are desktop-first. Responsive layout implemented for tablets. Full mobile optimization explicitly out of scope—documented with the data, not dismissed.
System Architecture
From fragmented touchpoints to a unified management platform
Before: Fragmented Across 5 Systems
4.2 avg. steps per task · ~8 min per operation · No unified audit trail
System Administrator
Navigates between systems for each operation type
User Directory
View profile
Permission Manager
Set access
Account Linker
Link accounts
Assignment Portal
Assign tasks
Auth Manager
Manage auth
Separate authentication per system
Data changes do not propagate across systems
No single audit trail
No bulk operations — manual user-by-user only
After: Unified Management Platform
1 system · 1 login · Complete audit trail · Bulk at scale
Presentation Layer
AG Grid User Management
User ID Detail Pages
Bulk Import Interface
↕
Service Layer — Aggregation API
User Management Service
Single call — all user data, 400ms
Async Processing Queue
Non-blocking bulk ops
↕
Data & Infrastructure
User DB
Auth
Permissions
Audit Log
Legacy Sync
Single login — complete user picture in one place
Server-side aggregation API reduces load time from ~3s to 400ms
Unified audit log across all operations
Bulk import handles 500+ users in a single operation
Design-Engineering collaboration note: The aggregation API wasn't an afterthought—it was designed collaboratively before any wireframes. I facilitated three architecture sessions with backend engineers to define what data needed to be available in a single API call. This shaped both the technical implementation and the design. The 400ms load time was a direct result of defining the API contract before the interface, not after.
User Identity Lifecycle State Model
Standardizing user states across the entire platform
Before this work, user states were named inconsistently across the 5 systems. "Inactive" meant deactivated in one system and pending activation in another. We defined a canonical 6-state model—ratified by product, engineering, and operations—that became the platform standard for all entity types.
This model was later adopted by Bulk Reporting, Alerts, Work Orders, and 4 additional modules.
✉
Invited
Admin creates user record
✓
Verified
Email link confirmed
⋯
Profile Pending
Awaiting profile setup
●
Active
Profile complete, access granted
⏸
Suspended
Admin or compliance action
✕
Deactivated
Employment terminated
Suspended ↔ Active (Reversible)
Admin can reactivate. Retains all permissions and history. Common use case: employee leave, compliance hold, account review.
Deactivated (Terminal in v1)
Irreversible in v1. All access removed immediately. Assignments preserved in read-only audit state. Requires new user record to re-enable. V2 roadmap includes archival with re-activation path.
Why 6 States, Not 3
A simpler Active/Inactive/Pending model was proposed. Rejected: operations teams needed to distinguish Suspended (temporary, reversible) from Deactivated (permanent) for compliance reporting. Granularity serves audit requirements.
User Journey: Admin Assigning a Task (Before the Redesign)
System Admin — Assigning a Work Order to an Employee
Persona: System Administrator — manages 200+ users across enterprise client org
Phase 1
Search for User
Actions
•
Opens user lookup modal
•
Types employee name in search field
•
Scans undifferentiated list of names
Pain Points
×
Multiple employees share the same first or last name
×
Only name is shown — no department, email, or role
×
No way to distinguish without opening each profile
frustrated
Phase 2
Verify Identity
Actions
•
Opens each potential match in a new tab
•
Navigates to User Directory to check email and department
•
Cross-references with personal notes or Slack
Pain Points
×
Must leave the assignment flow entirely to verify
×
Working memory resets with each system transition
×
73% of "wrong user" errors happen at this step
frustrated
Phase 3
Complete Assignment
Actions
•
Returns to the assignment form
•
Selects the user — best guess based on context
•
Submits without confirmation of identity
Pain Points
×
No identity confirmation before submit
×
No undo — errors require a support ticket
×
Error is often discovered downstream by the wrong person
neutral
Phase 4
Downstream Discovery
Actions
•
Wrong employee contacts admin to report the error
•
Admin files a correction request with operations
•
Operations team manually corrects the data
Pain Points
×
42% of wrong-assignment tickets traced to name disambiguation failure
×
Average correction time: 2–3 business days
×
Audit trail records the error, not the intent — compliance implications
frustrated
Design Process
1
1. Systems & Data Audit
Before wireframing, I audited all 5 existing systems to understand data models, API surface areas, and permission structures. This foundational work prevented rework and identified the data inconsistencies that shaped later design decisions.
Methods
System walkthrough sessions
API documentation review
Data model mapping with engineering
Deliverables
→
Current state system map
→
Data inconsistency log (23 fields flagged)
→
API capability matrix
2
2. Research & Journey Mapping
Contextual inquiry with 8 power admins revealed the context-switching pattern. Support ticket analysis (n=340) quantified the wrong-assignment problem at 73% name-only lookup. Both findings drove the contextual disambiguation decision.
Methods
Contextual inquiry
Support ticket analysis
Usage analytics segmentation
Deliverables
→
Current-state journey maps
→
Pain point prioritization matrix
→
User typology: power vs. occasional admins
3
3. Architecture & Technical Validation
Three architecture sessions with backend engineers before designing UI. Defined the API aggregation shape that made single-surface management viable. I co-wrote the API spec with engineering leads — UX requirements driving API design, not the reverse.
Methods
Architecture workshop facilitation
API design sessions
Technical feasibility reviews
Deliverables
→
Unified API specification
→
Technical constraints document
→
Performance benchmarks (400ms target)
4
4. Design Iteration & Stakeholder Alignment
Three rounds of wireframe review with product, engineering, and representative admins. Each round narrowed scope and validated feasibility. Presented high-fidelity prototype to senior stakeholders for sign-off — bridged UX language to business outcomes.
Methods
Iterative wireframing
Prototype testing with 6 admins
Executive stakeholder presentation
Deliverables
→
Low to high-fidelity prototype progression
→
Usability test findings (6 participants)
→
Final design specifications + component inventory
High-Fidelity Design Solutions
Unified User Management Grid
Replaced 5 system navigations with a single AG Grid interface. Contextual disambiguation—name, email, department, and role—visible in every row without opening a profile. Action dropdown consolidates all per-user operations.
after
After: Unified AG Grid System
Single interface for all user management operations — contextual disambiguation baked in
+ Add User
Bulk Import
Export
Search by name, email, or User ID...
User ID ↓
Name
Department
Role
Auth Status
Actions
USR-10234
Sarah Chen
sarah.chen@acme.com
Engineering
Admin
Active
USR-10235
Michael Johnson
m.johnson@acme.com
Operations
User
Active
USR-10236
Priya Patel
priya.patel@acme.com
Product
Manager
Pending
Showing 1–3 of 1,247 users · 0 selected
← Prev
Page 1 of 416
Next →
Disambiguation (Finding #2)
Name + email + department visible inline. Solves 73% of wrong-assignment cases without opening a profile.
Bulk Selection
Checkbox column enables multi-select for bulk operations — a net-new capability replacing manual user-by-user management.
Consolidated Actions
5 separate system navigations replaced by one dropdown per row. All operations accessible from a single interface.
User ID Detail Page
Clicking any User ID opens a comprehensive management view. Six focused tabs. Summary card at top prevents the "missed tabs" usability problem identified in research.
after
User Detail: USR-10234 — All management domains in one place
Tabbed detail page replaces 5-system navigation with a single focused view
Sarah Chen
USR-10234 · sarah.chen@acme.com · Engineering · Admin
Active
Email Verified
MFA Enabled
Edit Profile
More Actions ▼
Profile Info
Permissions
Assignments
Linked Accounts
Authentication
Activity History
Basic Information
Full Name
Sarah Chen
sarah.chen@acme.com
Employee ID
EMP-4421
Department
Engineering
Manager
David Park (USR-10198)
Last Login
Today at 9:14 AM
Quick Actions
🔗
Link New Account
🔐
Reset Password
✏️
Edit Permissions
—
View Assignments
⊗
Deactivate User
Unified management: All operations that required 5 system navigations are now accessible from this single page. Tabs are URL-addressable — notifications and alerts deep-link directly to the relevant tab.
Accessibility: Section 508 Compliance
Financial services platforms require full Section 508 compliance. AG Grid's default accessibility fell short in four critical areas—we had to override and augment. Below is what we changed, why, and how we validated it.
⌥ Keyboard Navigation Override
AG Grid's default keyboard behavior didn't meet Section 508. We implemented a custom focus management system on top.
Tab navigates between rows; Arrow keys navigate within rows
Enter opens User ID detail page; Space selects row checkbox
Escape closes open dropdown, returning focus to trigger element
Ctrl+A selects all rows (power admin efficiency shortcut)
🔊 Screen Reader: Custom ARIA
Status badges and action dropdowns required custom ARIA work on top of AG Grid's base implementation.
aria-label="User status: Active" — not just the visual badge
Actions menu: aria-haspopup="menu" with full option enumeration
Row context announced: "Sarah Chen, Engineering, Admin, row 1 of 1247"
Bulk import errors: aria-live="polite" announcement region
— Color + Contrast
Status indicators use both color AND text — never color alone (WCAG 1.4.1). All text meets 4.5:1 minimum contrast ratio.
Active: green badge + "Active" text + circle shape indicator
Pending: yellow badge + "Pending" text — distinguished from Active without color
Suspended: orange badge + "Suspended" label + triangle shape
Focus rings: 3px solid blue, 2px offset, visible on all interactive elements
📝 Form Error Handling
Bulk import CSV validation needed robust error communication for screen reader users managing large user sets.
Required fields: "required" text label, not just asterisk (*)
Inline errors linked to fields via aria-describedby
Bulk import summary: row number + field name + issue description
Tested with axe DevTools, NVDA, and JAWS before handoff
Design System Impact
Patterns that scaled beyond this workstream
User Identity Display Pattern
SC
Sarah Chen
sarah.chen@acme.com
Engineering
Admin
Used in 8 modules: Alerts, Assignments, Bulk Reporting, Work Orders, and more. Name + email + department + role in every lookup context. Resolved the disambiguation problem platform-wide.
Entity Status Badge System
Active
Pending
Suspended
Deactivated
Invited
Token-based badge system: Consistent color + text + border across all entity types. Color plus text ensures WCAG compliance — never color alone. Adopted for Users, Reports, Alerts, and Work Orders.
Contextual Action Dropdown
Actions
▼
Edit
Assign
Permissions
Deactivate
Adopted by 6 modules: Destructive actions always at bottom with visual separator. Keyboard navigable. Context-aware — shows only permitted actions based on user role.
Outcomes & Impact
42%
Reduction in wrong-assignment support tickets
Within 3 months of launch
~60%
Reduction in admin task completion time
Measured via post-launch session observation
500+
Users importable in single bulk operation
Previously impossible — manual only
8
Platform modules adopted the user display pattern
Design system platform-wide impact
~80%
Reduction in cross-system context switching
Fewer navigation steps per user management task
400ms
Page load for full user profile
Down from ~3s with separate API calls
System-Wide Impact
Design patterns established
The user identity display pattern and entity status badge system became platform standards. Eliminating the disambiguation problem platform-wide meant the 42% ticket reduction had ripple effects: every module that adopted the pattern reduced its own wrong-assignment rate.
Architecture impact
The API aggregation approach—designed collaboratively to support the unified UI—reduced page load from ~3s to 400ms. This architectural pattern influenced how 4 subsequent platform features were architected. Design drove backend decisions, not the reverse.
Reflection
What I would do differently
I pushed for full unification over a phased approach—and while the behavior shift worked, the risk was higher than necessary. A phased approach with hard public timeline commitments would have let us validate core patterns earlier and build trust before the full-scope lift. I was right that partial solutions wouldn't change admin behavior, but I underestimated the organizational anxiety that all-at-once creates for engineering teams mid-development.
What this taught me about enterprise UX
Starting with data architecture before UI design was the most consequential decision I made. The 400ms load time, the clean disambiguation display, the audit trail—all of these were only possible because we designed the API contract before the interface. In enterprise UX, the work you do before wireframing often matters more than the wireframes themselves.
How this shaped my approach going forward
The contextual disambiguation pattern—solving identity confusion at the display level rather than the interaction level—became a mental model I carried into Bulk Reporting, Alerts, and User Roles. When users are confused about "which thing is which," the answer is almost always adding display context to what's already visible, not redesigning the selection flow. Complexity at the data layer; simplicity at the surface.
In enterprise UX, data architecture decisions are design decisions. The 400ms load time, contextual disambiguation, and complete audit trail were only possible because the API contract was defined before the wireframes. The surface complexity you show users is inversely proportional to the backend complexity you build first.
