Designing an AI feature without AX vocabulary means reinventing patterns that PAIR, HAX, and the Shape of AI already mapped — and shipping the failures they already documented. This module builds fluency in the three frameworks, then applies them: entry points, conversation specs, alternatives to the chat box, streaming behavior, and memory UX.
Meera's second AI project — after the summarize panel from Module 4 — is bigger: her B2B product's first assistant. The team does what 2023 taught everyone: a sparkle icon in the nav opens a right-side panel containing an empty chat box and the placeholder "Ask me anything…"
Four weeks post-launch, the data is bleak. Seven percent of users have opened the panel; most typed nothing at all and closed it. Of those who typed, the largest cluster asked things the assistant cannot do — "email this report to my team" — and received apologetic refusals. A support ticket reads: "What is the AI thing actually for?" The assistant is capable of genuinely valuable work: it can build filtered views from a description, explain anomalies in a chart, draft field-report summaries. Almost nobody discovered any of that by staring at an empty text box.
Meera's team treated the AI experience as a component — add chat, ship. But every part of the failure was a designed surface someone forgot to design: where the AI shows up, how users learn what it can do, what happens when it can't, and whether a chat box was the right input at all. The good news is that none of these are open research problems. Three mature, free frameworks map this territory, and this module makes you fluent in them.
Three references anchor everything in Modules 6–8. Learn their names and structure now; you'll cite them in specs, critiques, and interviews.
| Framework | What it is | What it gives you |
|---|---|---|
| Google PAIR Guidebook | Six chapters of guidance: User Needs + Defining Success, Data Collection, Mental Models, Explainability + Trust, Feedback + Control, Errors + Graceful Failure | The decisions framing — worksheets for what to build and how to fail well; updated for generative AI |
| Microsoft HAX Toolkit | 18 Guidelines for Human-AI Interaction, organized by phase: initially, during interaction, when wrong, over time — plus a pattern library and workbook | The evaluation backbone — G1 "make clear what the system can do" through G18; the phases structure every review you'll run |
| The Shape of AI | Six pattern families with named, screenshot-documented patterns from shipped products | The component vocabulary — when a spec says "add a Wayfinder" or "footprints pattern," this is the dictionary |
Shape of AI's six families are worth committing to memory, because they name the anatomy of every AI surface you'll design:
All three frameworks are free. The AX half of this track — the premium skill from Module 1 — runs almost entirely on resources that cost nothing. What employers pay for is fluency: knowing which pattern answers which failure, without a week of searching.
The first AX decision predates any screen: where does AI show up? Three archetypes, with different discovery and trust profiles:
Whatever the entry point, capability onboarding decides the mental model — HAX G1 ("make clear what the system can do") and G2 ("make clear how well"). The bar is accuracy, not enthusiasm: onboarding that oversells produces exactly Meera's failure pattern, where users ask for the impossible, hit refusals, and generalize distrust to the capabilities that actually work. The reliable mechanics are Wayfinders: suggestion chips seeded with real, working, valuable prompts; templates for the three highest-value jobs; a capability tour that shows boundaries ("I can build views and explain charts; I can't send email") in the same breath as powers.
When conversation is the right medium, it gets designed with the same rigor as a screen — documented in a conversation spec, the artifact an engineer and a writer can both build from. Its sections:
NN/g's chatbot research sets the register for all of it: users want direct, scannable answers — front-loaded, structured, skimmable. Chit-chat, filler empathy, and restating the question are not personality; they are latency in costume. Watch a session recording of someone using a verbose assistant and the behavior is unmistakable: they skim past the pleasantries hunting for the answer, and every skipped sentence is a small tax the design chose to levy. Write the directness requirement into the tone-boundaries section of the spec explicitly — "answer first, context after, no restating the question" — because without the written rule, model defaults and stakeholder instincts will both drift toward padding.
Every extra sentence of pleasantry is time-to-value lost. Warmth in a product conversation comes from being effortlessly useful, not from the word "certainly."
The strongest AX pattern decision is frequently no conversation at all. Free-text input is maximally flexible and maximally burdensome: the user must know what's possible, compose a request, and hope. For well-understood jobs, structured alternatives beat it on speed, discoverability, and error rate:
"Ask me anything" in a side panel. User must guess capabilities, type a paragraph, read a paragraph back, then correct misunderstandings conversationally. Flexible, undiscoverable, slow for known jobs — and it made Meera's assistant a ghost town.
Madlibs for parameterized requests ("Show __ for __ grouped by __"). Inline actions on existing content. Preset styles and Tuner modes for output shaping. Hybrid surfaces where structured input launches and NL refines. Same model underneath — a fraction of the user burden.
The decision discipline is per job-to-be-done: enumerate the jobs, and for each ask — is intent structured or open-ended? Does the user know what they want before they start? How costly is a misunderstanding? Structured intent plus known goal → madlibs, parameters, inline action. Open-ended exploration → conversation earns its keep. Mixed → hybrid: structure to start, language to refine. Meera's relaunch applied exactly this: "build me a view" became a madlib with suggestion chips, chart explanation became an inline action on every chart, and the chat panel remained for the genuinely open-ended tail — with Wayfinders seeded from the top working use cases. Adoption tripled; refusal rates collapsed, because structured inputs can't ask for the impossible.
Generative latency is a designed experience, and the design decisions deserve a written behavior spec rather than whatever the frontend framework defaults to. The decisions: what streams token-by-token versus appears complete (streaming reads as alive but unscannable while moving; complete blocks read as considered); whether "thinking" is visible as a reasoning stream, a summarized status line ("searching your reports…"), or a plain skeleton; how long outputs collapse behind summaries with expand affordances (progressive disclosure — NN/g's guidance on scannability applies doubly to AI walls of text); and where the stop/interrupt control lives — a Governor pattern users need visible the moment generation starts, not discovered after it becomes annoying.
Spec each decision per surface with annotated behavior notes ("stream the summary; card layouts appear complete; status line during retrieval; stop button replaces send during generation"). You decide what the experience is; track 02's frontend engineers implement it — that split is explicit in both curricula, and the behavior spec is the artifact that crosses it.
Personalization is where assistants become either genuinely theirs or genuinely creepy, and the difference is legibility. The design rules, drawn from Shape of AI's Governors and Trust Builders and HAX's over-time guidelines (G13–G17):
Lab 11 assembles this module into its deliverable: for a provided B2B scenario, you'll choose entry points, design capability onboarding, and write the full conversation spec.
The blank chat box is not a neutral default — it's a stack of unmade design decisions, and users feel every one. Fluency in PAIR, HAX, and Shape of AI turns those decisions into named, defensible choices: entry points that get discovered, onboarding that tells the truth, conversations that repair, and inputs that fit the job.