UX Content And Form Specification
Use When
- A user-facing form or workflow needs exact content and validation behaviour before implementation.
Do Not Use When
- Do not use for visual styling, marketing copy or backend-only validation design.
Required Inputs
| Artefact |
Source or provider |
Required? |
Missing behaviour |
| Approved journey, fields and business rules |
UX specification, SRS and domain owners |
Required |
Stop where a field purpose or rule is unknown. |
| Voice, language and accessibility requirements |
Content/design system and user evidence |
Required |
Label unapproved wording as draft; do not invent legal text. |
Workflow
- Read the named inputs and confirm their approval, version and unresolved decisions.
- Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.
- Produce the UX Content and Form Specification through the existing domain procedure and load only the references needed for the chosen branch.
- Trace each material statement in the UX Content and Form Specification to an input, decision or explicitly qualified assumption.
- Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.
- If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.
Outputs
| Artefact |
Consumer |
Observable acceptance condition |
| UX Content and Form Specification |
Design, frontend, backend, accessibility and test teams |
Every field has purpose, label, input rule, inline error, recovery, accessibility name and completion event; copy is approved or clearly provisional. |
Evidence Produced
| Evidence |
Consumer |
Acceptance condition |
| Source and decision trace |
Reviewer and downstream owner |
Each material statement cites an approved input, named decision or qualified open issue. |
| Completed verification record |
Release or phase gate owner |
Every applicable check records pass/fail; unavailable checks remain not assessed. |
Capability and permission boundaries
Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.
Degraded mode
If any required capability is unavailable, return the narrowest useful qualified UX Content and Form Specification draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.
Decision Rules
| Choice |
Action |
Failure or risk avoided |
| Error can be prevented before submit |
Use constraint and inline guidance |
Users avoid recoverable failure |
| Rule depends on server state |
Preserve input and return a specific recoverable error |
Submission failure does not erase work |
Quality Standards
- Preserve repository terminology and trace every material choice to project context.
- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.
- Cover error, empty, edge, recovery and operational cases relevant to this skill.
- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.
- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.
Anti-Patterns
- Using placeholder text as a label. Fix: provide persistent visible labels.
- Writing
Invalid input. Fix: state what failed and how to correct it.
- Clearing a form after server error. Fix: preserve safe values and focus the error summary.
- Inventing consent language. Fix: route it to the authorised legal/privacy owner.
- Measuring page views instead of completion. Fix: define start, success, abandonment and error events.
References
Output Shape
Write projects/<ProjectName>/<phase>/<document>/UX_Content_And_Form_Specification.md with content principles, content inventory, form requirements, validation matrix, state copy matrix, accessibility gate, and measurement plan.
1---2name: 09-ux-content-and-form-specification3description: Use when a UX specification needs testable labels, microcopy, forms, validation, errors, empty states, accessibility and completion measures; use UX specification for journeys and interaction structure, and content strategy for broader editorial work.4---5# UX Content And Form Specification6<!-- dual-compat-start -->7## Use When89- A user-facing form or workflow needs exact content and validation behaviour before implementation.1011## Do Not Use When1213- Do not use for visual styling, marketing copy or backend-only validation design.1415## Required Inputs1617| Artefact | Source or provider | Required? | Missing behaviour |18|---|---|---|---|19| Approved journey, fields and business rules | UX specification, SRS and domain owners | Required | Stop where a field purpose or rule is unknown. |20| Voice, language and accessibility requirements | Content/design system and user evidence | Required | Label unapproved wording as draft; do not invent legal text. |2122## Workflow23241. Read the named inputs and confirm their approval, version and unresolved decisions.252. Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.263. Produce the UX Content and Form Specification through the existing domain procedure and load only the references needed for the chosen branch.274. Trace each material statement in the UX Content and Form Specification to an input, decision or explicitly qualified assumption.285. Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.296. If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.3031## Outputs3233| Artefact | Consumer | Observable acceptance condition |34|---|---|---|35| UX Content and Form Specification | Design, frontend, backend, accessibility and test teams | Every field has purpose, label, input rule, inline error, recovery, accessibility name and completion event; copy is approved or clearly provisional. |3637## Evidence Produced3839| Evidence | Consumer | Acceptance condition |40|---|---|---|41| Source and decision trace | Reviewer and downstream owner | Each material statement cites an approved input, named decision or qualified open issue. |42| Completed verification record | Release or phase gate owner | Every applicable check records pass/fail; unavailable checks remain `not assessed`. |4344## Capability and permission boundaries4546Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.4748## Degraded mode4950If any required capability is unavailable, return the narrowest useful qualified UX Content and Form Specification draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.5152## Decision Rules5354| Choice | Action | Failure or risk avoided |55|---|---|---|56| Error can be prevented before submit | Use constraint and inline guidance | Users avoid recoverable failure |57| Rule depends on server state | Preserve input and return a specific recoverable error | Submission failure does not erase work |5859## Quality Standards6061- Preserve repository terminology and trace every material choice to project context.62- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.63- Cover error, empty, edge, recovery and operational cases relevant to this skill.64- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.65- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.6667## Anti-Patterns6869- Using placeholder text as a label. Fix: provide persistent visible labels.70- Writing `Invalid input`. Fix: state what failed and how to correct it.71- Clearing a form after server error. Fix: preserve safe values and focus the error summary.72- Inventing consent language. Fix: route it to the authorised legal/privacy owner.73- Measuring page views instead of completion. Fix: define start, success, abandonment and error events.7475## References7677- [Content and form quality gates](references/ux-content-and-form-quality-gates.md)78- [UX Specification neighbour](../05-ux-specification/SKILL.md)79- [Human English and reader-centred craft](../../book-extractions/human-english-craft-synthesis-2026.md) for calm, grammatical, state-aware microcopy.80<!-- dual-compat-end -->818283848586## Output Shape8788Write `projects/<ProjectName>/<phase>/<document>/UX_Content_And_Form_Specification.md` with content principles, content inventory, form requirements, validation matrix, state copy matrix, accessibility gate, and measurement plan.89
peterbamuhigire