# Form principles ### Only ask for information you need Every question you add decreases how many users complete the form. ### Order questions from easiest to hardest Start your form with the easiest questions, like a user’s name. Move to the harder questions, like business income or project plan details. ### One question = one page This helps users fill out the form, especially users with low literacy. This does not mean only one input field per page. Fields should be grouped into small, logical groupings, like: * Contact information (email, phone, mailing address) * About you (Name, date of birth) * Your business (Business name, business address fields) These groupings should be based on mental models that the user has about the process, not the structure of City departments or our programs. A few examples are: * Personal information * Information about my business * Eligibility questions * Uploading documents ### Disclaimers and links to legislation Put any disclaimer or link to the legislation at the bottom of the page, if you need it. If a specific input is legally required, note that in the help text and link to a deeper source, if necessary. If a user must agree to legal terms, include that towards the end of the form. Mention it in the form introduction so they are aware before they begin. ### User research Whenever possible, a form should be tested with the target user group before launch. Test with users most likely to meet your research objectives for usability. You’ll learn the most if you focus on users who are likely to struggle using your forms or have challenges with: * Accessibility * Equity * Tech savvy --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://sfdigitalservices.gitbook.io/style-guide/how-to-write-forms/form-principles.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.