Designing Dexter,
the AI assistant built in a day
A single day turned months of prior underwriter research into a working, coded prototype. Four rounds of iteration later, it surfaces deal information faster and with far more transparency into how each answer was built.
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.
Customer: Meridian Logistics Inc., in PolicyCenter
- Pinned deal data and prior conversations
- Underwriting guidelines and loss history
- Precise: figures, citations, anything you'll quote
- Balanced: early exploration and first drafts
Conversations are retained 90 days, then cleared automatically.
Retrieval and reassembly, not analysis
Getting a clear read on a deal meant opening four or five systems and reconstructing the story by hand: claims in one tab, exposure in another, notes somewhere else entirely. Nobody had built an interface for that work, because nobody had quite named what the work was.
It wasn't analysis. It was retrieval and reassembly, over and over, for every deal, every day. That single reframe, found before a single screen existed, is what the whole project was built to answer.
Short for Operations Account Specialist: the role that manages the day-to-day administrative and processing work behind an underwriter's book of business, and one of the two people this tool was designed for as the user.
Research that shaped the room
Before the workshop, I'd already spent time with underwriters and their operations support teams, and one thing came through clearly: nobody was asking for a smarter assistant. They wanted to see its edges. What it read. Where an answer came from. When to double-check it. What happened to the record afterward.
That research became the brief the whole day worked from, not a slide deck we referenced once and set aside. Every decision below traces back to one of those questions.
In one day, a working prototype
We came into the room with Figma mockups already grounded in the research. The real power was in what happened next. We prototyped on the fly, inside our own design system in Claude Code, and watched mockups become working screens in real time. Our developers built an API in the room that same day and wired it to real data. By the end of the day we weren't holding a prototype anymore. We had a working AI Assistant, with four tabs: a place to ask questions, a guide for trust and scope, a way to save the record, and a settings panel for control.
That speed made it easy to try out ideas we hadn't planned for going in, including a tab to spin up a new project, a way to download several saved archives at once, and a way to send an artifact straight to a teammate. All of it was research informed and buildable in real time, which was genuinely exciting to watch. None of it was validated yet, and user testing still had to happen before any of it was real.
Ask me a question about this deal. I'll flag when you should verify before acting.
Which locations have the highest loss frequency? Next: Compare against last quarter- Pinned deal data and prior conversations
- Underwriting guidelines and loss history
Creativity level
The four tabs from the first coded prototype, plus a few room-built ideas riffing on the same pattern, recreated here in Dexter's own navy-and-red branding.
The path to pilot
Discovery
No interface yet. The finding that shaped everything after it: the work wasn't analysis, it was retrieval and reassembly.
First coded prototype
Four tabs, built straight from survey data, in a single day.
Validated with five underwriting specialists
The Guide tab resolved trust concerns in session, and the exported PDF got treated as an accountability record without anyone prompting for that.
Dexter, scoped for pilot
Two tabs removed, two added, and pinned context promoted into the chat itself.
Still open: how far back history should surface, permissions by persona, export governance, whether Dexter should always show its reasoning, and a working assumption on retention. We're also asking whether a model could learn which guidance to surface based on a person's history or the question they just asked, and what the information architecture for storing artifacts should look like as that library grows. This was our MVP. All of it goes to the account team and operations advisory groups before pilot.
What changed, and why
Five underwriting specialists sat down with the first prototype days after the workshop. What survived confirmed the brief; what didn't became the next round of design.
Sources cited in the answer
The single biggest trust builder, carried down from the guide into every individual answer.
Loading state required
A pause with no feedback reads as broken, and a tool that looks broken rarely gets a second try from a skeptical user.
Expand to full screen
Reading a real analysis in a 340-pixel column isn't reading. The panel stays the default; longer answers get room.
One thing we didn't resolve. A spot-check flag on lower-confidence answers split the room: half saw it as what makes the tool safe to act on, half worried people would learn to scroll past it. Neither view was something we could test from a conference table, so it went on the research list instead of getting decided by whoever spoke last.
What I took away
Research earns its keep when it arrives before the whiteboard
Seven minutes of findings changed what the room argued about. Nobody debated whether people wanted transparency, so the day went straight to the questions research couldn't already answer.
A coded prototype changes the conversation
When a design is a picture, feedback is opinion. When it's running code, feedback becomes a decision, because someone can change it and look at the result before the next agenda item.
Trust is a set of features, not a tone
Nobody asked for a smarter assistant. They asked to see the edges: what it reads, where an answer came from, when to double-check it, and what happens to the record afterward. Four features, and the thesis behind every version of this design.
What I'd carry forward
The spot-check flag is still an open question, and I'd rather test it directly with underwriters than debate it in a room. That's the next research cycle: put both versions in front of real users and let the data settle it.
Keep exploring
One of the largest redesigns in Travelers' history, unifying several enterprise systems into a single platform for underwriting teams.
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.