A short form can still be difficult. If someone has to work out what “required date” means, translate their project into internal service categories or invent an answer to a question they’re unsure about, the effort isn’t just typing.
Good inquiry-form design reduces that mental work. It helps a person understand what is being asked and answer honestly.
Nielsen Norman Group’s July 2025 form guidance discusses structure, transparency, clarity and support as ways to reduce cognitive load.1 The practical opportunity is to examine the decisions the form asks people to make, rather than judge it only by the number of fields.
Let’s work through a fictional equipment-rental inquiry where the customer is organizing an event and doesn’t yet know the exact quantity required.
Let the questions follow the planning task
The business needs enough context to respond usefully. The customer needs a way to explain what is known without pretending the event plan is finished.
Begin by distinguishing an inquiry from a confirmed reservation. A form collecting preferences should not use language that implies equipment has been held.
Put each date into a recognizable role
“Required date” could mean the day of the event, the preferred delivery day or the deadline for receiving a quote. The business may understand its internal meaning. The customer cannot be expected to inherit that knowledge by looking at the calendar icon.
Use a specific label and explain the distinction where it matters. If delivery and event dates can differ, give them separate roles in the data and interface.
Show the format and any relevant constraints before a failed attempt. If a date is approximate at inquiry stage, allow the customer to indicate that. A forced exact date can become inaccurate operational information very efficiently.
Slow pages and outdated forms were holding Office Accomplice back. See how the redesign fixed both.
Group information that belongs to the same decision
For our sample inquiry, event details could sit together, followed by equipment interests and contact information. The organization should help the person understand what they are describing.
Keep related labels and help text visually connected to their fields. A long horizontal layout may look compact while making people search for the question associated with each input.
The final order depends on the task. If an early choice changes which follow-up questions are relevant, ask it before showing those follow-ups.
The customer should not need to answer questions about collection after selecting delivery. A form can accept contradictory information while remaining entirely satisfied with its validation rules.
Let uncertainty produce a useful answer
Suppose the customer knows the event has around fifty guests but doesn’t know how many tables are appropriate. A required quantity field invites a guess.
The form could instead collect the context needed for a recommendation. Make it clear that the business will discuss the final selection.
For this fictional inquiry, useful prompts might include:
- The approximate number of people the equipment should serve.
- The kind of event and how the space will be used.
- Equipment the customer already knows they need.
- Any important question or constraint they want the team to consider.
These are sample prompts, not a reason to add four new required fields to every rental form. Keep only what the team will actually use at this stage.
Check out this blog: The form found a problem. Now help the person finish.
Support the person when an answer needs correction
Reducing mental effort includes the moments when something goes wrong. The interface should explain the problem and help the person continue without losing their progress.
A message saying “invalid input” is technically a response. So is a shrug.
Keep the original answers, identify the relevant field and explain what needs to change. If the form has a summary of errors, let people move from it to the affected questions. Check keyboard access and the way assistive technology communicates the errors.
The confirmation should also match the task. If the form requested a quote, confirm that request and explain the next step. Don’t call it a booking unless a booking has actually occurred.
I would test this form with someone planning a plausible event. Ask them to explain what they think each uncertain field means, then watch what information they leave to find.
That can reveal a label that needs rewriting, a question that belongs later or a missing option for someone still exploring. Measure any completion or inquiry-quality change with the business’s own data; another site’s research cannot supply that result.
The best version feels like a helpful first conversation. The person explains their event, the team receives enough context and neither side has to reverse-engineer what “required date” was supposed to mean.