Determining Form Length Based on Information Value Instead of General Shortness
The appropriate form length follows the information requirements: Each field needs a purpose for processing, decision-making, or reliable assignment.
For UX teams and web developers, the key aspects of "form length based on information value" are "subsequent use" and "appropriate time for data collection." The perspective "form scope, input, and error handling" shows how these two points interact in practice.
Published: 3 min read · Author: Sebastian Geier
How do you determine the correct form length based on information value?
The appropriate length results from the information that is actually needed in the current processing step. Each field needs a purpose, a recipient, and a comprehensible consequence if information is missing; stored data is eliminated, while necessary complex values are grouped in an understandable way.
Short at any cost
Short at any cost – Important information is missing, leading to avoidable queries, misrouting, or unusable requests after submission.
Stockpile field – Data is collected for potential future use, even though neither the process nor the decision currently requires it.
Free text as an abbreviation – Many structured questions are crammed into a single large message field, increasing the effort required for interpretation and uncertainty.
Subsequent use
Test criterion
Subsequent use
Each field has a named processing, decision, or assignment function that would not be equivalent without this information.
Test criterion
Appropriate data collection time
Information is only requested when it is necessary for the current step and cannot be reliably added later.
Understandable input load Necessary complex values are grouped, explained, and collected using appropriate input types instead of free text.
Appropriate data collection time
Document all form fields with a specific recipient, purpose, and consequences of missing information in a field inventory.
Remove unnecessary or premature values and translate necessary complex information into understandable groups and input types.
Review real-world processing cases from submission to internal use and compare new queries against missing information.
Understandable input load
Percentage of productive form fields with documented current purpose and named downstream process role.
Frequency of manual queries or misclassifications resulting from missing or unclear information.
Decision case: "Short at all costs"
A request form asks for budget, phone number, and full address, even though initially only the request and region are routed. Address and phone number are omitted in the first step; budget remains as an optional framework; processing later reveals whether a specific additional question is truly necessary earlier.
How "Form Length by Information Value" relates to related decisions
A suitable in-depth resource is available Prioritizing a UX Error List by User and Business Impact"How to Prioritize a UX Error List by User and Business Impact?"
In addition: Qualifying Project Requests with a Few, But Crucial Fields.
If you want to practically implement "Form Length by Information Value," you can refer to Robust Website Systems . This focuses on "Form Scope, Input, and Error Help" and "Subsequent Use."
Conclusion: Form Length by Information Value
The appropriate form length follows the information needs of the current process. Brevity and completeness are the results of well-defined fields, not blanket goals.
Sources and Further Information
These primary sources make the assumptions, system boundaries, and verification methods for "form length based on information value" transparent.
Collecting Personal Information from Users — GOV.UK Service ManualThe guidelines limit the collection of personal data to necessary and proportionate information instead of a fixed number of fields.
Structuring Forms — GOV.UK Service ManualThe Question Protocol checks for each question why information is needed, how it will be used, and whether it is already available.
Key Thesis
Each field is checked against a specific downstream purpose and removed if it is not useful. Necessary complex information is explained and structured clearly.
What This Is Not About
The issue is not resolved with a single correction. Separate cross-checks are provided for "short at all costs," "stockpile field," and "free text as an abbreviation."
What it's about
Three requirements must be met simultaneously: "Subsequent use," "Appropriate time for data collection," and "Understandable input requirements." This results in a traceable path from planning to acceptance.
UX, navigation & forms
Use required fields only where they are truly necessary
"Form length based on information value" includes, as a separate check, the question: Which form fields must actually be completed?
UX, navigation & forms
Consciously design empty states, loading states, and error states.
"Form length based on information value" is supplemented by a separate decision: How can empty states, loaded states, and error states be designed to be helpful?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Understandable Input Load: Starting Point for Implementation
A field-by-field review can reveal the usage, recipient, and potential errors of each entry. Afterward, redundant data is removed, and genuine information gaps are identified more precisely rather than comprehensively.