# The website form planning worksheet Blitz Studio ยท Updated 2026-10-29 Source: https://blitzstudio.xyz/resources/website-form-planning-worksheet Use this worksheet to agree one website form before design and development. Copy the blank records into your project notes or download the Markdown version. Record actual decisions and open questions; the worksheet does not submit or store your answers on this website. ## Describe the form and its owner - **Form name and planned page:** - **Visitor task:** - **What a successful submission means:** - **Who receives and acts on the request:** - **Business decision owner:** - **Design and development owners:** - **Current status and next review date:** Define the difference between sending an enquiry, booking a confirmed appointment and creating an account. The interface should describe the outcome the system can actually deliver. Use the [accessible website form guide](https://blitzstudio.xyz/blog/how-to-plan-an-accessible-website-form) for the reasoning behind the records below. ## Copy this record for each field - **Field label visible to the visitor:** - **Why the answer is needed now:** - **Who uses the answer and for which decision:** - **Required or optional, and how that is explained:** - **Control type and allowed answers:** - **Helpful instruction or example:** - **Validation rule confirmed by the implementer:** - **Message for a missing answer:** - **Message for an invalid answer:** - **How the label, help and error connect to the control:** - **Open issue, owner and decision date:** Review both an empty field and a field containing an answer. Confirm that its purpose and any important instruction remain available after typing. This is a specification record; it is not working validation code. ## Define each submission state - **Ready:** What explains the task and the main action? - **Sending:** What tells the visitor that the request is being processed? - **Field error:** How does the visitor find the affected field and correct it? - **Temporary failure:** What was not completed, which answers remain and what can the visitor do next? - **Accepted:** Which actual system event supports the confirmation? - **Next step:** What happens after acceptance, and who owns it? - **Repeat submission:** How is an accidental repeat handled and explained? Write the proposed text for each state and have the responsible owner approve it. Do not invent a reply time or present an unaccepted request as a success. ## Record delivery and data decisions - **Endpoint or service owner:** - **Where a submission record is stored:** - **Who can access the record:** - **How a notification is routed:** - **How failed delivery is detected:** - **Who responds to a failed delivery:** - **Approved test data and cleanup process:** - **Responsible owner for privacy and retention decisions:** Keep real passwords, customer messages and other sensitive information out of this worksheet. It prompts a handoff conversation; it does not set an organization's legal or retention policy. ## Fictional worked field record This sample is for a fictional design consultancy requesting enough information to arrange a project conversation. Replace every sample decision with the actual project's reviewed requirement. - **Visible label:** Email address. - **Reason needed now:** The team needs a reply destination for this enquiry. - **Required status:** Required; explain this before submission. - **Control:** An email input with its visible label associated in the implementation. - **Help:** Use an address where the team can contact you about this request. - **Missing-answer copy:** Enter an email address so we can reply. - **Invalid-answer copy:** Check the email address, for example name@example.com. - **Recovery expectation:** Keep the visitor's other valid answers while they correct this field. - **Unresolved item:** The developer must confirm the actual validation and submission behavior before the wording is approved. These are illustrative requirements and sample copy. They are not evidence of a tested client implementation or a universal validation rule. ## Keep a review record for each task - **Task and starting condition:** - **Environment, date and reviewer:** - **Input method or assistive technology where relevant:** - **Synthetic test answers used:** - **Expected result:** - **Observed result and evidence location:** - **Issue severity and owner:** - **Resolution and repeat-test result:** Include ordinary completion, an omitted required answer, an invalid answer, a temporary failure and an optional field left empty. Review keyboard use and a narrow mobile viewport. Confirm actual delivery through an authorized test; a browser confirmation alone does not establish that an inbox or team received the request. ## Agree what is ready to ship Name unresolved issues and who can accept or resolve them. Record what was actually reviewed, rather than marking the whole form accessible after one automated result. Use the [website launch checklist](https://blitzstudio.xyz/resources/website-launch-checklist) for surrounding navigation, content and release checks. ## Sources and scope - [W3C: labeling form controls](https://www.w3.org/WAI/tutorials/forms/labels/). - [W3C: form instructions](https://www.w3.org/WAI/tutorials/forms/instructions/). - [W3C: user notifications](https://www.w3.org/WAI/tutorials/forms/notifications/). Prepared 29 October 2026. This planning resource and its fictional example support a review process; they do not certify accessibility or test a backend. The cover previews this actual worksheet. Answers stay in your own project document or downloaded copy.