Defining work item
distribution
A single day to give a cross-functional team one name for the product, three business outcomes, and a ranked list of the assumptions most likely to sink it. The platform it feeds shipped nineteen days later. Nobody had yet defined how work would actually reach the right person.
Parts of this case study have been altered for portfolio purposes. Names, interfaces, and data are recreated, with no proprietary Travelers systems or real customer information shown.
A system nobody had named yet
As the F1 OneTrav program neared its first release, a critical gap was sitting in plain sight: nobody had defined how work would actually reach the right person. Operations Account Specialists were tracking their own queues in personal spreadsheets. Operations Managers were making assignment decisions out of institutional knowledge alone. And multiple teams were using six different terms for the same concept.
Before a solution could be designed or built, the team needed a shared language, a clear set of business outcomes, and a map of the user problems worth solving. That is what this workshop set out to create, and it is the only thing it set out to create. No screens were designed that day, on purpose.
Have you ever gotten on a call and everyone is using six different words, all talking about the same thing, and no one quite knows what we mean? This is why this stuff is so important. Agile coach, workshop facilitator
Short for Operations Account Specialist: the role that carries the day-to-day processing work behind an underwriter's book of business. They are the people whose queues this system would decide, and the perspective I was in the room to hold.
The team in the room
Four functions, one room, one day, and no laptops open for most of it.
My role as the Experience Designer meant I was the designated expert on the user perspective. The facilitator called on me explicitly to surface user needs, contribute the OAS pain points I had collected in advance, and translate user behavior into opportunity statements the product team could act on.
The frame the day ran on
What we did
The facilitator structured the day around the Externalize, Organize, Focus loop, repeated across multiple layers: from vocabulary all the way down to individual solution assumptions. Below are the steps the team moved through, with my specific contributions called out.
Shared language and scope alignment
Before any design or strategy work could happen, the group needed to agree on what we were even talking about. Routing, triage, orchestration, desk management, and distribution were all in circulation. Through open discussion the group landed on "work item distribution" as the product name, and drew explicit lines between triage, routing, and distribution.
Mine: observations from prior OAS conversations that framed why "tasks" carried a negative connotation for frontline staff. We retired the word.Discovery framework introduction
The facilitator introduced the three product lenses, desirability, viability, and feasibility, and established the core principle of the day: good products solve customer problems in ways that work for the business. That frame held every subsequent activity together.
Outcomes brainstorm
Participants individually ideated measurable behavior changes that would signal success, then presented and discussed them as a group. The group refined these into three outcome categories: Speed, Capacity, and Priority.
Mine: several outcomes from the OAS perspective, including adoption of the platform over spreadsheets, reduced time spent figuring out what to work on next, and work status that matches what is actually happening.Live user interview, observed
The facilitator ran a thirty-minute interview with Brian, an Operations Manager, while the team observed and took notes. It doubled as a live demonstration of research practice: open-ended questions, no leading language, one-on-one format, a hard time limit. Afterward the facilitator debriefed on technique and noted that UserZoom, the platform I work in, allows a room to observe while the participant still gets a one-on-one.
Mine: the OAS pain points I had posted to the group chat beforehand, which shaped what the room was listening for.Opportunity mapping
Pain points from the interview and my pre-collected OAS notes were reframed as opportunity statements in the user's voice: "I wish," "I want," "I need." Each was placed on the board and aligned to one of the three outcome categories.
Mine: seven statements, covering adoption ("I wish I didn't have to live in my spreadsheet just to know what to work on next"), manager visibility ("I wish my manager could see where I stand without me having to send an update"), and complexity scoring ("I wish agency complexity showed up as heavier work, not just another account").Solution ideation and assumption mapping
Teams broke into two groups and each selected one opportunity to solve for. Groups storyboarded their solution and identified every underlying assumption, then plotted those assumptions on a 2×2 of importance against certainty to surface the riskiest ones for testing.
Mine: the group I joined worked through complexity scoring and skill-based assignment, generating assumptions around handle time accuracy, skill set data availability, and whether OASs and underwriters share a definition of account complexity at all.What we produced
A shared product definition
The team left with a single agreed name for the product and clear, shared definitions for the concepts around it. That alone resolved months of terminology confusion across product, operations, and design, and it is the artifact with the longest half-life. Every document written since uses these words.
Triage
The first read on a submission, before anyone owns it.
Routing
Sending one work item to one destination, by rule.
Work item distribution
The whole system: skill, capacity, availability, and complexity, together.
Three business outcome categories
Every outcome brainstormed during the session was organized into three actionable buckets. Each category now anchors prioritization decisions, and each one has a different owner arguing for it.
Stop losing time to the tool
Reduce the time it takes to assign, complete, and close a work item. Eliminate manual status tracking and data entry. Surface the information an OAS already needs, in one place.
Make availability visible and trustworthy
Distribute work equitably, accounting for skill, volume, complexity, and time off. Give managers data they can act on without a round of manual check-ins.
Work the highest-value item, not the easiest
Surface SLA proximity and account complexity as real inputs to the order of work, rather than things people hold in their heads.
Everyone wrote outcomes alone first, then read them out. Sorting them was the argument worth having. Ten of the thirty-odd notes, transcribed off the wall.
Opportunity statements in the user's voice
Thirty-plus opportunity statements were generated from OAS and Operations Manager perspectives, rooted in observations from the live interview and pre-collected research. Seven of them are mine, and on the wall they are the pink ones, because I wrote on a pink pad all day.
A ranked assumption map
Each group storyboarded its solution, then went back over every step hunting for what it took on faith. Those assumptions went onto a 2×2 of importance against certainty. The upper-right quadrant, the things we were betting the most on and knew the least about, became the short list for rapid assumption testing after the workshop.
This is the artifact I would defend hardest. A storyboard is a guess dressed up as a plan until you can say which parts of it you cannot yet support. Plotting the assumptions is what turned a day of sticky notes into a research backlog.
Ten of the thirteen my group generated. Click any one to read where it landed and what that meant.
Test-first short list 0
Fills as assumptions land in the upper right.
Still open. Whether a reliable complexity score can be built from data we already hold, whether OASs will adopt the platform as their primary interface rather than keeping the spreadsheet alongside it, and whether "capacity" means the same thing to operations and to underwriting. None of those could be settled from a conference table, which is why they became the inputs for the next research cycle rather than decisions made by whoever spoke last.
What I took away
My specific contributions
I came into the room as the team's user expert. Before the workshop I had collected OAS pain points through prior research sessions, and those became source material for the opportunity mapping exercise. During the session I contributed seven opportunity statements covering adoption, spreadsheet dependency, manager visibility, data accuracy, manual entry, cross-coordination, and the cognitive load of process change.
I also pushed the group's thinking on platform adoption by raising the risk we had seen in prior enterprise tool launches, where users quietly opt out when the system does not reflect how they actually work. That risk is now one of the four assumptions on the test-first list.
Discovery as a team sport
The most effective moments in the day were not exercises done in isolation. They were the moments when someone from operations said something and someone from product recognized it as an assumption they had been carrying untested. Getting diverse roles in the room, doing messy collaborative work, and naming things together is itself a design act. The sticky notes on the wall were an artifact. The real output was the aligned mental model everyone left with.
The gap between output and outcome
One of the core lessons I kept returning to during the session: shipping a feature is an output. The question is whether anything changes as a result. Framing our success criteria as measurable behavior changes rather than delivery dates reoriented the room's thinking in a way that will carry forward into how we evaluate research and design decisions after release.
What comes next
The workshop surfaced the riskiest assumptions for the work item distribution solution: whether a reliable complexity score can be built from existing data, whether OASs will adopt the platform as their primary interface, and whether the concept of capacity means the same thing to operations and to underwriting. These become the inputs for the next research cycle, which is targeted assumption tests before design begins in earnest.
Keep exploring
One of the largest redesigns in Travelers' history, unifying several enterprise systems into a single platform for underwriting teams.
A one-day workshop that turned months of underwriter research into a working, coded AI assistant, then four rounds of iteration into a trust-first tool.
Reworking a sales homepage experience to fit underwriter workflows.