Make every chatbot state clear and keyboard usable
Present supported, handoff, unsupported, invalid and error states clearly across keyboard, mobile and narrow layouts.
01 · Understand
Why this issue exists
Customers experience the product through the interface, not through its architecture.
02 · Investigate
Accessibility smoke test
Unplug the mouse
A supported answer, a refusal and an application error all appear as plain text. The input has no visible label. The page works on the developer’s laptop but has not been tried at phone width.
- 1Can a user tell which state occurred at a glance?
- 2Can the entire path be completed with a keyboard?
- 3Does the page explain its scope before someone types?
- 4What belongs in the service and what belongs in the UI?
03 · Decide
Where should a rule such as “eligible means personal” live?
04 · Make the thinking visible
Team workspace
Discuss first, then record the team’s reasoning. These notes stay in this browser until you copy them.
For each state, define heading, visual treatment, message purpose and next action.
A second student should tab, type, submit and understand the result without a mouse.
Check labels, source evidence, controls, focus and horizontal overflow.
05 · Scaffold
Render the answer contract—do not recreate it
The UI selects a presentation from answer.kind. It contains no keyword checks, refusal policy or source validation.
result = answer(question)
match result.kind:
case AnswerKind.SUPPORTED:
# Render answer and evidence.
...
case AnswerKind.HANDOFF:
...
case AnswerKind.UNSUPPORTED:
...
case AnswerKind.INVALID:
...
case AnswerKind.ERROR:
...06 · Prove it
Evidence checklist
Tick an item only when the team can show the evidence and another student can explain it.
Push further
Stretch challenge
Ask a student who did not build the interface to identify all five states without seeing the code. Record any ambiguity as a defect.