Enter password to view case study
Enterprise platform design & process innovation
Scope
Global contract management platform
Role
Lead UI/UX Designer
Duration
18 months
Team
UX Manager, Project Manager, Business Analysts, Engineers, Scrum Masters
At PwC, I identified a systemic problem: design and development were working in silos. Developers received designs late, discovered issues during build, and rework extended delivery timelines by 10-15%.
I created a collaborative workflow on an internal API marketplace project that brought developers into design reviews from day one, establishing documentation standards in Figma and Azure DevOps. The workflow reduced delivery time 10% and improved consistency 25%. After proving impact, it was adopted company-wide through PwC's design center of excellence.
Beyond process innovation, I led design across PwC's contract management ecosystem: a unified engagement platform merging two systems, AI-native onboarding, validation network tooling, and strategic vision work that shaped product roadmap decisions.
10%
faster delivery
25%
improved consistency
12
territories researched
This case study describes my process and contributions while respecting confidentiality. Specific system names and internal details have been generalized.
The Challenge
PwC's engagement management ecosystem turns client opportunities into billable engagements across every global territory. It handles risk assessment, financial analysis, compliance validation, and recurring contract management.
When I arrived, the system was fractured. Two separate platforms — one for opportunity validation, one for engagement management — were supposed to work together but didn't communicate well. The business wanted them merged into a single unified platform.
The Problems
01
Siloed Teams
Design worked in isolation. Engineers received designs late in the process with little context. Business stakeholders dominated conversations while technical constraints went unheard.
02
Broken Handoffs
The design-to-development handoff was a wall, not a bridge. Design was expected to provide static wireframes. Developers discovered issues mid-build. Rework was constant.
03
No Global Perspective
The platform served consultants across dozens of countries, but design decisions were made from a single office with little understanding of how different territories actually used the system.
04
Scope Creep Without Strategy
Features were added based on whoever spoke loudest in meetings, not based on user research or strategic prioritization.
Global Research
We were given a loose project scope and told to immediately jump into rapid design development. My UX manager and I pushed back. We argued that designing a global platform without understanding how different territories actually use it would create solutions that worked for no one.
The Approach
We split our efforts strategically: my UX manager led global research while I managed stakeholder expectations with design deliverables, buying us the time we needed. I was her right hand throughout. I attended every workshop with middle office teams from 12 territories, reviewed all Zoom recordings and Copilot transcripts, and synthesized insights through Condens that shaped our approach to regional flexibility vs. standardization.
01
Some Regions Had It Figured Out
Certain territories didn't want us touching the system. It worked beautifully for them. This told us: don't break what's working. Design for flexibility, not uniformity.
02
Local Laws Created Friction
Several territories struggled with recurring engagements because the system didn't account for local financial regulations. What worked in one region created compliance nightmares elsewhere.
03
Others Built Workarounds
Some regions had created homegrown solutions to fill gaps the platform didn't address. We studied these workarounds to understand what the system was missing.
04
Shared Teams, Mixed Data
Some territories share operations teams across borders. Their engagements sometimes got mixed up because the system wasn't designed for cross-territory collaboration.
05
Fragmented Visibility Across Roles
Multiple teams within each territory worked on interconnected tasks, but had no shared view of overall progress. This insight directly informed the dashboard concept: teams needed a single source of truth, not scattered information across multiple views.
Not every territory can get custom features. But understanding regional differences helped us prioritize solutions that served the broadest set of users.
Process Innovation
The product work mattered, but the biggest impact I had at PwC was identifying and solving a systemic collaboration problem.
A few months in, I noticed a pattern. Figma was new to PwC and most projects had just transitioned from Adobe XD. Developers got their information from Azure DevOps and expected static mockups as attached images. They weren't accustomed to collaborative design processes.
Business dominated every conversation, telling teams what to build and expecting execution. Designers and developers worked in silos, with no voice in decision-making. As a result, we dealt with a lot of late-stage rework, QA discovering issues after development, and endless revision cycles.
I created a new workflow on an internal API marketplace project, not because it was my job, but because I saw an opportunity to make cross-functional teams more effective.
The Old Process
Business defines requirements in a meeting, documents in ADO.
Design creates static mockups in Adobe XD.
Mockups get approved in meetings, developers often absent or silent.
Approved designs delivered as PNG screenshots attached to ADO tickets.
No documentation, no interaction specs, no context.
Developers build in isolation, discover issues mid-development.
Back-and-forth revisions, QA finds more issues, endless cycles.
What Was Broken
Designers created static mockups in Adobe XD, delivered them as PNG screenshots with no documentation, and developers built in isolation. Feedback came too late, QA discovered issues after development, and revision cycles were endless.
My Solution: A 7-Stage Process
Briefing
Business, design, and dev leaders align on complete requirements before sprints begin. Everything documented in Azure DevOps. Scope changes move to new sprints, forcing clarity upfront.
Sandbox
Designers explore concepts in Figma, iterating through low-fidelity ideas before committing to high-fidelity solutions.
Feedback
Weekly cadences where design presents to business AND developers together. Meetings are recorded for absent team members. Wireframes are linked to ADO user stories, with a 2-3 day async feedback window where all stakeholders comment directly in Figma. Major decisions are documented in ADO.
Ready for Dev
Final wireframes with complete annotations and interactive prototypes. Sectioned in Figma and linked in ADO, these become the source of truth for Development and QA. Once finalized, they are never changed and remain as a source of documentation. Any non-urgent updates that arise are moved to the next sprint cycle.
Development
Dev team builds from wireframes, prototypes, and documentation, with clear understanding of intended behavior and interactions.
QA
Quality assurance references Ready for Dev wireframes as source of truth for validation.
Amendments
If QA identifies critical issues requiring immediate fixes within the same sprint, a new user story is created. Designer copies Ready for Dev wireframes to Amendments section, makes changes, documents thoroughly, shares updated link.
Process Swimlane Diagram
Documentation Example: Ready for Dev Handoff
Each feature was sectioned out and documented in Figma with annotations describing complete interaction specifications, linked to the corresponding Azure DevOps user stories, and provided with interactive prototypes. This example shows the "Save Filters" feature documentation. Developers received everything they needed to build without requiring additional design clarification.
Once this was submitted, these wireframes were frozen. They would remain unchanged in the documentation, and any further updates would be made with amended copies of these wireframes.
Complete documentation includes: user flow, interaction specifications, validation rules, error states, and links to ADO stories and prototypes.
This eliminated ambiguity and reduced back-and-forth between design and development.
Getting Buy-In
I pitched this to product leadership first, presenting the quality improvement and risk reduction case. Then I conducted workshops with development and business teams, teaching them how to use Figma and explaining how the new process would work.
The key argument: slightly longer upfront time investment would dramatically reduce time-to-successful-completion by eliminating late-stage revisions.
I piloted the process on an internal platform redesign project. We tracked sprint velocity through Azure DevOps and measured the results over six sprints.
The Pilot Results
10% reduction in delivery time
25% improvement in design consistency
Fewer QA rounds
Earlier issue detection
Surya's work on an enterprise-wide validation platform was so strong that I asked her to present it to a room full of design leaders and senior managers. She didn't just deliver, she landed. That's when I knew she was someone special.
What sets Surya apart is her ability to see the whole system, not just her slice of it. She thinks through stakeholders, handoffs, and downstream impact.
Duane Gayle
UX Director, PwC
Beyond process innovation, I led product design across multiple projects in PwC's contract management ecosystem. I worked closely with my UX manager, contributed to global research, and designed systems serving consultants worldwide.
Unified Engagement Platform
Context
Merging two separate internal platforms into a single system for managing the full engagement lifecycle, from opportunity validation through recurring contract management.
What I Designed
Engagement Lists
Filterable, sortable view of all engagements: ongoing, completed, drafts, and marked for recurrence. Users can select engagements and process them through recurrence workflows. The most important details are shown at a glance, with more accessible through expansion.
Draft engagements list with expanded details
Engagement Forms
Extensive forms for editing engagement details, line information, and line management. These forms work both during active engagements and when preparing for recurrence.
Recurring engagement forms with multiple engagements and project lines
I redesigned the form hierarchy using progressive indentation (24px per level) and color-coded backgrounds for nested elements. A read-only sidebar shows prior engagement context for recurring engagements, preventing accidental edits to locked fields. New fields were also introduced and I grouped the inputs in the engagement header into sections to make the entries easier to follow.
Before:
Same visual level for engagements and nested project lines
Not scannable
No separation between prior engagement context and current details at the individual engagement level
Fewer fields
After:
24px indentation at every nested level
Shades of blue to differentiate engagement header, engagements, and project lines
Back to Engagements link to return to Engagement List
Prior engagement context maintained in a separate space at the individual engagement level
New fields added
Engagement header section divided into Prior Engagement Details, Engagement Details, Team Members, and Financial Details
Recurrence Flow
The complete process of turning a completed engagement back into a new opportunity for renewal during a new time period.
Initiating recurrence on an Engagement and saving to Drafts
Line Management
Each engagement has multiple product lines with their own managers, codes, and data. I designed the experience for linking, merging, adding, and removing lines when preparing engagements for recurrence. Linking and adding lines require no verification, while merging and deletion, being destructive actions, require modal verifications.
Line management on a recurring Engagement and field validations
I designed the line component in the Manage Mode to show default state, selected state, and lead line designation. Linked lines display visual indicators showing their relationship to the lead line.
Project Line components in Manage Mode of the Engagement Form
Validation System
When forms are submitted, they run through compliance checks before being submitted to risk analysis and finance teams. I designed the notification system for warnings (informational) vs. hard stops (must fix before continuing).
Validation states at the input field level
Toast notifications in case there are any validation hard stops
Modal verification in case of any warnings and no hard stops
Design Process
This project merged two platforms — an opportunity management system and an engagement management system — into one unified experience. The goal was to create a single platform where users could manage opportunities, engagements, and drafts as one cohesive workflow.
Most of the work involved augmenting existing features to create continuity across the engagement lifecycle. Before touching UI, I worked with my UX Manager to map the information architecture and user flows that would define how everything fit together.
During her time at PwC, Surya demonstrated resilience and adaptability through periods of constant change and consistently took ownership of her work with minimal oversight, making her a trusted UX partner. Throughout challenging timelines, she remained committed to advocating for strong UX practices and maintaining focus on delivering quality UI.
Jennifer Dolan
Sr UX Manager, PwC
Information Architecture
The first decision: how to organize the platform's navigation. We debated two models: a 2-tab structure that matched users' current mental model, versus a 3-tab structure that would establish a new one.
I advocated for three tabs. My rationale was that users were moving between opportunity creation, draft management, and engagement lists constantly. Without a dashboard to surface everything, each workflow deserved top-level visibility. I also wanted clear navigation feedback: when a user saves a draft, the global header should reflect that they've moved into Drafts, not leave them guessing which subtab they're in. Above all, I wanted to break the mental model of "two systems in one container" and establish Easy Engage Plus as a unified platform.
The 3 tab structure was applied, but was still in active debate with stakeholders when I left the project.
User Flows: Line Management
Line operations—merging, linking, duplicating, deleting—were the most complex part of the system. I mapped these flows collaboratively to define edge cases and prevent errors at scale.
Key decisions:
Two paths for merging (automatic search vs. manual evaluation) converge at a confirmation modal, preventing accidental bulk merges. The automatic merge was shelved for later development due to technical complexity, but we laid the bricks to put it in place.
Duplicate lines use templates from each engagement's existing lead lines. Users never start from blank.
All additive actions would occur with a single click, while destructive actions like merging and deletion would require a confirmation.
Any action taken in Manage Lines mode could be reversed by canceling, and changes would only be saved when the user submitted or saved the engagement as a drag while in Edit mode. This was communicated clearly to the user using modals and toast notifications.
Merge Lines user flow
Shelved for Later: Automated Rollovers
Based on research findings, we explored a feature for automated rollovers that would allow the system to scan for eligible engagements and roll them forward without manual initiation. We mapped the flow and began groundwork, but deprioritized it for a later iteration. Line management had to ship first, and the technical complexity of automation required more foundation.
These flows directly informed the final interface: a modal that consolidates all line actions with clear selection states, confirmation steps, and field-level validation errors.
Strategic Vision: Team-Configurable Dashboard
The Opportunity
Through global research, I identified a critical gap: teams had no single place to understand operational status. Information existed — notifications showed alerts, Code Creation showed opportunities — but it was scattered. Managers spent their first hour each day checking three separate views just to see what needed attention.
I advocated for a dashboard concept that would give teams a unified operational view while respecting territorial differences.
The Design
The challenge:
Balance standardization with flexibility. Every territory had different priorities and workflows. We couldn't customize the core recurrence process for everyone, but we could let teams configure how they viewed their work.
The solution:
A team-configurable dashboard with two capabilities:
Operational Overview: Summary metrics, alert feed, and engagement progress: a single source of truth for daily decisions
Customization Layer: Widget-based configuration letting teams surface what mattered most to their workflow
Key principle:
Balance standardization with flexibility. Every territory had different priorities and workflows. We couldn't customize the core recurrence process for everyone, but we could let teams configure how they viewed their work.
Proposed Dashboard Concept - Middle Office Analyst
Proposed Dashboard Concept - Manager
What Happened
I pitched this concept to leadership as a strategic north star, not for immediate build, but as a future state to guide product decisions. The vision addressed a real operational gap identified through research, but business priorities focused on foundational work: merging platforms, establishing core workflows.
My contract ended before development began, but the strategic thinking mattered. How we structured notifications, validation states, and progress tracking was informed by this vision, building toward a future where teams could configure their operational view rather than forcing a one-size-fits-all approach.
AI-Native Onboarding
Context
What I Designed
A single AI-driven interface that consolidated all system entry points. The key design challenge: deciding when users should interact conversationally (typing/speaking) versus when structured selection (dropdowns, forms) serves them better.
Structured forms prevent AI misinterpretation when precision is critical (entity selection, dates, codes), while conversational prompts improve UX for exploration and guidance.
AI-native onboarding experience
The Design Principle
Other Projects
Validation Framework
Context
What I Designed
In addition to these projects, I was a member of PwC's Lean UX Center of Excellence and contributed to their global design system initiative, defining component patterns and documentation standards to ensure consistency across applications. The initiative was deprioritized before launch, but principles informed my work on individual projects.
Impact
10% Faster Delivery
The new workflow caught issues during design, not during QA. Less rework meant faster sprints.
25% Better Consistency
Clear documentation and linked handoffs meant developers built what designers intended.
Companywide Adoption
After the pilot success, I presented results to a UX director who championed the approach to PwC's internal design center of excellence. Members adopted elements of the framework for their own teams. I worked with a scrum master to refine the documentation standards, and the process was applied to the main platform redesign and influenced teams across the company.
Beyond the metrics, the impact wasn't just efficiency. The systemic change went beyond metrics:
Developers had a voice at business-dominated tables.
Design decisions were informed by technical constraints from day one.
Documentation eliminated ambiguity and potential blame.
Teams started collaborating instead of just coordinating.
Reflection
01
Process Design Is Product Design
The most impactful work I did at PwC wasn't designing a screen. It was designing how teams work together. By identifying inefficiencies in handoffs and creating structured collaboration rituals, I improved outcomes for every project that followed. The workflow I created outlasted any individual feature I designed.
02
Early Alignment Prevents Late Chaos
The Briefing and Feedback stages of my process exist specifically because of this insight. Bringing developers into design conversations from the beginning, rather than treating them as implementation resources who receive PNG attachments, prevented weeks of rework later. A 30-minute design review with engineering present caught issues that would have cost us days in QA and wasted sprint cycles.
03
Global Research Requires Strategic Synthesis
Working across 12 territories with different regulations, workflows, and needs taught me how to synthesize diverse requirements into scalable solutions. The goal isn't to make everyone happy. It's to make decisions that serve the broadest set of users while acknowledging tradeoffs.
04
Vision Work Has Value Even When Not Built
The dashboard concept I proposed never shipped. However, the process of advocating for it demonstrated leadership and influenced other design decisions made, paving the way for its creation in the future.
Strategic thinking isn't just about what ships—it's about identifying the right problems, proposing thoughtful solutions, and influencing direction even when immediate execution isn't possible.