All work

CS/02 · Case study

Showing the assistant’s work

You can’t prompt an AI’s narration away, so I designed a place for it: chat patterns for results, clarifying questions and working notes, and a plain answer to “how did you get this?”

Details generalized under NDA. Every visual is recreated with fictional data.

Role
Product designer and design engineer
Scope
Chat patterns, answer details, a design-system component
Context
AI reporting assistant for a government data platform, in beta
Year
2026

The problem

The model narrates between tool calls, and it narrates more on harder tasks. Prompt changes alone couldn’t stop it. And when a request was ambiguous, it quietly stacked up assumptions instead of asking.

I owned the assistant’s chat patterns: how results appear, how it asks clarifying questions, and how it shows its work.

Decision 1

Give the narration a place to go

Considered
  • Tighten the prompt only
  • Hide the narration
  • Give it a place to go
Chose
Three chat patterns, prototyped as client tools the agent can call: a launch card that opens a result in the side panel, a clarifying-choice card with option pills and a “use defaults” escape, and collapsed working notes that absorb the narration.
Why
You can’t prompt narration away, so design a place for it. And for ambiguity, asking once beats guessing three times.
Fig. 1The three patterns in one conversation: working notes, a clarifying choice, and a launch card.

Names matter here too: I called it a “launch card” so it wouldn’t collide with the design system’s existing “chip”.

Decision 2

“How I got this answer”: start expressive, then cut to the design system

Considered
  • Stacked, expandable and lineage layouts
  • A first-person “trail” with connector lines and markers
Chose
The first-person structure (Data used → Assumptions made → Query), built only from standard design-system cards, lists, badges and inline messages. The custom trail visuals are gone.
Why
It is the path of least resistance for engineering and review, with no custom UI to maintain.
Fig. 2Three rounds of the answer details: an expressive exploration first, then the version built only from design-system parts.

One rename came from the domain, not the layout: “judgment calls” became “Assumptions made”, because “calls” collides with “calls for service” in public-safety data.

A component for everyone

The result card, and a grouped “N more” variant, went into the company’s open-source AI design-system package, with Storybook stories, a changeset and React wrappers. The whole card is clickable, and the active card is marked with aria-current.

Fig. 3Result card anatomy: base, hover and active states, and the grouped variant.

Constraints

  • Platform limits. There was no hidden-reasoning channel, and tools bind when a conversation starts, so every change needed a hard reload to test. I documented these as asks for the platform team.
  • Honest copy. Charts were declared but not implemented (only tables rendered), so no copy invites people to ask for a chart. While checking, I found a prompt telling the model to use tools that don’t exist.
  • Contrast. I caught a status chip that failed contrast on the dark toolbar, and it didn’t belong on that surface anyway.

Outcome

  • The “How I got this answer” view and the result card were built as production code, not just mockups.
  • The result card was offered to the shared design system for other products to use.

What I learned

  1. Start expressive, then cut hard.

    The trail explored the idea. The design-system version is the one built for production.

  2. Every element has to earn its place.

    A focus surface like the canvas is for making things, not monitoring them, so status belongs where it’s scannable or actionable. I now default to removing things.