One customer, served by
one team, in a single place
A year-long project that combined legacy underwriting and sales platforms into one new system. Business Insurance submissions used to arrive by email and scatter across six systems before anyone could act on them. F1 rebuilds that path end to end, and OneTrav is where the work now routes automatically, designed for the underwriters who will live in it.
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.
Priorities this week
Assigned to mePriorities this week
Assigned to me · Next 90 daysThese lines belong to another business unit. You can see where they stand, and the deal moves when every unit is done.
Rounding opportunities are optional and never block the review.
Contractors Equipment and Installation Floater, assigned to Jane Austin, opened 4/18/26.
| Team member | Role | Business unit | Office |
|---|---|---|---|
| Julie Rodriguez | Account Executive | Commercial Accounts | Richardson-Dallas |
| Dan Brown | Operations Account Specialist | Commercial Accounts | Richardson-Dallas |
| Jane Austin | Account Executive | Inland Marine | Richardson-Dallas |
Requests
Work asked of you, separate from deals you own| Request | From | Deal | Due |
|---|---|---|---|
| Confirm loss runs received | Dan Brown | Drake LLC | 4/24/26 |
| Add umbrella quote to file | Jane Austin | ACME, Inc. | 4/28/26 |
| Schedule risk control visit | Risk Control | Harbor Group | 5/02/26 |
Requests and deals are separate objects in the system because of how work is routed. Users do not think that way, so the interface keeps them side by side and never asks anyone to know which is which.
Work that existed everywhere and nowhere
A new business submission used to arrive as an email in someone's inbox. From there it was keyed by hand, classified by guesswork, and passed between business units that each had their own queue, their own system, and no view of each other. An Account Executive who wanted to know where a deal stood had to open three systems and a spreadsheet, then call somebody.
F1 replaces that path. Submissions are extracted and enriched on arrival, triaged into a single deal record, and surfaced in OneTrav as work assigned to a named person. My job was the part where a human has to make a decision: what the Account Executive sees, what they are being asked to do, and whether the screen makes that obvious without training.
It's just so much more documented. Who's holding up the process, if they've touched it, if they've looked at it. It's night and day. Account executive, commercial accounts field, usability round two
Short for Account Executive: the person who owns the customer relationship and the deal, decides which lines to pursue or decline at intake, and answers for where the submission stands.
Short for Operations Account Specialist: the role that handles the processing work behind an Account Executive's book of business. The two workflows diverge often enough that most research sessions ran in both variants.
The Work Orchestration ecosystem
One designer inside a program with a lot of owners. Research ran through standing advisory groups of Account Executives and Operations Account Specialists drawn from five business units, a separate pool of usability participants who had never seen the screens, and capability surveys that keep measuring after launch. Findings moved weekly into agile product owners, business process managers, and the development teams building intake, the deal record, and the configured ServiceNow task layer. Most of the work was getting one position agreed across all of them and then holding it steady through two rounds of testing.
Where design sits in a four-stage rebuild
F1 spans the full commercial lifecycle, from the agent's first contact to post-bind service. Release 1.0 takes on the middle: intake, enrichment, and triage, plus the deal record that everything downstream reads from. That scope decision is what made the design work tractable. It also made it high stakes, because intake is the step where a submission either becomes a deal the right team owns, or becomes a deal nobody owns.
Prospect and distribution
Appetite guidance before a submission exists.
Intake, enrich and triage
Extraction, classification, intake review, deal creation. The scope of this case study.
Underwrite
Single pricing and proposal across business units.
Post-bind and service
Servicing and renewal against one deal record.
Release 1.0 targets under ten minutes from submission receipt to a ratable deal, with every business unit working the same record.
Three ideas the design had to sustain
Status has to be legible across units, not just within one
A single customer submission can include Commercial Accounts, Inland Marine, and Excess lines. Each unit reviews its own lines, but the deal only moves when all of them are done.
Someone owns the deal end to end
The deal lead coordinates the rest of the team. That role is new, and the interface is where it gets defined for people who have never had it before.
Bridge the split without leaking the plumbing
The system separates the two because of how work is routed. Users do not think that way. Closing that gap drove several rounds of search and navigation design.
User testing
I wrote the F1 research plan in January 2026 around a simple constraint: the people who help us build something cannot be the only people who tell us whether it works. So the engagement model splits into three groups that never overlap, and each one answers a different question.
User advisory groups
Small standing groups of Account Executives and Operations Account Specialists across business units. Weekly hour-long sessions for the life of the project, covering brainstorming, current-state feedback, requirements, and readiness.
Usability testers
Employees in the same roles who have never seen the screens and are not in the advisory group. Moderated sessions of 45 to 60 minutes, plus unmoderated click tests.
Capability surveys
Post-launch, under ten minutes, per capability. They ladder up to the annual employee satisfaction measure and give capability-level detail underneath it.
Q1 alone ran focus groups on intake, the deal page, the AI assistant, exception handling for both AEs and processors, the home page and view layer, and the Collaboration Digest, each with AE and OAS variants where the workflows diverge, plus a heuristic evaluation of the configured ServiceNow task interface. Product owners were invited into scripts and prototypes before sessions, which turned research readouts into requirements conversations instead of reports nobody acted on.
How the advisory group actually runs
The group was recruited for three traits: change champions, reflective about their own workflows, comfortable with ambiguity. The first session set expectations that mattered more than any agenda item. This work is early, it will be messy, and telling us you dislike something is the point.
You are the experts on how you work. You won't hurt our feelings. Session one, group expectations
Nine sessions in, the format has settled into a rhythm. I bring either two design directions side by side with the tradeoffs written out, or no screens at all when the question is still about the work rather than the interface. Session nine on the Collaboration Digest was deliberately screen-free: I wanted to hear how Account Executives and Operations Account Specialists currently piece together what happened on a deal before I showed them a feature that claims to do it for them.
Bring the open question, not the answer
Sessions open with the decision we are stuck on. Two directions, inline pros and cons, no house favorite stated out loud.
Prototype in the room
Everything I bring is clickable. People react differently to something that responds than to a static frame, and disagreements get settled by trying it.
Leave with a decision or a test
Either the group converges and I build it, or the disagreement becomes a task in the next usability round with fresh participants.
Five findings that changed the build
Each of these changed structure rather than styling, and each traces to something a real person said or failed to do.
Nothing tells me it's mine
Account Executives opened the tool and could not tell which submissions needed them today versus which were somebody else's problem.
Priority cards on the home page, grouped by work type, capped at a short preview with the next action on the row. Homepage orientation tested at 100% success.
I don't know where the deal is
Lifecycle state lived in a different system than the work, so people asked each other instead of looking.
A stage tracker and a plain-language deal status at the top of the deal summary, with the reasons underneath. Most participants placed the deal in the right stage immediately.
Who else is on this?
Cross-unit counterparts were invisible. Account Executives kept personal lists of who to call.
A contacts page split into core and extended deal team, with the deal lead named at the top and phone numbers on the row. Participants understood the split without being told what the tab was for.
The deal disappeared
After an Account Executive finished their own review, the deal dropped off their priority card, including when the last step was still theirs to take.
Three-state status on the card: your review, waiting on another unit, ready to create accounts. Nothing falls off until the deal is done. Rebuilt after round two, and running in the comparison below.
The deal lead can't be deleted
Removing the person who owns the deal silently orphaned it. There was no rule in the interface, only in the data model.
A blocking error that offers the fix: assign a new deal lead first, with the directory search one click away inside the same modal. Guardrail, not a dead end.
Eight AEs, twelve tasks, no walkthrough
April 2026. Eight Account Executives across five business units, none of them in the advisory group, none of whom had seen a single screen. Forty-five to sixty minute moderated remote sessions on a live high-fidelity prototype, think-aloud throughout, pass or fail scored per task with a single ease question after each one.
Task-level results
| # | Task | Success | SEQ |
|---|---|---|---|
| 1 | Email submission notification | 87.5% | 6.3 |
| 2 | Home page orientation and prioritization | 100% | 6.3 |
| 3 | Deal lifecycle identification | 87.5% | 6.0 |
| 4 | Find the intake review button | 100% | 6.1 |
| 5 | Understand the intake review page | 87.5% | 5.5 |
| 6 | Edit the customer name | 100% | 6.9 |
| 7 | Pursue all lines | 100% | 6.6 |
| 8 | Wait for Inland Marine | 87.5% | 5.8 |
| 9 | Create accounts flow | 62.5% | 5.6 |
| 10 | Decline flow | 100% | 6.9 |
| 11 | Reassign to the business center | 42.9% | 5.8 |
| 12 | Find contacts and add a contact | 87.5% | 6.3 |
Benchmarks: success at or above 75%, SEQ at or above 5.5. Task 11 ran with seven participants; the Select AE skipped it. Two tasks fell below benchmark, and both are the interesting ones.
What the two failures were actually about
The Move button
Move existed to shift a single line to a unit already on the deal. Participants read it as the way to reassign the whole submission to the business center, which is a dropdown in the assignments section. Confusion in every session, 42.9% pass.
Create accounts
After review, the priority card changed its label to signal the next step. Nobody noticed. Five of eight found the trigger, and only after prompting.
Documents mid-review
Multiple participants across different units asked for the submission documents while reviewing. Convergent, unprompted, and not something we had planned for.
The Move decision is the one I am most comfortable defending. The instinct in the room was to relabel it and retest. Instead we pulled it from Release 1.0 entirely. Its only function was moving one line to a unit already on the deal, which is rare, and leaving it in meant every Account Executive's first encounter with routing would be a wrong turn. Removing it buys a clean read on whether the fulfillment model dropdown works on its own, and we can design the capability properly for day two.
I think it does streamline the overall process. Much quicker than what we have now, or at least more all in one spot where we're not clicking through six, seven different things. Account executive, select business center
Deal lead: Julie Rodriguez
| Team member | Role | Business unit | Office | |
|---|---|---|---|---|
| Julie Rodriguez | Account Executive | Commercial Accounts | Richardson-Dallas | |
| Dan Brown | Operations Account Specialist | Commercial Accounts | Richardson-Dallas | |
| Jane Austin | Account Executive | Inland Marine | Richardson-Dallas |
Cannot remove deal lead
Assign a new deal lead first, then remove this contact from the team.
Change deal lead
No one in the directory matches that. Try a last name or an email.
The Collaboration Digest, still a question
The digest pulls what happened on a deal across Teams, notes, and request history into one summary with its sources shown. Session nine explored the underlying job with no screens at all: how Account Executives and Operations Account Specialists reconstruct a deal's history today, and what they would stop doing if this existed. The direction below is what came out of that, and it goes back to the group before it goes anywhere near a release.
Every sentence above traces to one of these. Pick a source to see what it contributed.
Designing the feedback loop before launch, not after
Release 1.0 goes live on September 28, 2026. A launch this size produces signal from a dozen directions at once: help desk tickets, quality audits, regional feedback sessions, surveys, an inbox, and the advisory group that never stopped meeting. Left alone, that becomes noise nobody owns. Since July I have been working on the post-launch feedback operating model alongside change management and operations so the loop exists on day one.
The operating principles we landed on
Issue or feedback, decided at triage
Every submission is classified as a defect, which routes to product, or as experience feedback, which routes to change and process. Users never self-classify. They are bad at it and it is not their job.
Low-friction submission
Intake asks for the minimum. Volume matters more than completeness, because a form nobody fills in tells us nothing.
Visible loop
Submitters need to see status and see their feedback connected to a fix. Without that, the channel reads as a black box and stops producing.
One place to look
All channels converge into a single intake and visibility tool. Fragmented capture was the failure mode we were trying to avoid in the product; it is the same failure mode here.
Cadence
Daily command center
Cross-domain defect and observation triage every day, assigning ownership, criticality, and priority for everything that came in during the prior 24 hours. Frequency steps down as volume settles.
Frontline sessions and regional Teams channels
Thirty-minute sessions with frontline users and a parallel track for their leaders, split by region. Remediation updates go back out through the same channels the feedback came in on.
Pulse surveys and one-to-one listening
The first pulse waits until people have had enough real interaction to have an opinion. Individual deep dives follow around week ten on whatever the pulses and sessions surfaced.
Operating reviews and steering
Production metrics, trend analysis across feedback categories, enhancement backlog status. Quarterly covers stabilization and feeds the next release's planning inputs.
The advisory group keeps meeting
Biweekly sessions continue against the next release. The group that co-created R1.0 is the same group shaping what comes after it, now with production experience behind their opinions.
Still open. Triage team composition, the submitter-facing status mechanism, and service expectations for the external agent channel are unresolved as of the current working draft. I would rather name them here than imply the model is finished. The channels exist; the accountability around a few of them does not yet.
What I would tell myself in January
Separate the people who build with you from the people who test
The advisory group is invaluable and completely compromised as a test population. They know why every control is where it is. Keeping usability participants strictly outside that group is what made 42.9% on task 11 possible. An advisory member would have sailed through it and we would have shipped a trap.
Removing a feature can be the finding
The obvious response to a confusing button is a better label. The right response to Move was that the capability was not worth the cost of everyone's first wrong turn. Research earns its keep when it changes scope, not just copy.
Build the thing that responds
Every prototype in this case study is real code, because static frames get polite feedback and working screens get honest ones. It also means the prototype can go straight into a session the same week the question comes up, which is the actual cadence the work moves at.
The hardest problems were organizational
Requests versus deals, cross-unit status, who owns a deal lead role that did not exist before. None of those are interface problems, but the interface is where they become real for the person doing the work, so the design has to take a position on them. Most of my time went into getting those positions agreed rather than into pixels.
Keep exploring
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.
A team workshop redesigning how tasks get triaged and assigned across a distributed team, tested against a real backlog.