List or text field: which should you use?

Dropdown vs text field is a small design decision that changes both visitor effort and staff review. A dropdown gives staff tidy data. An open-text field gives the visitor room to explain. Neither is automatically better.

The right choice depends on the decision that follows the submission. Pick the control that helps the visitor answer accurately and lets the team review the result without guessing.

Let the staff decision choose the control

Start with the work, not the field. If staff need to route a request to a known department, a fixed choice may be useful. If staff need to understand an unusual problem, the visitor probably needs space to explain.

• For a known classification, choose from a short, stable set.
• When the context is unknown, let the visitor describe the situation.
• When both matter, use one structured choice plus a short explanation.

This avoids a common mistake: using open text for a decision the business has already standardized, or forcing a complex request into categories that do not fit.

Use a dropdown when the choices are stable

A dropdown works when the available answers are known, distinct, and unlikely to surprise the visitor. Examples include location, service line, existing-customer status, or a request type that maps to a real team.

• Keep the list short enough to scan.
• Use the words visitors use, not internal department names.
• Do not make a placeholder look like a valid answer.
• Avoid overlapping choices such as “support,” “technical help,” and “website issue.”
• Add an honest escape path when the list may be incomplete.

The GOV.UK select guidance recommends using a select only when people can understand the choices without needing to see all of them at once. For a very short list, radios may be easier to compare.

Use open text when context changes the answer

Open text is useful when the facts do not fit a stable list: describing a fault, explaining a project goal, outlining a complaint, or sharing the constraints behind a quote request.

A blank box with “Message” above it asks the visitor to design the answer. Give the field a job instead.

• Weak: “Tell us more.”
• Better: “What are you trying to accomplish, and what is stopping you?”
• Weak: “Describe the issue.”
• Better: “What did you expect to happen, and what happened instead?”

The GOV.UK textarea guidance also cautions against setting an arbitrary maximum character count. If a real limit exists, explain it and show people how much room remains.

Add an “Other” path with care

“Other” is useful when the list cannot cover every valid answer. It is not a substitute for maintaining the list.

If visitors choose “Other” often, review what they write. A repeated answer may deserve its own option. A confusing answer may show that the categories use internal language. A one-off answer may confirm that the open path is doing its job.

When “Other” is selected, reveal a short text field with a specific label. Do not leave staff with a category that says nothing and no explanation to review.

Write labels that reduce guessing

A good control cannot rescue a vague label. The W3C guidance on labels and instructions explains that people need labels or instructions when content requires input.

• Put the visible label next to the control and keep it available after the visitor starts typing.
• Use help text for format, scope, or examples; do not repeat the label.
• Say why sensitive information is requested, or do not ask for it.
• Write error messages that explain how to fix the answer.
• Keep optional fields visibly optional.

Clear labels improve the visitor experience and the downstream review. Staff see fewer answers that need translation, and automation receives less ambiguous input.

Do not make AI compensate for a weak question

AI can summarize open text, suggest intent, or flag missing context. It should not be the excuse for a confusing form.

The Pain Point and Intent action is useful when the visitor’s own words carry meaning. Content Quality Validation can help review whether an answer is usable. Keep the original answer visible and treat the result as a review aid, not a replacement.

Structured choices still have value. A dropdown can give staff a reliable routing signal while a short text field supplies the context. That combination often asks less of the model and less of the reviewer.

Test review cost, not only completion

Completion rate matters, but it does not show whether the answers are useful. Test the field with real examples and review both sides of the exchange.

1. Give the question to someone who did not write it.
2. Use five recent submissions or realistic examples.
3. Check whether visitors can choose or write an accurate answer without extra explanation.
4. Ask staff how long it takes to assign, reply, or request clarification.
5. Change the field only when the same problem appears more than once.

If open-text answers keep exposing the same confusion, use the guide to fix form questions that AI keeps flagging. If the field is not needed for the review job, consider the case for not sending every form field to AI.

A quick field-choice checklist

• Is the answer set known, short, distinct, and stable? Consider a structured choice.
• Does context change the meaning? Use open text.
• Do staff need both a routing signal and an explanation? Use both.
• Could the options exclude a valid answer? Add a clear escape path.
• Can someone understand the label without knowing your internal process? Rewrite it if not.
• Does the answer change the next decision? Remove the field if it does not.

After the form is clear, the Sentient Forms Action Library can help you choose a focused review job. Check the current WordPress.org listing for supported Form Sources and installation details.