Turning a single chat into a full investigation workbench

01 Context

Yuma is an agentic support platform for ecommerce brands. It plugs into helpdesks like Gorgias and Zendesk and automates as much of customer support as it can, ideally most of it. Ask Yuma is the surface where operators and merchants talk to that agent: investigate tickets, debug Auto-Pilots, pull reports, steer automations.

I led design at Yuma for a year and owned this surface. Everything below is mine end to end, from the problem framing to the merged pull requests.

02 Problem

The challenge

Ask Yuma was single-thread. Open a new chat and the old one vanished into a "recent conversations" list nobody found. Anyone working two things at once, comparing two Auto-Pilots, or debugging Account A while answering Account B, opened extra browser tabs, which broke the shared websocket and the logged-in context.

Why it mattered

Operators start an investigation, get pulled away, and never come back. The "awaiting your reply" state sat in a popover almost nobody opened. Every dropped thread is a support outcome that fails quietly, and the people dropping them were the heaviest users, ops handling 20+ tickets a day. When your most engaged users keep losing work, you are not losing a feature. You are losing trust in the agent, which is the whole product.

Single-thread chat is right for ChatGPT. It's wrong for an investigation tool used by people who switch context every minute or two.

How I knew it was the right problem

I did not get this from a brief. I sat through session replays, watching operators work, and the same failure kept repeating: a clarifying question goes unanswered, the operator tabs away, the thread dies. I turned that into an 18-issue UX audit of Ask Yuma, and "the awaiting loop is invisible" was the theme that mattered most. The replays and the audit pointed at the same thing.

03 Impact

What changed:

• Operators stopped losing context. They run several investigations across tickets and accounts without extra browser tabs or a broken socket.

• The awaiting-reply loop is closed. A reply the agent is waiting on now shows up where people already look, instead of dying in a popover.

• The motion vocabulary outlived the feature. Two named spring presets are now the standard for every panel transition in the product.

• A latent bug got killed along the way. The unread notifier matched the wrong event, so finished AI replies never bumped tab counts. Fixing it unblocked the feature and repaired an existing badge too.

04 Solution

Rebuild Ask Yuma as a multi-tab, expandable panel, basically a browser tab strip for AI conversations, and put every awaiting reply in the same dropdown people already use to switch chats.

In practice, that is a panel that grows out of the input you clicked, in two sizes, with a browser-style tab strip, undo-on-close, and an awaiting section that turns a buried state into something you catch at a glance. Keyboard and screen-reader users get full parity.

05 Approach

What I owned

Problem framing, the IA argument, visual and interaction design, the production code in TypeScript and React, the PRs, and the rollout. I worked in the codebase next to the engineers, with Storybook and a mock chat provider as the review surface.

The decisions that shaped it

• Tabs in the app, not native browser tabs. Browser tabs each open their own connection and session, which is exactly what was breaking parallel work. In-app tabs share one connection and one context.

• Awaiting state promoted into the switcher, not left in a separate popover. I deleted the old popover in the same change, because a feature that only adds is debt with a launch note.

• Overflow by measuring the DOM, not counting tabs. A long title overflows at two; short ones fit at eight. Counting is the wrong heuristic.

Accessibility was in from the start

ARIA tablist, arrow-key nav, focus rings, 44pt hit areas, reduced-motion scrolling, and unread counts in each tab's aria-label so screen-reader users get the same signal sighted users do. Tab strips are easy to get wrong for keyboard users, so I designed for them first.

Execution

I built it in stages so each shipped on its own: the panel's spatial language first, then the two-size expand driven by a pair of named spring presets that are now the product's motion vocabulary, then the tabs. The hard part was the last stage, giving every tab its own state while sharing one connection, instead of opening a socket per tab and melting the backend.

06 Reflection

What worked

The key decision was putting the awaiting state inside the same switcher people use to change chats. That is what solved the biggest complaint: replies the agent was waiting on used to get missed, and now they show up in the one place people already look.

What I'd do differently

Add tracking from the start. I found the problem by watching session replays, which was enough to act on but not enough to prove the result with hard numbers afterward. Next time I would measure how often people switch context, and how many investigations get dropped, before and after.

Transferable insight

When the same kind of state shows up in several places, reuse one pattern for all of them instead of designing each spot on its own. People learn it once, and the tool stays consistent as it grows.