Required question

Picture this: a marketer is collecting feedback after a webinar. The questionnaire has 12 questions, all marked with an asterisk — all required. One of them reads: "Describe what you liked most (long-form answer)."

The respondent is in a hurry and not ready to write a paragraph of text, but skipping isn't allowed — the system won't let them move on. They type "ok" and head to the next screen. Technically, an answer was received. In reality — it wasn't. The required-question mechanism turned against its creator: instead of valuable feedback, the questionnaire collected three hundred empty placeholders like "fine," "." and "123."

What "required question" means

Required question (Required Question, Forced Response) — a setting in which the respondent cannot move to the next page or finish the questionnaire without answering this question. Such questions are usually flagged with an asterisk (*) or a special marker next to the wording.

The idea seems obvious: if a question matters — make it required, and the data will be complete. In practice, it's more complicated. Requiredness is a trade-off between completeness of information and a person's willingness to provide that information. Push too hard, and you'll get either "junk" answers or a questionnaire abandoned halfway through.

Data completeness vs. honesty of answers

Required questions have an obvious advantage: they guarantee that the final table holds a value next to every respondent rather than an empty cell. That's convenient for analysis — no need to deal with gaps, recalculate shares, or figure out how to interpret a missing answer.

But "a value in the cell" and "an honest answer" are different things. When someone is backed into a corner, they act out one of three scenarios:

The "just leave me alone" scenario. The respondent picks the first option they see or types random characters into a text field. On the surface the answer looks fine, but in substance it's random. Detecting such answers during analysis is nearly impossible — especially in multiple-choice questions, where a "random click" is indistinguishable from a deliberate one.

The "I'm leaving" scenario. The respondent closes the tab. You get neither an answer to the forced question nor answers to everything that follows. Instead of one gap in the data — an entire lost record. Research in survey methodology shows that each additional required question raises the Abandonment Rate (the share of people who quit the questionnaire) by 2–5%.

The "socially desirable answer" scenario. The respondent doesn't want to share their real opinion (the topic is sensitive, the answer is unpleasant), but isn't ready to leave either. They pick a "neutral" or "positive" option — the one that looks safer. The result: a systematic shift in the data toward the socially acceptable.

Making a question required doesn't guarantee sincerity — it only guarantees that the field won't stay empty. And an empty field is sometimes more honest than a random click.

When a question really is worth making required

Not every question deserves an asterisk. Requiredness is justified in a few specific situations.

Screening and filtering questions. If the respondent's route through the questionnaire depends on the answer, a skip breaks the whole logic. The question "Are you a customer of our company?" must be required — otherwise the system won't be able to send the person down the right branch.

The study's key metric. If the entire survey was launched for the sake of a single indicator — say, NPS or CSAT — skipping precisely that question makes the whole run pointless. Here requiredness is in the right place.

Identification fields. An email for sending results, an order number to tie the answer to a transaction, a name for personalization — all of these lose their meaning if the field can be skipped.

Questions with minimal cognitive load. Choosing one option out of three or four, a scale from 1 to 5, yes/no — the answer takes a second and causes no difficulty. Here requiredness neither irritates nor nudges anyone toward deception.

When it's better to leave a question optional

Open-ended text questions. A detailed answer is an effort. Not every respondent is willing to put thoughts into writing, and forcing it produces a stream of ".", "-", "no," "all fine." Such answers aren't merely useless — they create the illusion of data that doesn't actually exist. Leave text fields optional: those who have something to say will say it; the rest will skip, and that's fine.

Sensitive topics. Questions about income, age, health, political views, religion — anything a person might consider too personal. A forced answer here yields not honest data but defensive data. The person will either lie or leave. Neither outcome is useful to you.

Clarifying and secondary questions. If a question was added "just in case" or out of curiosity, rather than because analysis is impossible without it — don't make it required. It isn't worth losing a respondent over.

Long questionnaires. If a survey has 20+ questions and every one is required, it's a marathon with no right to a breather. Fatigue builds up, patience runs out, and after the tenth "required" question the respondent starts click-throughing without reading. The longer the questionnaire, the more generous you should be with optionality.

Practical techniques

The 70/30 rule. A benchmark for most surveys: around 70% of questions are required (the ones without which analysis is impossible), 30% are optional (clarifying, open-ended, sensitive). It's not a rigid standard, but a starting point that helps you avoid overdoing it in either direction.

The "Prefer not to answer" option. For sensitive questions that still matter, there's an elegant compromise: add a "Prefer not to answer" or "I'd rather not say" option and make the question required. The respondent feels no pressure (they have an out), and you distinguish a conscious refusal from an accidental skip.

Soft validation instead of hard. Some platforms let you show a warning — "You haven't answered this question — do you want to continue?" — instead of a hard block. The respondent sees a reminder but keeps freedom of choice. This lowers the skip rate without raising the rate of junk answers.

Test on a pilot. Before launching the survey to the full audience, run it on 15–20 participants and see where people get stuck. If completion time spikes on some required question, or the questionnaire gets abandoned there — that's a signal to reconsider its status. More on piloting in the article Pilot Study.

How it works in SurveyNinja

In the SurveyNinja builder, any question can be made required with a single toggle in the element's settings. A marker (an asterisk) is shown next to such a question, and when the respondent tries to move to the next page without an answer, they see a prompt.

A detailed setup guide is in the article "How to make a question required."

Useful nuances:

• Requiredness is configured for each question separately. You don't switch on an "everything required" mode at the questionnaire level — the decision is made point by point, taking into account the role of each specific question.
• Compatibility with branching. If a question is required but hidden from the respondent through logic branching (because it doesn't fit their route), no conflict arises. The person won't see the question and won't be forced to answer it.
• Analytics of incomplete responses. If the respondent did abandon the questionnaire on a required question, their partial answers are saved in incomplete responses. This lets you track exactly which question the "drop-off" happens on and decide what to do: soften the wording, remove the requiredness, or drop the question entirely.

A required question is a tool with a hidden catch. It guards against skips, but with careless use it spawns something worse than a skip — false data that looks like the real thing. The golden rule: make required only what analysis loses its meaning without.