Forms Are the Front Door: Designing Intake Forms That Get Complete Information

Every request your team receives starts somewhere. If that somewhere is an email, a hallway conversation or a row someone added to the shared sheet, the first step of your process is always the same: going back to ask for the information you needed in the first place.

A good intake form ends that loop. It’s the front door to your process, and like any front door, it shapes the first impression. Make it confusing or tedious and people will climb in through the window instead.

Start from what the work needs, not what you’re curious about

The most common form mistake is asking everything that might ever be useful. Each extra question costs the requester time, and every question that feels pointless erodes their goodwill for the ones that matter.

Before you build, sit down with whoever actually does the work and ask: “To start on this request, what do you need to know?” Not “eventually”, not “for reporting”, but to start.

For a fictional facilities team handling office move requests, that list was short:

• Who is moving, and from where to where
• Requested date
• Equipment that needs moving (desk, monitor, storage)
• Any accessibility needs

Their old form asked eleven more questions, including the requester’s manager, their cost centre, and “reason for move”. Every one of those was either already known from the requester’s profile or never read by anyone. Cutting them halved the time to submit and, more usefully, ended the habit of people skipping the form and emailing.

Don’t ask what you already know

If a person is signed in, the form should know their name, email, team and location. If the request is about an existing client, let them pick the client from a list and pull the details automatically.

This does two jobs. It saves typing, and it removes a whole category of errors: misspelled names, outdated department names, the same client entered three ways. Picklists, Free Text and Everything Between: Designing Fields People Fill In Correctly covers how to choose the right field type for what remains.

Conditional questions keep the form short for most people

A conditional question only appears when an earlier answer makes it relevant. If someone answers “Yes” to “Does this involve a new supplier?”, the form then asks for the supplier’s details. If they answer “No”, those questions never appear.

This lets one form handle several variations without becoming a wall of fields. Some practical guidance:

• Put the branching questions first. “What kind of request is this?” near the top lets the rest of the form tailor itself.
• Keep the branches shallow. One or two levels of “if this, then ask that” is manageable. Five levels becomes a maze nobody can test.
• Consider separate forms for very different requests. If two branches share almost nothing, they’re two forms pretending to be one.

Most form builders and no-code database platforms support conditional logic. Test every path yourself before launch, because a hidden required question on a branch nobody tested is a classic way to make a form impossible to submit.

Helpful defaults and examples

Defaults pre-fill an answer that’s right most of the time. Requested date defaults to two weeks out. Priority defaults to “Normal”. Location defaults to the requester’s office. People can change them, but most won’t need to.

Be careful with defaults on fields that matter for decisions. If “Urgent: No” is pre-selected, that’s sensible. If “Budget approved: Yes” is pre-selected, you’ve built a form that lies by default.

Where an answer needs explaining, use hint text and examples rather than long instructions:

• Instead of “Describe the issue”, try “What happened, and what did you expect to happen? Example: ‘Badge reader on floor 3 rejects my card since Monday.’”
• Instead of “Estimated value”, try “Estimated value in dollars, excluding tax. A rough figure is fine.”

That last phrase does a lot of work. “A rough figure is fine” turns a question people stall on into one they answer.

Required fields: fewer, firmer

On a form, every required field is a hurdle. Keep them to what’s genuinely needed to start, and make the rest optional or ask for them later in the process. Required Fields and Validation: Stopping Bad Data at the Door goes further on stage-based requirements; the short version is that the intake form should only require what the first person in the process needs.

Validate where you can do it kindly. A date in the past, an email without an “@”, a quantity of zero: catch these on the form with a clear message, rather than letting them through for someone to chase.

The confirmation message is part of the form

Most forms end with “Thank you for your submission.” That’s a missed opportunity. The requester has just handed over a problem, and their next thought is “now what?”

A good confirmation answers it:

• A reference number they can quote
• What happens next and roughly when (“The facilities team reviews requests every Tuesday and Thursday”)
• Where to check status
• Who to contact if it’s urgent

Send the same information by email or through your chat tool so they have a copy. You’ll be surprised how many “did you get my request?” messages this stops.

Test with real people, then watch the data

Before launch, ask three people who’ll actually use the form to submit a real request while you watch, without helping. Note where they hesitate, what they ask, and what they type into free-text fields. You’ll find at least one confusing question every time.

After launch, look at the submissions for patterns:

• Fields where most answers are “n/a”, “see above” or blank
• Free-text fields where the same answers keep appearing (these want to be picklists)
• Requests that always need a follow-up question (that question belongs on the form)

Project Intake: Turning “Can You Just…” Requests Into a Managed Queue covers what happens once the request is through the door.

Where to start this week

1. Ask the person who processes requests to list what they need to start work. Compare it to your current form and cut anything not on the list.
2. Replace any field the system already knows (name, team, client details) with an automatic fill.
3. Rewrite your confirmation message to include a reference, the next step, a timeframe and a contact.
4. Watch three people fill in the form and fix the first question that trips them up.