A B2B tool is adding its first AI assistant. Choose the entry-point patterns, design capability onboarding that sets accurate expectations, and write the full conversation spec — persona, tone boundaries, repair strategies, refusal language, conversation-to-GUI exits — sharp enough that an engineer and a writer could both build from it.
Hana is lead product designer at Freightline, a fictional B2B logistics platform where operations managers track shipments, file customs documents, and resolve delivery exceptions. The company is adding its first AI assistant, and the CEO's instinct — "put a chat bubble on every screen" — is exactly the instinct this lab exists to discipline. A conversation is a UI with no visible edges: users cannot see what it can do, where it ends, or what happens when it breaks. The conversation spec is how designers put the edges back. You will start from a PM's draft spec that gets several things dangerously wrong, and end with a document two different professions can build from without asking you anything.
FREIGHTLINE — context
Users: ops managers, 30-500 shipments/day, deadline-driven,
low tolerance for toys. Core jobs: "where is my container",
"fix this customs hold", "file this document", "warn me
before a delay costs money".
Assistant scope v1 (engineering-committed): shipment status
lookup, delay-risk summaries, customs-document drafting
(human files it), exception triage suggestions. NOT in v1:
booking, rate negotiation, anything that files or sends.
DRAFT SPEC v0.4 (PM)
- Entry: floating chat bubble on all screens, pulsing until
clicked. Opens with: "Hi! I'm Freddie ⚡ your AI logistics
genius! Ask me anything!"
- Persona: fun, quirky, uses emoji, first-person feelings
("I'd love to!").
- If the assistant doesn't know: apologize and say "I'm
still learning!" then offer a joke to lighten the mood.
- If the user is frustrated: respond with extra enthusiasm
to balance the energy.
- All interactions stay in chat — never bounce the user
back to boring screens. The chat IS the product now.
- Refusals: avoid them. Find something helpful to say
instead of "no".
Red-line the draft spec. List every line that will hurt trust with this audience: the unbounded promise, the persona-audience mismatch, the "never leave chat" rule, the anti-refusal rule, the frustration strategy, the attention-demanding entry. For each, write why it fails for deadline-driven ops managers specifically — audience-anchored rationale is what makes a spec defensible in review.
Choose entry points deliberately. Replace the everywhere-bubble with two or three scoped entry patterns from the Shape-of-AI Wayfinder family — e.g., contextual nudges on surfaces where the assistant is strong (a "summarize delay risk" affordance on the shipment list), suggestion chips seeding first questions inside the panel, and one persistent-but-quiet entry point in the nav. For each: where it appears, what first message or chips it opens with, and why that surface earns it. Rule: an entry point is a promise about capability at that location.
Design capability onboarding that sets accurate expectations. First-run panel, three beats: what it can do (the four v1 capabilities, named concretely), what it cannot do yet (booking, filing, sending — say so), and how it can fail (may be wrong; status data lags; verify before acting on money decisions). Write the actual copy — max 60 words total. No "ask me anything." Test it: every claim must map to an engineering-committed capability.
Decide the persona and tone boundaries. Write the persona section: role ("a competent ops colleague"), tone dials for this audience, and hard boundaries — no emoji in operational contexts, no first-person feelings, no jokes in error or delay contexts, no fake enthusiasm mirroring. Include five sample exchanges (canonical Q→A pairs) because examples constrain a model and a writer better than adjectives.
Write the repair strategies. Cover the four standard breakdowns with copy templates: misunderstanding (assistant answers the wrong question → offer interpretation + one-tap correction: "I read that as container MSKU-778. Different shipment?"), no-data (status feed gap → say what is missing and when to retry, never guess), out-of-scope (route to the human/GUI path that can do it), repeated failure (after two failed repairs, stop retrying and hand off — escalation is a repair strategy, not a defeat). A repair loop with no exit is the spec bug users describe as "arguing with the bot."
Write the refusal language. Three refusals with real copy: a capability refusal (asked to book a shipment), a data-confidence refusal (asked to certify a customs figure it cannot verify), and a safety/authority refusal (asked to file the document itself). Pattern each as boundary + reason + adjacent capability: what it cannot do, why, and what it can do instead. Refusing well is a feature; the draft spec's "avoid refusals" line is how assistants end up bluffing.
Design the conversation-to-GUI exits. Kill the "chat IS the product" rule with specifics: every assistant answer that references an entity (shipment, document, exception) links to its GUI screen; multi-field tasks (document drafting) start in chat but land in the form view with fields pre-filled for review; bulk operations always exit to the list view. Annotate two flows end-to-end: "where is container X" (happy path, with exit) and "draft the customs doc" (chat → pre-filled GUI form → human files it — the approval boundary visible).
Adversarial-test the spec, then finalize. Paste your spec into your AI: "Role-play a rushed, skeptical ops manager using this assistant. Follow the spec exactly. Try to make it break its persona, overpromise, refuse badly, or trap the user in chat." Run six exchanges. Every break you find becomes a spec edit. Then assemble the final document: scenario, entry points, onboarding copy, persona + exemplars, repairs, refusals, exits, and the two annotated flows.
Write the refusals and repairs before polishing the happy path — the happy path designs itself, and the breakdowns are where an engineer discovers whether your spec actually decided anything.
A conversation is an interface whose affordances are invisible — the spec's job is to make the edges real: bounded entry promises, honest onboarding, repairs with exits, refusals that transfer, and a GUI boundary the assistant respects because you wrote it down.