Prudential's Corporate Technology organization forecasts ~$400M in annual software spend across ~1,400 contracts. When Relationship Managers needed changes made, requests landed in a 4-person Planning & Analysis team's inboxes through email and Teams - no queue, no context, no history. The team tracked hundreds of requests in their heads.
Goal:
Replace two scattered inboxes with a shared, structured queue that gives the Planning & Analysis team one place to pick up, action, and track change requests.
Measure:
Time spent reconstructing context, request distribution across the team, and pattern visibility.
Result:
A shared pick-up queue that eliminated forwarding, ended context reconstruction, and surfaced request patterns the team never saw before.
I designed the Planning & Analysis side of the change request system - a triage-based ticket queue that replaced email chaos with a single, actionable workflow.
Pick up one ticket at a time. Every request lands in a shared unassigned queue visible to all four team members. Opening a ticket fills the screen - line items, submitted request, and conversation in one focused view. "Take it" is the moment of commitment, so no forwarding, no bottlenecks, and two people never work the same ticket.
Track your own work in one place. The "My Tickets" tab shows the status of everything you've picked up - in progress and resolved. An "Upcoming" section surfaces tickets other team members have tagged you on, so complex requests reach the person with the most context without being hard-assigned.
See RM replies in the inbox. When a Relationship Manager responds to a question on a ticket, it shows up in the inbox - so the team member handling it knows there's a reply waiting without monitoring every open ticket.
285 change requests. 2 inboxes. 4 people.
Prudential's Corporate Technology organization forecasts approximately $400M in annual software spend across ~1,400 contracts. When Relationship Managers identify changes, they communicate them to a 4-person Planning & Analysis team who coordinates the changes and confirms them back.
Stakeholder | Their Role |
|---|---|
Planning & Analysis team | A 4-person team that receives change requests, coordinates with upstream data owners to action them, and communicates status back |
Relationship Managers | Director-level finance partners who identify what changes need to be made and communicate them to P&A |
Every change request used to arrive through email or Teams. There was no queue, no structure, no history, and no unified view of what was coming in, what was in progress, and what was done.
When a request came in through email or Teams, the Planning & Analysis team read it - often missing context - followed up for more information, waited for a response, then re-read the whole thread from the top to reconstruct what was being asked before they could action anything. Once done, they confirmed completion back to the Relationship Manager. And when an RM replied to an old thread asking to add a couple of line items to an already-resolved request, the team had to dig back through the full email thread and cross-reference Excel sheets to reconstruct the original context before they could act. All of it happened across two channels at once, with no unified view.
The business problem
285 messages. 2 channels. 4 people. | ~285 change request messages per forecast cycle across email and Teams. Each arrives in a different format, with varying context, across two disconnected channels - no unified view of what's in, in progress, or done. |
60% to one inbox, 40% to another. | Most RMs only knew of two P&A team members. Requests were unevenly distributed, causing constant forwarding - one person overloaded while others were underutilized. |
Reading everything twice, sometimes three times. | Most requests arrived without enough context to action. P&A followed up, waited, then re-read the full thread before doing anything. For a team of 4 managing 285 requests, the re-reading added up fast. |
All 4 Planning & Analysis members named tracking requests across two inboxes as their biggest source of mental load
5 user interviews with the Planning & Analysis team and Relationship Managers revealed that volume wasn't the biggest issue - it was the mental load of holding it all in their heads.
With ~285 requests split 60/40 across two people's inboxes, most RMs only knew of two of the four team members - so requests were forwarded constantly, and the whole team mentally tracked what was in, in progress, and done across email and Teams. Most requests arrived without enough context to action, triggering a follow-up cycle: ask, wait, then re-read the full thread from the top before doing anything. And when an RM replied to an old thread to add line items, the team reconstructed the original context from scratch - scrolling emails and cross-referencing Excel sheets.
The real insight: P&A's job isn't complicated - receive a request, understand it, coordinate the change, confirm completion. The process made it complicated. The tool needed to do the organizing so the team could focus on the work.
Current UX pain points
Pain point | How pressing the pain was |
|---|---|
No unified queue | P&A monitored two channels simultaneously, tracking everything mentally |
Uneven distribution, constant forwarding | 60% of requests to one person, 40% to another - the other two were unknown to most RMs |
No structured intake | Requests arrived freeform - most missing the context needed to action them |
No history in one place | Reconstructing context meant scrolling email threads and cross-referencing Excel |
No pattern visibility | Processing one email at a time meant never seeing which change types were most common |
Defining the challenge
User needs
See all incoming requests in one place regardless of channel. Get enough context on arrival to action without following up. See the full history of every request in one place. Step back and understand patterns across all requests.
Business goals
Reduce time spent reconstructing context. Replace email and Teams as the intake channel. Give the team a structured queue so nothing slips through. Surface request patterns to inform product improvements.
Engineering needs
Change request data lives in the React app's own database, not upstream. P&A coordinates changes with upstream data owners - the tool facilitates that but doesn't own the data change. Reusable components shared with the RM side - queue, ticket detail, chat, audit log.
Challenges translated to design goals
Pain point | Design goal | Design specifics |
|---|---|---|
Monitoring two channels simultaneously | Centralize all requests in one place | All requests land in one queue regardless of channel |
Uneven distribution and forwarding | Ticket pick-up model | One shared queue visible to all four - anyone picks up any ticket |
Requests arrive missing context | Structured requests with context captured | The RM-side form prompts for change type, description, and line items upfront |
No history in one place | All request history in one place | Every update and message lives on the ticket |
No pattern visibility | Surface patterns in a dashboard | Volume by change type shows where the process is breaking down |
Two design directions for how P&A picks up tickets
Direction 1: Assignment Model
Tickets are assigned to specific team members, each with their own queue. Pros: clear ownership, easy to see individual workload. Cons: recreates the distribution problem — formalizes uneven forwarding; if one person is out, their tickets stall; a team of four doesn't need that structure.
Direction 2: Pick-Up Model (Selected)
All tickets land in one shared unassigned queue. Anyone picks up what they can handle. Pros: no forwarding, no bottlenecks, work distributes naturally, flexible for a small team, tagging keeps complex tickets moving without hierarchy. Cons: requires trust and self-organization.
Iteration 1: Modal
Each ticket opened as a modal overlay with a "Take it" button.
What we tested | Feedback received |
|---|---|
"Take it" button inside the modal | After clicking, the modal closed and the ticket moved to My Tickets - the team had to navigate away and reopen it. Opening, closing, reopening broke the flow. |
Modal size | Too small for a complex request - line items, submitted request, and reply box felt cramped. |
Iteration 2: Side panel
Each ticket opened a side panel while the queue stayed visible on the left.
What we tested | Feedback received |
|---|---|
Queue visible alongside the ticket | Seeing all tickets while reading one encouraged browsing - the team reviewed multiple before deciding to take any |
"Take it" while the ticket is open | The ticket disappeared from the unassigned queue while the person was still reading it - confusing to watch it vanish |
Iteration 3: Full screen (Selected)
Each ticket opens as a full-screen page with a back button to the queue.
What we tested | Feedback received |
|---|---|
One ticket, full screen | Removed clutter - the team focused on one thing at a time |
"Take it" above the assignee dropdown | Claiming became a deliberate action, not triggered by opening |
"Close" resolves and notifies | The RM gets notified, the ticket moves to resolved in the background |
Key debates
How should P&A balance personal focus with team visibility?
P&A wanted | A focused view of their own tasks - but still the ability to see all tickets, to understand incoming volume or look up a ticket they didn't personally resolve. Not to compare. |
Design perspective | Separating My Tickets and All Tickets gives focus without hiding activity. But splitting the resolved view by team member creates implicit comparison. |
Resolution | All Resolved tickets are mixed together with the resolver tagged - no separate sections per member. Anyone can look up a resolved ticket without the view feeling like a performance scoreboard. |
What if two team members open the same ticket at once?
Engineering reality | Two members could open the same unassigned ticket simultaneously - the system needs to handle who gets it. |
Design opinion | The ticket stays in the unassigned queue until "Take it" is clicked. First click locks it - the second person sees it's already claimed. |
Resolution | "Take it" is the moment of commitment, not opening the ticket. Browsing is free, claiming is intentional - the queue stays accurate without tickets vanishing mid-read. |
Should we use color?
The case for color | Change type pills in distinct colors - like Asana - would make the queue scannable. It would look polished. |
Design opinion | Color draws attention. The question at the queue isn't "which type is this?" - it's "what's next in line?" Color on change types pulls focus to the wrong thing. |
Resolution | Monochrome for the queue and ticket detail - color would redirect attention without adding value. Color on the dashboard only, where charts and numbers benefit from at-a-glance differentiation. |
Final Design
Design decision | What it solves |
|---|---|
Dashboard as the landing page | The team no longer starts blind - pending, in progress, resolution time, and volume by change type are visible before opening a ticket. High volume of a change type surfaces gaps in the forecasting tool itself. |
Shared unassigned queue, one ticket at a time | Replaces two fragmented inboxes with one place to see all requests - no forwarding, no missed requests, no mental tracking |
Full screen ticket, "Take it" as commitment | One thing to focus on; two people can't claim the same ticket; browsing is free, claiming is intentional |
All Resolved tickets mixed, resolver tagged | Team visibility without implicit comparison - no performance scoreboard |
Usability Testing
Task | Old Process | Iteration 1 (Modal) | Iteration 2 (Side Panel) | Iteration 3 (Full Screen) |
|---|---|---|---|---|
Channels monitored at once | 2 | 1 | 1 | 1 |
Steps to claim and work a ticket | 5+ | 4 | 3 | 2 |
Context visible before claiming | None | Partial | Full | Full |
Accidental double-claiming possible | Yes | Yes | Yes | No |
Focus on one ticket at a time | No | No | No | Yes |
Found a resolved ticket without guidance | No | No | Partially | Yes |
3 months post-launch
Metric | Target |
|---|---|
Change request emails to P&A | Reduced by 70%+ |
Follow-up messages per request | Reduced from 1–3 to 0 |
Time to action a ticket | Reduced from 3–5 days to same day |
Pattern identification | At least 1 process improvement per cycle from dashboard insights |
What I learned
Watch the user work when it's difficult to find pain points in interviews. The Planning & Analysis team had normalized their own pain points, so they didn't bring them up in interviews. Going back over Excel sheets when an RM finally replied with context. Marking emails unread so they'd remember to return to them. One team member getting the bulk of requests and quietly forwarding them to distribute the load. None of this came up when I asked how the process worked - it only surfaced when I watched them actually do it. Observing the process let me name the pains, then bring them back to the team to confirm we were solving the right things.
Restraint in design. It's tempting to add color to make an interface feel polished -distinct pills for each change type, like Asana. But the question the team was asking at the queue wasn't "what type of change request is this?" It was "what's the next ticket I need to get to?" Nobody was picking up specific types - everyone takes on whatever's next. Coloring by change type would have pulled attention toward a distinction that didn't matter for the decision at hand. I kept the queue monochrome and saved color for the dashboard, where seeing patterns at a glance is the whole point. Knowing when not to add something is as much a design skill as knowing when to.
Designing both sides of a system makes each side sharper. I designed the RM experience of submitting a change request and the P&A experience of receiving it. Seeing both perspectives changed decisions on each. Because I'd designed the RM's structured submission form, I knew exactly what context would arrive on the P&A side - so the ticket could show it cleanly instead of asking P&A to hunt for it. And because I understood P&A's need to reconstruct history, I knew the RM's drafts and line-item edits had to persist as a visible trail. Neither side would have been as clean if I'd only designed one. The handoff between two users is where a system either works or falls apart - and you can only design that handoff well if you've stood on both sides of it.
