Surveys are attractive because they look scalable. That advantage disappears when the questions are broad, the trigger is random, the audience is unclear or the team has no plan for the answers. A hundred responses to “How do you like the app?” can be less actionable than five observations tied to a specific task.

Start with the broader app feedback guide. Then use this question bank to collect structured evidence at moments when you cannot interview every user.

Write one sentence: “We will use this survey to decide whether…” Examples include whether onboarding should be simplified, whether a result is trusted enough to reuse, which failure prevents activation, or whether a beta cohort is ready for a broader launch.

The GOV.UK Service Manual recommends agreeing research objectives and turning assumptions into research questions before choosing activities. It also notes that surveys and benchmarking usually need far more participants than qualitative methods to produce clear findings. A survey should therefore complement observed behavior and interviews, not imitate them badly.

Trigger onboarding questions after the user has attempted the first valuable action—not immediately after account creation. Useful options include:

The first question identifies intent. The second creates a simple outcome segment. The remaining questions diagnose why the outcome differed. Avoid asking all five if two will support the decision.

Use an event-based survey when the product knows that a user just generated, saved, shared, purchased or completed something. The event gives the response context.

Prefer answer options that cover reality. Include “Not applicable,” “I did not try,” or “I am not sure” when those states are possible. Forcing a rating from someone who never completed the task creates false precision.

Ask near the failed or cancelled journey when possible. If you wait weeks, recall becomes less reliable.

Do not present a cancellation survey as a hostage screen. Make it optional, preserve the user's chosen action and collect only what the team can use. A person deleting data or ending a paid service should not have to justify the decision before the product obeys it.

An AI feature needs questions about evidence and control, not just satisfaction.

Ask:

Avoid implying that a fluent response is correct. If the app supports consequential actions, instrument whether the user reviews or edits the result and provide appropriate approval boundaries.

Label each endpoint and make the scale match the construct. “Very difficult” to “Very easy” measures perceived ease; it does not measure success. “Not completed” to “Completed without help” captures a different outcome. Do not compare scores across materially different questions or triggers.

Keep the direction consistent within one survey. If a higher number sometimes means better and sometimes worse, analysis errors become likely. Include the question text, scale labels, trigger, eligible audience and date when reporting a number.

Avoid double questions: “Was the app fast and easy?” A user may think it was fast but confusing. Avoid leading language: “How helpful was our improved dashboard?” Avoid unexplained jargon and absolutes such as “always” or “never” unless the behavior genuinely requires them.

Do not ask users to rank a long list of imagined features as the main evidence for a roadmap. Their current problem, workaround and commitment provide better context. Do not collect sensitive personal details simply because the form allows custom fields.

Segment by relevant context before averaging: intended job, lifecycle stage, whether the task completed, device or plan when those factors matter. Read open responses alongside the segment instead of treating isolated quotes as votes.

Create a short findings table with observation, affected group, frequency in this sample, consequence, supporting behavior and owner decision. Mark assumptions explicitly. A small or self-selected response pool can surface issues but does not justify population-level percentages.

GOV.UK's research guidance recommends analyzing soon after a round, involving observers and deciding actions from findings. The same discipline prevents an in-app survey from becoming a permanent widget nobody owns.

We started from common product decisions—activation, task completion, trust, abandonment and repeat use—then adapted GOV.UK's guidance on clear objectives, relevant user groups, appropriate methods, analysis and participant privacy. The questions are original templates rather than quotations or fabricated user research.

Test the shortest relevant question set on a real project and document the trigger, audience, response count, and resulting owner decision. Do not publish response percentages without the underlying sample and question wording.

Ask two questions after one meaningful event:

Add one optional follow-up only when it supports the named decision. Publish the project with a specific feedback ask, review the answers with observed behavior, and record what the owner will do next.