Design an intake form people can finish

A request form has a narrow job: capture enough context for someone to understand and route a piece of work. It does not need to solve the entire process at the moment of submission. Forms become hard to finish when every possible detail is required from every person, even when some fields do not apply.

Start with the next decision

Before adding fields, write down what the receiving team needs to decide first. A facilities team may need a location and description. A purchasing reviewer may need purpose, amount, timing, and a quote. An access request may need an approved role and system, while sensitive credentials should never be collected in a general intake form. The initial form should support that first decision, not attempt to model every future step.

Separate required facts from helpful context

Make a field required only when a missing answer would prevent routing or review. Use optional fields for context that may be useful but is not always available. When a value is uncertain, let the requester say so. A clearly marked estimate is safer than a required numeric field that encourages someone to invent precision.

Use labels that name the information directly. “What do you need?” is usually easier to answer than an internal acronym. Explain why a field is requested when the answer may not be obvious. Keep examples short and relevant to the expected response.

Use conditional questions sparingly

Conditional fields can reduce clutter when different request types need genuinely different information. Keep the first choice simple and explain the available categories in terms requesters recognize. If choosing a category produces a long second form, reconsider whether the process can begin with a smaller shared intake and follow up with the assigned owner.

Tell people what happens next

Before submission, explain who reviews the request and what acknowledgment to expect. After submission, distinguish clearly between “received,” “approved,” and “scheduled” so requesters understand the current state.

Protect the boundary

Tell requesters what not to include. A routine service form may not be an appropriate place for passwords, payment card details, medical information, or confidential customer files. Link to the organization’s approved secure channel where needed. Collect only the information required for the stated purpose, and make sure the privacy notice describes the real data path.

Test with real requesters

Ask a few people who submit requests to complete the draft without coaching. Watch where they pause, choose “other,” or add an explanation in the wrong field. Ask the receiving team whether each submission supports the next decision. Remove fields that nobody uses and clarify fields that repeatedly trigger follow-up. A shorter form is not automatically better if it creates more back-and-forth; the goal is sufficient, understandable information with low friction.

Review the form as the process changes

Request categories and team responsibilities change. Assign an owner to review field labels, routing assumptions, and confirmation text periodically. Keep old records interpretable when fields change, and avoid renaming a field in a way that changes its meaning without documenting the transition. Good intake design respects both the person asking for help and the person who must take responsibility for the work.