C.O.N.V.E.R.S.E.
A high-bandwidth loop for intent and correction.
The user expresses a goal, the system makes its interpretation legible, the user adjusts it cheaply, and the response becomes clear, credible, and usable. That loop is the product.
Design principle
Design the composer and conversation so people can inspect context, express intent naturally, see what is happening, verify claims, refine precisely, read structured output, and recover when the turn fails.
C.O.N.V.E.R.S.E.
Each dimension has a design question, what to build, and patterns that put it into the product.
Context
No hidden or accidental context
- Question
- What does the AI know for this turn, and can the user inspect it?
- Principle
- Context should be inspectable, scoped, and reversible. Default to showing only what is active in the current turn: conversation, attachments, selections, instructions, memory, sources, and workspace.
- Breaks as
- Surprising answers from silent injections, or control panels nobody will use.
- Build
- Context chips for files, selections, workspace, and sources
- Attachment preview with filename, type, progress, and remove
- “Using context” disclosure for materials that informed the answer
- Scope selector when chat, files, workspace, or web differ
- Memory shown when applied, with edit / forget
Other related patterns
Onboarding
Lower blank-page friction
- Question
- How does a user know what to ask and how to start?
- Principle
- The empty state should teach capability through action. Starters should be immediately usable and tied to a clear outcome.
- Breaks as
- “Ask anything” with no path into value, or a carousel of feature cards.
- Build
- Job-based starter prompts tied to outcomes
- Context-aware suggestions when files or selections are present
- Templates with editable placeholders
- One strong input example with its likely output format
- Clear New chat and whether prior context carries over
Natural expression
Low-effort input
- Question
- Can users express intent in their own words and media?
- Principle
- The composer is the control surface. Support natural language, then add structure only when it materially improves the result.
- Breaks as
- Forcing prompt engineering, or a crowded composer that hides the main input.
- Build
- Expanding multiline primary input
- Clear send vs new-line behavior
- Attachments, paste, selection, and in-product objects
- Voice with editable transcription
- Optional tools and input limits without crowding the input
- Slash / intent menu and mentions for frequent tasks
- Draft preservation and keyboard-first behavior
Other related patterns
Visibility
Reduced uncertainty
- Question
- Can users see system status, response progress, and conversation state?
- Principle
- Communicate real state; do not simulate thinking theatrics.
- Breaks as
- Ambiguous spinners, no stop, or lost prompts after failure.
- Build
- Immediate acknowledgement after send
- Meaningful progress only when true (searching files, reading sources, drafting)
- Streaming when it helps, with Stop always available
- Retry and reconnect that keep the prompt and any partial response
- Clear drafts, sent, regenerated, and edited states
Other related patterns
Evidence
Calibrated trust
- Question
- Can users assess what supports the response?
- Principle
- Evidence should be contextual and proportionate to the stakes. A simple draft does not need a provenance panel; a market or policy answer probably does.
- Breaks as
- Every answer treated as equally reliable, or provenance panels on simple drafting.
- Build
- Inline citations on claims that matter
- Source drawer with titles, excerpts, dates, and links
- Quoted evidence for the exact passage behind a claim
- Assumption and no-source labels
- Conflict states instead of invented certainty
Other related patterns
Refinement
Efficient iteration
- Question
- Can users correct or reshape a response precisely?
- Principle
- After send, the key act is precise correction. Refinement should reduce the cost of being specific.
- Breaks as
- Only “Regenerate,” forcing a full rewrite for a one-paragraph fix.
- Build
- Whole-response controls (tone, length, format)
- Selection-based refinement on a paragraph or claim
- Follow-up chips and editable user messages that preserve the original branch
- Variants and branches without destroying the thread
- Feedback with reasons: incorrect, unhelpful, missed context, bad tone
Other related patterns
Structure
Scannable, usable output
- Question
- Is information presented in the best form for reading and use?
- Principle
- Chat is the container; the answer should use the format the job needs.
- Breaks as
- Walls of fluent prose where a table, checklist, or artifact would work.
- Build
- Progressive disclosure: answer first, then detail
- Real tables, lists, code, and quotes
- Actions near content: copy, export, save, share
- Collapsible long outputs
- Artifact handoff for long drafts and analyses
| User need | Better output |
|---|---|
| Compare options | Table with criteria, trade-offs, and recommendation |
| Follow a process | Numbered steps or checklist |
| Review a document | Summary, key quotes, risks, and open questions |
| Make a decision | Options, evidence, confidence, and decision criteria |
| Analyze data | Chart or table with interpretation and caveats |
| Create content | Editable draft with title, sections, and alternatives |
| Learn a concept | Short explanation, example, and optional deeper detail |
Error recovery
Graceful recovery
- Question
- What happens when the answer is wrong, incomplete, or unavailable?
- Principle
- Design failure as a normal conversation state, not a technical dead end.
- Breaks as
- Confident nonsense, opaque failures, or no path back to a usable answer.
- Build
- Unclear request: one focused clarifying question and possible interpretations
- Missing input: what is needed, why, and an easy way to add it
- Unsupported request and safety boundary stated plainly
- Failed generation that keeps the prompt and offers retry
- Bad answer paths: correct, regenerate, verify sources, and give feedback
Other related patterns
Design workflow
Use C.O.N.V.E.R.S.E. as a design-review and product-definition process.
- 1
Define the conversation job
Specify the user, their moment of need, the input they have, and the outcome they want from a single chat session.
- 2
Map the turn lifecycle
For each meaningful turn, design input, active context, system state, response shape, evidence requirement, refinement path, and failure state.
- 3
Design the composer before the model prompt
Decide what users can attach, select, reference, constrain, and revise. The composer determines how much useful signal the model receives.
- 4
Prototype difficult moments
Test vague prompts, large attachments, contradictory context, interrupted streaming, inaccurate answers, long conversations, and users who do not know how to prompt.
- 5
Measure conversation quality
Track successful outcome rate, time to a usable answer, clarification burden, edit and refinement rate, citation engagement, recovery success, and user-rated trust.
Cheatsheet
Eight checks before shipping, one for each C.O.N.V.E.R.S.E. dimension.
- Can a first-time user understand what this chat is for?
- Can they see and change the context that will influence the answer?
- Can they express intent without mastering prompt engineering?
- Do system states make waiting, streaming, and failure understandable?
- Can users verify important claims and see uncertainty?
- Can they correct one part of an answer without restarting?
- Does the response use the right structure, not just fluent prose?
- Can users recover from an incorrect, incomplete, or failed response?
