Overview
Carol, a product designer at Mercury (a fintech startup building “radically different banking”), walks host Jay through the full lifecycle of designing Command, Mercury’s agentic AI assistant. She reveals her end-to-end process for designing AI-agent experiences: starting from loose high-level diagrams of the mental model, to low-fi Figma explorations, to vibe-coded working prototypes, and ultimately moving into production code and real data.
The video is a masterclass in how design teams should work with AI agents as collaborators rather than treating AI as a magic box. Key themes: leading with intent instead of navigation, designing “canonicals” (conversation-friendly renderings of data primitives), handling deterministic confirmation for high-stakes actions, designing reasoning/thinking states, and operating within a strong design-quality culture where design can push back on shipping subpar craft.
Key Insights
-
(0:09) Start with a mental model, not pixels. Carol’s first step was asking “what is this new mental model we want to work on” and doing a lot of loose, high-level prototyping. She drew a small diagram combining search + chat into one — a “grounding moment” that helped her understand what the system was doing.
-
(0:40) The LLM’s job: gather context, reason, then output legible results. Her framing: the LM gets context, takes it all in, does its thinking/crunching, and outputs something legible to the customer — so the customer never needs to do calculations or hunt for the right button.
-
(3:32) A public demo environment is a powerful design asset. Mercury runs a public demo site live for customers and non-customers. Every shipped feature is visible there (a product-launch checklist item). It helped her fall in love with the product before joining, and it’s a great onboarding tool.
-
(8:28) Flip the interaction model: lead with intent, not navigation. Traditional banking means walking the sidebar to find data. Command flips this — you land, ask a question, and then the system navigates you to the pages you care about with the right filters pre-applied. The user’s intent comes first.
-
(9:55) Chat output should link to the dashboard with filters applied. Carol’s favorite feature: the LLM generates a summary but also links to “money in / money out” activity, and clicking applies the right filter. This connects chat to the deterministic dashboard.
-
(10:12) Never let the LLM generate raw links. Link generation is handled entirely in the backend, managed through the agent, so the LLM can’t generate random/unsafe links.
-
(10:52) Design the “reasoning state” — communicate that something is happening. During a query, text changes with a text-gradient effect to signal “something’s going on.” Carol’s analogy: when chatting with a person you don’t need them to articulate every thought — you read it from their eyes or head movement.
-
(13:06) Diagrams are a thinking tool, not just deliverables. Carol repeatedly draws diagrams and metaphors to orient around a mental model. She even spends a lot of time in Figma because it’s a “free canvas to draw and move pixels around.” Drawing is how she thinks.
-
(15:02) Explore “easy” solutions even if you won’t land on them. The simplest concept — throwing chat on the homepage — was explored as a valid starting point even though it wasn’t the final solution. Low-fi explorations are valuable.
-
(16:11) Borrow ergonomics from existing AI chat tools. For conversation-interface interaction patterns, Carol looked for inspiration from Claude, ChatGPT, and Notion AI — borrowing ergonomics from those surfaces. For workflow/response architecture, she drew on internal customer personas and journeys.
-
(17:36) Vibe-code when Figma can’t capture the medium. The feedback after the Figma iteration was “I can’t feel what this interaction is like.” Since conversation is a user + keyboard + typing + clicking, turn-by-turn flow is impossible to prototype well in Figma. So Carol vibe-coded a solution in Cursor.
-
(19:16) Connect your backend/model to your prototype for the real feel. The first vibe-code was fully deterministic (no model), which was fine for seeing turn-by-turn flow but hit a wall. She then paired with her PM and built a vibe-code with a real working system prompt — because the response architecture (how the system answers different question types) is what actually needed testing.
-
(21:51) The system prompt IS the product. Carol: “it feels almost impossible to design without interacting with the system prompt… the system prompt in a way is the product.” For visual details you can still use Figma, but different parts of the final product need different ways of interacting with the solution.
-
(25:16) Get into production and real data as fast as possible. Both vibe-code prototypes taught her: the best thing is to work directly in prod and get as close to production code as possible. The vibe-code “ceiling was pretty low” — she was “hitting her head” on it.
-
(25:49) The process is not linear. Command was put on the roadmap, kicked off at the beginning of the year, and taken to a weekly Wednesday “product review” with the leadership team starting Jan 7. Early conversations were about scope (update homepage? insights page? entire architecture?), then narrowed to what Command should look like, how it’s placed across pages, its output, and supported workflows.
-
(27:28) Show vibe-coded prototypes synchronously to execs. For leadership reviews, share prototypes live with someone screen-sharing and guiding the conversation, rather than just sending links async. There’s too much content to cover and the flow needs talking through.
-
(28:31) Product review aligns on language and design principles. The review process was used to align leadership on the specific design principles for the project, and to converge on IA/UI form-structure options.
-
(29:03) Track exec feedback in comments, follow up in workshops/Slack. Execs (e.g., COO Jason) leave comments like “can you make these different states clearer for different canonicals.” Design follows up in the next workshop, or in Slack for pressing items.
-
(32:51) Design “canonicals” — conversation-friendly renderings of data primitives. Command renders objects (recipients, vendors, cards, transactions) in the conversation in different formats — inline in a sentence, or as a rich card after an edit/create action. This is where a lot of hierarchy and typography craft lives.
-
(33:29) Use a recurring “Craft Crit” for visual quality. Every ~two weeks Mercury runs a Craft Crit with the design team where designers bring explorations (like canonical renderings) and chat about details. Example: a designer flagged that text hierarchy and type weights were inconsistent across a card, leading to a cleaner before/after.
-
(35:15) Borrow from your design system AND existing visuals. Canonicals borrow from the design system and from literal existing visuals — e.g., the card rendering, team member avatars.
-
(36:28) Kill visual flourishes that create confusion. Carol loved showing the file attachment on invoices, but it was dropped because it looked like the payment card and the document’s text confused the UI text. The info was already interpreted into the UI, so the flourish was redundant. Good craft means removing what muddies clarity.
-
(39:39) Design the input-elicitation experience deliberately. A key interaction is making sure users can provide all necessary inputs for the system to create the right money movement/object. The elicitation experience shouldn’t feel “too heavy” — ask follow-up questions in plain text first, then surface structured multiple-choice options.
-
(40:39) Reasoning state during elicitation shows tool calls. During a transfer, the reasoning state shows the agent going through different tool calls to identify what information needs gathering.
-
(42:33) Require deterministic confirmation for high-stakes actions. For a real money transfer, users must confirm via explicit buttons — “we want to make sure users are intentionally taking these actions,” unlike a casual Claude conversation. The canonical has explicit states (draft → edit → confirm → done).
-
(43:22) Designers still design in Figma — as a thinking canvas. Carol’s workflow shows “yes” to “do designers still design in Figma?” It’s easier to move around and sketch ideas. Metaphor: like an architect wanting a pen and paper before building in wood — for UI, a pen, canvas, and pixels.
-
(44:11) Make canonical states explicit (draft label). In response to Jason’s feedback, they added a “Draft” label so users know an object isn’t sent yet and is open for edits — clear state labeling throughout the flow.
-
(46:35) Design the edit flow within a draft. What happens when a user wants to edit a draft? You can change fields (e.g., send date), delete, go back to confirmation, cancel, or send — and the agent returns a new draft to confirm. Clear state transitions matter.
-
(48:24) Tune system prompts for the stakes. Carol notes you can tell when AI chat tools tweak their system prompt to be more eager or more conservative. For Mercury, “there’s probably more at stake,” so they want to be methodical, ask questions, and confirm deterministically.
-
(49:08) A shared quality bar lets design push back on shipping. Mercury aligns on quality bars across design, engineering, and product. Design can say “this isn’t good enough” and cross-functional partners usually agree — it’s not a battle. They do weekly check-ins and test together before beta/launch.
-
(50:53) Use a 0–5 design leveling rubric. Mercury has a design leveling scale (0–5). For Command they aimed at a 4–5 because it’s a new interaction/interface that must make no mistakes (at least a 3) and be crisp, innovative, and fresh.
-
(52:02) Reasoning states: show succinct thinking, allow expand/collapse. The team debated whether to show the agent’s thinking. Feedback: “loading”/“thinking” alone felt too slow, but full chain-of-thought + tool-call text floods the page for 10–20s loads. They landed on a simple, one-line rotating summary (e.g., “searching for card data,” “searching for transaction details”) that the user can expand/collapse to see tool calls and chain-of-thought.
Actionable Techniques
-
(0:09) Diagram the mental model first. Draw a simple diagram of what the AI system is doing (context → reasoning → legible output) before designing screens. Use it to ground your own understanding even if no one else sees it.
-
(3:32) Maintain a public, always-live demo environment. Make shipped features visible in a public demo; add “live in demo” as a launch checklist item. It helps recruiting, onboarding, and customer evaluation.
-
(8:28) Design “lead with intent, not navigation.” Structure the primary surface so users state what they want; the system navigates to the right page/filter. Remove the burden of sidebar hunting.
-
(9:55) Link chat outputs to dashboard views with filters applied. When the agent returns a summary, provide deep links that open the relevant page with the correct filter/data pre-loaded. Click-through must land in context.
-
(10:12) Handle link generation in the backend, not the prompt. Keep navigation/link generation managed deterministically by your backend/agent rather than letting the LLM fabricate links.
-
(10:52) Add a visible “reasoning/thinking” state. Use motion (e.g., a text gradient) to signal activity during model processing — analogous to reading a person’s facial cues mid-conversation.
-
(17:36) Vibe-code conversation interfaces. When the interaction is turn-by-turn typing/clicking, build a working prototype (e.g., in Cursor) rather than trying to fake it in Figma — Figma is the wrong medium.
-
(19:16) Connect real backend + system prompt to your prototype. To test the response architecture (how the system handles different question types), pair with your PM and wire a real model/system prompt into the vibe-code, not just a deterministic mock.
-
(21:51) Treat the system prompt as a design artifact. Design with/around the actual system prompt since it largely defines the product experience. Work in Figma for visuals, but validate system behavior against the real prompt.
-
(25:16) Get into production and real data quickly. Aim to work directly in production code with real data as soon as possible; vibe-codes have a low ceiling.
-
(27:28) Walk execs through working prototypes live. Share vibe-coded prototypes synchronously (screen-share + guide) in review meetings; post only the agenda async. Too much is lost in async links for agentic flows.
-
(29:03) Capture leadership feedback in-file comments; follow up in workshops/Slack. Keep a paper trail of exec comments, then resolve them in the next crit or promptly in Slack.
-
(32:51) Design “canonicals” for AI responses. Create conversation-friendly renderings of your core data objects (cards, vendors, transactions) that work both inline in text and as rich post-action cards. Invest in the typography/hierarchy craft here.
-
(33:29) Run a recurring Craft Crit. Hold a biweekly design review specifically for visual craft and detail (type weights, hierarchy, consistency) where designers bring explorations for critique.
-
(39:39) Sequence elicitation: plain-text follow-ups → structured choices. Don’t front-load heavy structured forms; ask clarifying follow-ups in plain text first, then offer multiple-choice options to reduce typing.
-
(42:33) Require deterministic confirmation for high-stakes actions. For irreversible/high-value actions (money movement), make users confirm with explicit buttons and walk through labeled states (draft → edit → confirm → done). Never let an eager agent auto-execute.
-
(44:11) Label object states explicitly. Show a “Draft” tag and clear state labels so users always know whether something is sent, pending, or editable.
-
(46:35) Design a full draft-edit flow. Support editing fields on a draft in-context (change date, delete, cancel, send) with the agent returning a revised draft for confirmation — not a cold restart.
-
(48:24) Right-tune the system prompt to the stakes. Make the agent methodical, ask clarifying questions, and confirm when stakes are high; be more permissive only for low-risk tasks.
-
(49:08) Align cross-functional quality bars. Get design, product, and engineering aligned on a shared definition of quality so design can veto shipping subpar work without a fight. Do weekly joint testing/check-ins.
-
(50:53) Use a 0–5 design leveling rubric. Set a target quality level for the project up front (e.g., 4–5 for a flagship agentic experience) and hold the bar.
-
(52:02) Design succinct, collapsible reasoning states. Show a one-line rotating summary of what the agent is doing; let users expand to see full tool calls and chain-of-thought on demand. Avoid flooding the page with raw reasoning.
Tools & Skills Mentioned
- Figma — Carol’s primary design canvas; used for sketching, diagrams, explorations, components, and Craft Crits.
- Cursor — used for vibe-coding working prototypes (both deterministic mock and model-connected).
- Claude / ChatGPT / Notion AI — sources of inspiration and ergonomics for chat interface patterns.
- vibe coding tools — V0, Magic Patterns, Figma Make were noted as getting “really good” at the time; Carol chose to stay with Cursor.
- Feature flags — used in Mercury’s internal testing environment to toggle features/products on/off.
- Mercury Command (product) — the agentic AI assistant being designed.
- Product Review — weekly Wednesday leadership review cadence.
- Craft Crit — biweekly design-craft critique session.
- Design leveling rubric (0–5) — company design quality scale.
- Public demo environment — always-live public site reflecting shipped product.
Quotes Worth Keeping
- (0:40) “Okay, what the LLM can do is it can just get context right and then take that all in and then do its thinking and its crunching and then output something that’s pretty legible to the customer without the customer needing to do any calculations on their own.”
- (8:28) “It flips the interaction model from the traditional banking experience… it’s less about me finding where I need to go and more about directly asking the system here’s what I want to know.”
- (13:06) “It was really helpful for me to understand what the system was doing… this was a grounding moment.”
- (14:37) “I think for me it’s a good thinking tool which is also why I am still spending a lot of my time… in Figma because it’s just this free canvas to draw and move pixels around very easily.”
- (17:36) “The interaction for conversation interfaces is just a user and their keyboard and typing and clicking. It’s just so difficult to get that turn-by-turn experience prototyped out in Figma.”
- (21:51) “It feels almost impossible to maybe even design without interacting with the system prompt because I think the system prompt in a way is the product.”
- (25:16) “I think the vibe-codes kind of hit a quick… the ceiling was pretty low maybe and I was just hitting my head.”
- (27:28) “Mostly these conversations… happen pretty synchronously just so that we have someone to talk through and guide the conversation.”
- (39:39) “How can I make it delightful?” — the central design question for agentic interactions.
- (42:33) “We want to make sure that users are intentionally taking these actions unlike just a kind maybe a casual conversation with a Claude, right? But this is real money that’s being moved.”
- (43:22) “Do designers still design in Figma? My workflow is showing yes. It’s just a lot easier for me to move around and sketch ideas.”
- (48:24) “I think for Mercury there’s probably more at stake… we want to be sure that we are maybe a little bit more methodically asking these questions and making sure that users are confirming basically in a deterministic way.”
- (49:08) “We have more or less aligned on our quality bar across the company… it’s never actually been that difficult for design to be like ‘I don’t think this is good enough.’”
- (52:02) “The initial experience is a lot simpler and it’s just the thinking flipping through one line of summary of what it’s doing at a given moment.”