Use this worksheet to connect a website problem with its message, recovery action and observed result. Copy the blank records into project notes or download the editable Markdown. This page does not collect or save completed answers. Keep private test data and operational evidence in the project's approved document system.
Describe the task and the review
- Website and page URL:
- Visitor task and intended completion:
- Content owner and implementation owner:
- Services or integrations involved:
- Reviewer, environment and date:
- Scope of this review:
- Known limits and unresolved decisions:
Use the error-message guide for wording and the form planning worksheet for the wider input/submission contract. Agree the actual states before labeling any of them as passed.
Copy this record for each error state
- State identifier and location:
- Condition that triggers the state:
- Where the condition is detected:
- What the system knows about the outcome:
- What remains uncertain:
- Visitor-facing message:
- Known correction or recovery step:
- Recovery control label and actual behavior:
- Information retained or lost:
- Owner of unresolved behavior:
Distinguish an input correction from a service failure or an uncertain submission result. Do not tell someone that nothing was sent, that everything was saved or that a retry is safe without evidence from the actual implementation.
Plan how the message is communicated
- Trigger: typing, focus change, submission or another event:
- Visible placement and relevant field or task:
- Text association with the control, if applicable:
- Focus behavior, if applicable:
- How a dynamic change is communicated:
- Text that explains any visual cue:
- When the message clears or changes:
- Who verifies the implementation:
A screenshot can show placement and wording at one moment. It cannot establish every keyboard, assistive-technology or recovery behavior. Record those observations separately when they are actually checked.
Connect processing and completion
- What the visitor sees while the action is processing:
- Evidence required before showing completion:
- Completion message and next destination:
- What happens if confirmation is unavailable:
- How duplicate attempts are handled, if relevant:
- How the owner notices delivery failures:
- Available support route and actual owner:
Keep the wording consistent across states. A page should not tell the visitor that an action both completed and failed. If completion is uncertain, describe the agreed next step rather than inventing a definite outcome.
Fictional example: a required project detail
This is an illustrative planning record, not a tested client form.
- Task: Prepare a project enquiry for review.
- Condition: A required project-summary field is empty at submission.
- Known outcome: The implementation must confirm whether submission was prevented before this record is approved.
- Proposed message: Add a short project summary so we can understand your enquiry.
- Proposed recovery: Return to the identified summary field and retain the other appropriate input.
- Unresolved checks: Confirm the real required-field rule, field association, retained values and subsequent submission result.
- Owner: The project's named implementer and content reviewer.
Replace these assumptions with the actual project's decisions. A service timeout or unknown delivery outcome needs a separate state record and different recovery wording.
Record a review attempt
- State and test environment:
- Authorized test input and setup:
- Steps actually performed:
- Expected result and its source:
- Observed message, behavior and outcome:
- Evidence location:
- Uncertainty or defect:
- Issue owner and agreed change:
- Repeat-check date and result:
For AI browser-agent work, the agent and WebMCP guide explains how to keep an emerging integration evaluation tied to a defined task. Record the actual environment and completion boundary rather than treating a demonstration as universal support.
Close the state review
- Approved message and behavior:
- Evidence supporting approval:
- Remaining limitation:
- Operational owner after launch:
- Next review trigger:
Sources and scope
Prepared 2 November 2026. This worksheet supports planning and evidence capture. It does not establish complete accessibility compliance, delivery reliability or improved conversion.
The Blitz Studio team
We design brands, build websites and engineer digital products.
Talk about your next project
