Enrich+
Ongoing
Enrich+ V2: Designing for workforce planning, staffing, delivery and revenue.
An enterprise platform connecting workforce planning, staffing operations, project quotations, capacity management and revenue forecasting across Publicis Sapient.
The problem
Making financial data easier to understand
Enrich+ is where workforce supply, client demand, delivery staffing and project economics meet and have to agree with each other. It is the system of record, not a resourcing tool bolted onto HR.
The Impact
Allocating one engineer to one assignment simultaneously reduces available capacity, closes a demand, changes a project’s delivery readiness, and books revenue at a specific rate. There is no single primary user and no single success metric — six domains use the same records to answer different questions.
The issue
One staffing decision moves capacity, delivery readiness and booked revenue at once. Operators could act — but not see what the action cost. The platform wasn’t confusing. It was expensive to use.
What I did
One staffing decision moves capacity, delivery readiness and booked revenue at once. Operators could act — but not see what the action cost. The platform wasn’t confusing. It was expensive to use.
Research
Understanding financial activity felt unnecessarily difficult
A discovery ramp session on 27 January 2025, then role-based persona work across the four operational roles that live in the platform daily.
The session produced a system model, a role map, a terminology glossary and a findings list — each finding closed with an explicit decision. That decisions list is why the redesign stayed coherent across fourteen modules and several squads: there was always a written answer to “why does it work this way.”
Abbi
Fulfillment
Gathers role requirements from account teams, then works with staffing to fulfill them.
Action buttons pushed off screen; hard to navigate to create or adjust roles.
01
Weak hierarchy
Balances and supporting details competed for attention throughout the interface and reduced clarity.
02
Inconsistent spacing
Grouping and inconsistent spacing slowed down dashboard scanning across everyday workflows.
03
Workflow friction
Important actions required extra steps to access transaction details and payment context.
Design
Design decisions
Four moves carried the redesign. Each one traces back to a research decision and forward to shipped design.
5 users
Small business owners and finance professionals.
45 minutes
Moderated sessions focused on dashboard workflows.
3 tasks
Reviewing balances, transactions, and payments.
What we learned
Through interviews and workflow analysis, I identified recurring patterns in how users reviewed balances, tracked transactions, and navigated everyday financial tasks. The biggest issue wasn’t financial complexity itself — it was uncertainty. Users often stopped to compare balances, reopen transaction details, or rescan multiple sections before taking action. Similar visual weight across the interface made it difficult to quickly identify what mattered most.
“Most of the time, I understood the numbers — I just didn’t understand what needed my attention first. I kept jumping between balances, transactions, and reports to make sure I wasn’t missing something important before taking action.”
Interview participant
E-commerce founder
Organizing recurring patterns and behaviors
I used Claude AI to help cluster interview notes, recurring frustrations, and behavioral patterns into broader themes. This made it easier to identify where users experienced the most friction across the dashboard experience.
Key insights
Users struggled to quickly identify the most relevant financial information.
Payments and recent activity lacked enough context before taking action.
Important actions became harder to find within visually dense layouts.
Similar visual weight reduced clarity across key dashboard workflows.
Understanding the user journey
I mapped the most common financial workflows to better understand where friction, hesitation, and repeated actions appeared across the dashboard experience.
01
Checking balances
Friction
Pending, available, and used balances were not clearly distinguished.
Opportunity
Introduce clearer balance separation with distinct visual hierarchy.
Impact
Improve balance scanning and reduce repeated checking behavior.
02
Seeing transactions
Friction
Payments and activity lacked enough context before actions.
Opportunity
Surface merchant details and payment status directly within activity flows.
Impact
Reduce uncertainty and help users understand activity faster.
03
Managing payments
Friction
Important actions became harder to find within visually dense layouts.
Opportunity
Simplify navigation patterns and prioritize key financial actions.
Impact
Improve task completion and reduce navigation friction across workflows.
04
Scanning data
Friction
Similar visual weight reduced clarity across dashboard sections and data.
Opportunity
Create stronger hierarchy between balances, activity, and supporting details.
Impact
Help users scan information faster and focus on what matters most.
Ideation
Exploring interface directions
I explored multiple layout directions focused on balance visibility, transaction context, and workflow clarity. Each concept tested different approaches to grouping financial information, simplifying navigation, and helping users scan important details faster.
Exploring different dashboard concepts focused on hierarchy, transaction visibility, and clearer everyday financial workflows.
01
Focused overview
Explored a simplified top-level summary with clearer balance visibility and primary actions.
02
Modular layouts
Tested flexible dashboard blocks to improve grouping, spacing, and information hierarchy.
03
Task-oriented flows
Structured the interface around key financial actions and recurring user workflows.
Testing interaction flows early
Before moving into high-fidelity designs, I tested early interaction flows using low-fidelity paper prototypes. These quick sessions helped validate navigation patterns, layout hierarchy, and task completion behavior before investing time into polished UI design.
The work
Fourteen modules. For each, the hard part — and what the design does about it.
Demand & requisition
Creating a demand meant navigating staffing, delivery, and approval workflows without clear ownership visibility.
Saved views, demand ageing, ownership tracking, approval history, and bulk updates brought critical context into a single workflow.
Saved views and ageing indicators eliminated the need to repeatedly rebuild context.
Saved views
Demand ageing
Approval history
Bulk updates
Nomination
Matching people to opportunities required balancing skills, availability, and business constraints.
The Nomination Workbench unified manual and automated nominations, eligibility checks, broadcasting, and future allocation visibility.
Teams could evaluate readiness, not just availability.
Auto-nomination
Preferred nominee
Broadcasting
Eligibility checks
Allocations & roll-offs
Allocation decisions directly impacted delivery commitments, capacity, and revenue.
Designed workflows for extensions, split allocations, roll-offs, bulk actions, and exception handling with full traceability.
Allocation changes became easier to review before they affected project performance.
Extension
Split allocation
Roll-off reason
Bulk actions
Supply
Workforce planning depended on knowing who would become available, where, and when.
The Supply Workspace provided visibility into bench populations, planned demand, future availability, and workforce distribution.
Staffing moved from reactive fulfillment to proactive planning.
Internal bench
Bench ageing
Planned demands
Capacity planning
01
Focused overview
Explored a simplified top-level summary with clearer balance visibility and primary actions.
02
Modular layouts
Tested flexible dashboard blocks to improve grouping, spacing, and information hierarchy.
03
Task-oriented flows
Structured the interface around key financial actions and recurring user workflows.
01
Focused overview
Explored a simplified top-level summary with clearer balance visibility and primary actions.
02
Modular layouts
Tested flexible dashboard blocks to improve grouping, spacing, and information hierarchy.
03
Task-oriented flows
Structured the interface around key financial actions and recurring user workflows.
Testing interaction flows early
Before moving into high-fidelity designs, I tested early interaction flows using low-fidelity paper prototypes. These quick sessions helped validate navigation patterns, layout hierarchy, and task completion behavior before investing time into polished UI design.
Designs
Designing for delivery
Fourteen modules, several squads, one product. What held it together wasn’t design review — it was infrastructure: a system engineering could build from, accessibility written as an engineering contract, and files structured so AI tooling could read them.
1 - The system
A library that made consistency structural
Tokens, light and dark theme values, typography, elevation, the icon system, component artboards on a shared grid — plus the working documentation the team actually needed: which modules were dev-ready, and how to bring project context into new files. Standardising terminology and iconography was a research decision; the library is where it became enforceable.
The foundation: tokens, light and dark theme values, type scale, elevation and component artboards on a shared grid.
2 - Accessibility
Written as an engineering contract, not a checklist
I authored the platform’s accessibility documentation: WCAG 2.1 AA and ADA alignment, ARIA rules, contrast and typography guidance for the dark theme, a component matrix covering Modal, Accordion, Tabs, DataGrid, Alerts, Tooltip and Select/Menu, and a stage gate across Design, Dev, QA and Release — Lighthouse ≥ 90, Axe, Storybook a11y, manual NVDA and VoiceOver.
The clearest example of the level it works at: in a permissions-heavy tool, a disabled control appears on nearly every screen — and the native attribute makes the explanation for it unreachable.
Instant card controls allowing users to freeze cards, manage limits, and update payment settings with minimal friction.
3 - AI-Assisted Delivery
Written as an engineering contract, not a checklist
We explored Slingshot, Publicis Sapient’s AI-powered delivery platform, as a bridge between design and development — replacing static specs and manual interpretation with something engineering could execute against.
Early results were mixed, and worth reporting honestly: generating from large-scale Enrich+ experiences produced hallucination and token-interpretation failures at enterprise scale. Those failures were the useful part. They specified the prerequisites, and output quality turned out to be a lagging indicator of design-system maturity — the model mattered less than the structure of what we fed it.
Consistent component naming
Design tokens
Variant management
Auto-layout usage
Reusable patterns
So the practice changed: away from bespoke screen-by-screen solutions, toward system-driven experiences both developers and AI tooling could interpret consistently. Later testing generated usable code from Enrich+ screens, and engineering used the outputs in implementation discussions. Slingshot didn’t replace engineering — it moved the conversation earlier.
In parallel we used Figma Make to explore before committing — workflow directions, alternative interaction models, staffing dashboard and resume concepts — testing feasibility before anything got componentised. The key lesson: AI concepts were only good when grounded in existing Enrich+ patterns. A blank prompt ignored the platform’s paradigm; existing references extended it. So I wrote the grounding procedure into the platform index.
A simplified dashboard focused on balance visibility, transaction context, and clearer everyday financial workflows.
Exploring different dashboard concepts focused on hierarchy, transaction visibility, and clearer everyday financial workflows.
Before & after
The redesign focused on improving clarity across everyday financial workflows by simplifying navigation, strengthening visual hierarchy, and surfacing more contextual transaction information throughout the experience.
01
Clearer balance hierarchy
Balances became easier to distinguish through improved grouping, spacing, and visual separation.
02
More contextual activity flows
Transaction details, merchant information, and payment states were surfaced earlier to reduce uncertainty before actions.
03
Simplified navigation patterns
Important actions became easier to locate through clearer layout structure and more predictable workflow organization.
Designs
Refining the dashboard experience
The final redesign focused on improving clarity across everyday financial tasks through stronger hierarchy, simplified navigation, and more contextual transaction feedback. The updated interface made balances easier to compare, actions easier to locate, and activity flows easier to understand at a glance.
Overview of spending trends, category insights, and budget usage designed for faster financial scanning.
Instant card controls allowing users to freeze cards, manage limits, and update payment settings with minimal friction.
A simplified dashboard focused on balance visibility, transaction context, and clearer everyday financial workflows.
Exploring different dashboard concepts focused on hierarchy, transaction visibility, and clearer everyday financial workflows.
Before & after
The redesign focused on improving clarity across everyday financial workflows by simplifying navigation, strengthening visual hierarchy, and surfacing more contextual transaction information throughout the experience.
01
Clearer balance hierarchy
Balances became easier to distinguish through improved grouping, spacing, and visual separation.
02
More contextual activity flows
Transaction details, merchant information, and payment states were surfaced earlier to reduce uncertainty before actions.
03
Simplified navigation patterns
Important actions became easier to locate through clearer layout structure and more predictable workflow organization.
Outcome
Outcome
User feedback centred on speed, responsiveness and usability — which maps directly onto what the research said was wrong. The complaint was never that Enrich+ lacked capability; it was that using it was expensive. Those three words are operators reporting that the cost came down.
Business Impact
Experience Impact
"Much faster compared to the previous version, more intuitive and user-friendly, it really helps improve efficiency in our daily work.."
Interview participant
E-commerce founder
"The system is incredibly fast & responsive, and having everyone in the same system is making communication a lot easier."
Interview participant
E-commerce founder
Users struggled to quickly identify the most relevant financial information.
"Much faster compared to the previous version, which really helps improve efficiency in our daily work."
Interview participant
E-commerce founder
"Much faster compared to the previous version, which really helps improve efficiency in our daily work."
Interview participant
E-commerce founder
Payments and recent activity lacked enough context before taking action.
Important actions became harder to find within visually dense layouts.
Similar visual weight reduced clarity across key dashboard workflows.
Lessons
What I carry forward
Record a decision against every finding
The most useful artifact from discovery wasn’t the persona set, it was the decisions list. Research that stops at insight gets re-litigated; research that ends in decisions gets built.
Simplification isn't removing complexity.
What worked was making the downstream effect of an action visible at the moment of the action. What failed, every time, was hiding complexity the user was accountable for.
Design systems are delivery systems.
Making Enrich+ legible to AI tooling required no compromise — consistent naming, real tokens, managed variants, clear hierarchy. The same structure that made generation viable made the platform maintainable.
Consistency across a federated build is a systems problem, not a review problem.
A shared library, documented tokens, an accessibility matrix and written patterns held fourteen modules together in a way no amount of design QA could have.
