// Collect design context, audience, intent, and requirements before writing any UXSpec JSON
Add purposeful motion to a UXSpec — $animations, onEnter choreography, and timing tokens
Improve every piece of text in a UXSpec — descriptions, labels, error messages, empty states, and loading copy
Identify repeated patterns and consolidate them into $elements and shared tokens for systematic reuse
Strengthen a UXSpec against real-world conditions — overflow, missing data, network failures, and accessibility
Run a systematic quality audit on a completed UXSpec — design intent, consistency, accessibility, and state coverage
Walk through building a UXSpec (.uxspec.json) file — gathering requirements, making design decisions about layout/typography/color/motion/accessibility, designing the state machine, defining visuals, then compiling and verifying the output.
| name | gather |
| description | Collect design context, audience, intent, and requirements before writing any UXSpec JSON |
Establish who this spec is for, what it needs to do, and how it should feel — before writing any JSON.
Before starting any new .uxspec.json file. Context cannot be inferred from code — only the creator knows the audience, intent, and tone.
A bullet-list summary covering all 11 answers. Get user confirmation before moving to state machine design. This summary becomes the foundation every other skill builds on.
Every design decision in a UXSpec traces back to context. A login form for a bank and a login form for a game share structure but share nothing else. Capture the difference here so tokens, visuals, and copy reflect it throughout.