Put the State Machine and Boundaries in the Prompt
For every screen, list every state, nail the edge cases, and write error-prevention requirements. State-machine completer + edge-case wheel, with a copy-ready acceptance phrasing template
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Put the State Machine and Boundaries in the Prompt”?
For every screen, list every state, nail the edge cases, and write error-prevention requirements. State-machine completer + edge-case wheel, with a copy-ready acceptance phrasing template
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
You say "build an order list page," and AI always pictures: network fine, data fits one screen, user never mis-clicks. It's not lazy—your description only had fair weather. Lesson 2 covered the three states (loading, empty, error); lesson 3 covered error prevention and reversibility. Those taught you to spot the gaps; this lesson turns what you spotted into black-and-white clauses in the prompt.
Cross-lesson · The three states and the three parts of an error messageWhat loading, empty, and error should look like when they're done right, and how to write error copy in plain language—lesson 2 already walked it; we reuse that conclusion here.The prompt below is classic fair-weather; the five cells on the state board are still question marks. Tap a state chip to write that state into the prompt and watch the spec grow line by line.
How much is that one line—"empty state gets guidance"—worth? Same order page, two versions in a new user's eyes: left prompt never mentions empty state; right adds one sentence. Tap the side you think keeps the newcomer.
Once states are listed, deeper edge cases remain. Demo never hits them; week one after launch, they all show up. Draw one to see AI's default dodge—and which sentence to add to the prompt.
How finely you write states and edge cases depends on the interface posture. About Face 4, Chapter 9 sorts products into postures; here are the two you'll use most. Name the posture first in the prompt—AI will nail state density much better.
Classic posture mismatch: a leave-request page with sovereign-grade filters and charts, or a day-long monitoring console with poster-sized one-screen flows. Density follows posture; posture follows how often it's used.
Taste Engineering's block builder assembles visual specs; this one builds interaction specs. Toggle five clause groups; the preview updates live. Pick "Omit" and the preview flags where AI will freestyle. Assemble, copy, paste at the end of your generating-UI prompt.
AI only writes states you name: loading, empty, error, weak net, success—name all five. Unnamed ones are a blank-screen and alert farm.
Nail the edge cases: when the list is empty, when the network fails, when they double-submit, when permissions are missing—after every "when," one clear requirement.
Posture first, then density: sovereign UIs can be dense; transient UIs stay few and loud—don't grab the wrong script.
Ship the spec as an annex: goal + scenario (last lesson) first, interaction spec (this lesson) last—together they're the full brief for AI.
Source: Original to Xiaoshan Academy's Interaction Engineering series; error and state principles from About Face 4, Chapter 15; interface posture from Chapter 9 (Alan Cooper et al.).
Turn the feeling in “Why AI output is always the "fair-weather" version” into a judgment
“You say "build an order list page," and AI always pictures: network fine, data fits one screen, user never mis-clicks.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “The prompt below is classic fair-weather;” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “Ship the spec as an annex: goal + scenario (last lesson) first, interaction spec (this lesson) last—together they're the full brief for AI” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Why AI output is always the "fair-weather" version” to “Try it · State-machine completer”
“Why AI output is always the "fair-weather" version” grounds the problem in “You say "build an order list page," and AI always pictures: network fine, data fits one screen, user never mis-clicks. It's not lazy—your description only had fair weather. Lesson 2 covered the three states (lo…”. “Try it · State-machine completer” then moves it toward “The prompt below is classic fair-weather; the five cells on the state board are still question marks. Tap a state chip to write that state into the prompt and watch the spec grow line by line”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Why AI output is always the "fair-weather" version”: You say "build an order list page," and AI always pictures: network fine, data fits one screen, user never mis-clicks. It's not lazy—your description only had fair weather. Lesson 2 covered the three states (lo…
- “Try it · State-machine completer”: The prompt below is classic fair-weather; the five cells on the state board are still question marks. Tap a state chip to write that state into the prompt and watch the spec grow line by line
- “The closing point”: AI only writes states you name: loading, empty, error, weak net, success—name all five. Unnamed ones are a blank-screen and alert farm
The final “The closing point” brings the discussion to “AI only writes states you name: loading, empty, error, weak net, success—name all five. Unnamed ones are a blank-screen and alert farm”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.