All posts
4 min read

The anatomy of a great form template

A form is the interface between someone's need and a business decision. In most organizations, the quality of that interface dictates the speed of everything downstream. A poorly designed form is a tax — it produces dirty data, incomplete submissions, follow-up loops, and frustration.

Great forms aren't just well-styled. They're the product of careful information design, validation, and conditional logic. Here's what makes one good.

1. Clear instructions and context

Users approach internal forms with mild dread. Small upfront clarity buys a lot of goodwill.

  • Tell them what happens next. "IT will review this within 24 hours. You'll get a Slack DM when it's approved." Knowing the outcome calms the process.
  • Say what they need before they start. If you're going to ask for a tax ID or a specific PDF, list it at the top. Don't let them get to field 20 before they realize they need to go find something.
  • Use helper text to resolve ambiguity. Instead of a bare "Cost" field, use helper text: "Estimated, including shipping and a 10% buffer for taxes."

2. Group fields into sections

Cognitive load is the enemy of accuracy. Forty fields on one screen produces errors, because people start skimming.

Break the form into named sections with a clear purpose:

  • Requester info (often auto-filled).
  • The core request — what is actually being asked?
  • Budget and financials.
  • Technical or operational details.

For very complex intakes, a multi-step wizard can focus attention on one piece at a time. For most internal workflows, a well-sectioned single page feels faster and is easier to review.

3. Use the most specific field type

A generic text input is the fastest way to produce unusable data. Be precise about what each field allows.

  • Dropdowns and radios for predefined lists (priority, department). Prevents "Marcom" / "Marketing" / "Mktg" from becoming three things in your reports.
  • Single vs. multi-select. Be deliberate. If a person can only have one primary laptop, don't allow multi-select.
  • Date pickers with constraints. Future-only for requests; past-only for expense reports.
  • Email, phone, and currency validation. Catch obvious malformed inputs before submit.

Every time you use a stricter field type, you save cleanup work later.

4. Be ruthless about required fields

Every field has a cost. Assume guilty until proven useful.

  • The audit test. For each field, ask: will an approver actually look at this to make their decision? If not, delete it.
  • The optional trap. If a field is optional, it's usually empty. If you truly need the data, require it — but use conditional logic so it only appears when relevant.
  • Pre-fill what you know. If the system knows the user's name, email, manager, and cost center, don't ask again. Fetch it.

Shorter forms with well-placed required fields outperform longer forms with more optional ones.

5. Conditional logic: forms that adapt

Static forms are rigid. Great forms behave like conversations — the next question depends on the previous answer.

Example: a hardware request.

  1. "What do you need?" → user selects "Laptop."
  2. Only now show screen size and OS.
  3. If they had selected "Monitor," show resolution and mount type instead.

The form stays short for the user while still capturing the deep, specific data the downstream team needs.

6. Accessibility and mobile

Work happens on phones, trains, and sometimes assistive tech. Your forms need to handle it.

  • Focus states that are clearly visible for keyboard users.
  • Touch targets large enough to tap without squinting.
  • Contrast ratios that keep labels and helper text legible.

This isn't just compliance — it's whether people can actually finish your form.

The Requset form builder

Requset's builder is designed around these patterns: conditional logic, strict field types, sectioning, and accessible defaults — so the easy thing to build is also the good thing to build.

Browse example templates or start free and build one in a few minutes.