Assistant Design
What this domain tests
Assistant design tests conversation and information architecture: choosing user goals, naming actions, writing prompts and questions, handling repair and handoff. It is less about code and more about making a flow predictable and usable.
Core rules
- Design from user goals, not internal departments. “Change delivery address” is a goal; “Address service” is an org chart.
- One action should have one job and a clear success condition. Use action descriptions and example utterances to make selection reliable.
- Collect only necessary slots; mark required versus optional; validate formats at the point of entry.
- Confirm before irreversible actions; read back critical values; offer a correction path.
- Design repair: “I didn’t catch that,” “Is that the right order?,” and a route to a human.
- Write in the channel’s voice and length. Buttons for small choice sets, free text for open answers.
- Test with real transcripts, including abbreviations, typos, code-switching and multi-intent utterances.
Worked example
Goal: change a delivery address. The action asks for an order number, validates a pattern, looks up the order via an extension, asks for the new address, reads it back, asks “Confirm?” and only then submits. If lookup fails, it says the order was not found and offers retry or agent. Reasoning: validation prevents wasted API calls; read-back catches speech errors; confirmation protects an irreversible change.
Traps
Building a giant menu; asking for data the backend already has; treating “no” as an error; skipping confirmation; and designing only the happy path. Another mark-loser is writing action names for search engine optimization rather than for the model’s action selection.