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 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
Led research and service design across 14 modules; redesigned demand, nomination, allocation and bulk operations and built the system that made the work legible to engineering — and to AI tooling.
The problem
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.
When a project passes 95% probability in CPQ, its data crosses into Enrich+ and is issued a Project Identifier plus one Assignment Identifier per role. From that moment Enrich+ owns the record — so every operational decision inside it carries a financial consequence someone in finance must be able to defend.
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.
Capacity planning
Who becomes available next month?
Bench cost
Staffing
Which employee actually fits
this demand?
Delivery risk
Fulfillment
Which candidates should be nominated?
Cycle time
Delivery
Is this project fully staffed?
Slipped starts
Sales & quotation
Can we price this work
confidently?
Under-priced work
Finance
What revenue does this
allocation create?
Revenue leakage
C1
Density is a requirement
Users work in grids of hundreds of rows. Removing information would have made the product unusable. Make it legible, not smaller.
C2
Every action is a bulk action
Operators don’t edit one demand. They edit sixty. Single-record workflows were already broken.
C3
Mistakes cost money
A rate change, a roll-off, a backdated demand each carry an accounting effect. Errors must be visible and correctable.
C4
The build is federated
Modules shipped on different squads’ timelines. Consistency had to be designed in, not reviewed in.
V1 — critical actions below the fold, and a layout that didn’t scale to the window.
V2 — actions pinned and persistent, filters that survive navigation, same density with the hierarchy rebuilt.
The design problem was never “make the screens nicer.” It was: how do you let an operator act quickly without hiding the consequences of the action?
Research
Understanding financial activity felt unnecessarily difficult
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.
The discovery board: system model, role map, terminology glossary and the findings list — each finding closed with a written decision.
What we heard
Strikingly consistent across roles — and almost none of it was about missing features.
Critical actions sat at the bottom of the page and were hard to find.
Exports ignored the filters applied, forcing manual cleanup in Power BI.
Graphs didn’t populate reliably, took up space, and were routinely ignored.
No confirmation after key updates — users couldn’t tell whether the action landed.
Filters reset when navigating away — and users had to apply a filter or search times became unacceptable. The reset cost them real time, repeatedly.
This was not a product people found confusing to understand. It was a product people found expensive to use — every task cost more clicks, more waiting and more uncertainty than it should have.
Design
Design decisions
Four moves carried the redesign. Each one traces back to a research decision and forward to shipped design.
Exploration 1
Exploration 2
The direction that shipped
Three comparable options for the comments module. Stakeholders chose between trade-offs rather than approving or vetoing a single proposal.
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
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.
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.
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.
"Much faster compared to the previous version, more intuitive and user-friendly, it really helps improve efficiency in our daily work.."
"The system is incredibly fast & responsive, and having everyone in the same system is making communication a lot easier."
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.
