UX survey questions aren't universal. The question that works in discovery — "What's the hardest part of your current workflow?" — is useless after launch, where the thing is already built and what matters is what's broken. Ask a post-launch question during discovery and you're researching a product that doesn't exist yet; ask a discovery question after shipping and you've wasted a response slot on context you already have. So before you pull a single question, figure out which phase you're in: discovery, usability testing, post-launch, or ongoing pulse. Each phase has a different goal, a different question style, and a different moment to send. Below are 40+ questions organized by phase, with the timing that makes each one work.
Phase 1 — Discovery Questions (Before You Build)
The goal here is to understand how the user already works — their behavior, pain points, and context — before a single screen gets designed. You're not testing a solution; you're mapping the problem.
"How do you currently handle [task]?"
"What's the hardest part of [task] with your current setup?"
"What have you tried that didn't work?"
"How much time do you spend on [task] per week?"
"What would have to be true for you to switch to a new tool for this?"
"When was the last time [task] caused a real problem for you? What happened?"
"Which part of [task] do you wish you could skip entirely?"
"What does good look like to you for [task]?"
"What tools do you use today for [task], and what do you like or dislike about each?"
"If you could change one thing about how you do [task], what would it be?"
These are open-ended by design — discovery is qualitative, and you're listening for language and unmet needs, not tallying scores. Keep the survey short (3–5 questions) or use it to complement interviews rather than replace them. Open-ends take effort to answer, so a long discovery survey gets you abandonments, not insight.
Two of these carry more weight than the rest. Question 5 — "what would have to be true for you to switch?" — tells you the actual bar your product has to clear, and it's usually higher and more specific than teams assume ("it has to import my existing data," not "it has to be better"). Question 8 — "what does good look like?" — gives you the user's own success criteria in their own words, which is what you'll design against later. If you only have room for three discovery questions, those two plus the hardest-part question (2) cover the most ground.
Phase 2 — Usability Testing Questions (During Build)
The goal shifts from understanding the problem to finding friction in a specific flow before it ships. The product exists now, at least as a prototype, and you're hunting for the exact points where users hesitate, misread, or give up. This is distinct from concept testing, which validates whether people want the thing before you build it — here the build exists and the question is whether it works.
"On a scale of 1–7, how easy was it to complete [task]?"
"At any point, were you unsure what to do next? If yes, where?"
"What, if anything, almost made you give up?"
"Did anything surprise you — positively or negatively?"
"Were there any words, labels, or icons you found confusing?"
"What did you expect to happen when you clicked [X]?"
"How does this compare to how you do [task] today?"
"What would you improve about this flow if you could?"
"How confident are you that you completed the task correctly? (1–5)"
"Would you use this feature in your actual work? Why or why not?"
Send these within 24 hours of the test session, while the memory is still specific. For remote usability tests, embed the survey directly after the task so there's no gap at all — the further you get from the moment, the more "it was a bit confusing" replaces "the Save button looked disabled."
The highest-signal pair here is questions 6 and 9. Question 6 — "what did you expect to happen when you clicked [X]?" — exposes the gap between your mental model and the user's, which is where most usability failures actually live. When the expected outcome and the real outcome diverge, you've found a labeling or affordance problem, not a user problem. Question 9 — confidence that the task was completed correctly — catches the silent failure mode where someone finishes the flow but isn't sure they did it right. A high completion rate paired with low confidence means the task technically works but doesn't reassure, and that gap predicts support tickets.
Phase 3 — Post-Launch Questions (After Shipping)
The goal is to check your assumptions against reality: did the feature land the way you designed it, where's the friction you didn't anticipate, and are people actually adopting it. The build is live and being used by people who weren't in your test sessions.
"How easy was it to get started with [feature]? (1–7)"
"Did [feature] work the way you expected?"
"What, if anything, was missing from [feature]?"
"How has [feature] changed how you do [task]?"
"What almost made you not use [feature]?"
"Did you find everything you were looking for?"
"What would have made your first experience better?"
"How does [feature] compare to what you used before?"
"Is there anything you expected to find here that you didn't?"
"How likely are you to keep using [feature]? (1–10)"
Send these 7–14 days after first use — early enough that the first experience is still fresh, late enough that the user has actually done real work with the feature rather than just clicked around once. Fire it on day one and you're measuring a first impression; wait a month and you're measuring a faded memory.
Read questions 5 and 9 together. Question 5 — "what almost made you not use [feature]?" — surfaces the friction that nearly cost you the user even though they pushed through; multiply those near-misses across everyone who didn't push through and you've found a real adoption leak. Question 9 — "is there anything you expected to find that you didn't?" — catches feature gaps framed as the user's expectation rather than your roadmap, which tends to surface the genuinely missing pieces instead of the ones you already planned to build. Both turn a vague "adoption is soft" into a specific thing to fix.
Phase 4 — Ongoing Feedback Questions (Recurring Pulse)
The goal is to watch satisfaction and sentiment move over time, so you catch a decline while it's still a trend and not yet a churn spike. The value isn't any single reading — it's the direction the line is heading.
"Overall, how satisfied are you with [product]? (1–7)"
"How likely are you to recommend [product] to a colleague? (0–10)"
"How easy is [product] to use on a day-to-day basis? (1–7)"
"What's working better than it was [X months ago]?"
"What still frustrates you?"
"How often do you use [product]?"
"Which features do you use most?"
"Which features have you tried but stopped using? Why?"
"What would you miss most if [product] went away?"
"What's one thing we could add that would make [product] more valuable to you?"
Run these on a fixed cadence — same questions, same timing — because a change in score only means something if the methodology didn't change underneath it. Reword a question between waves and you've reset the trend you were building. Keep recurring surveys to 5 questions max; completion rates drop sharply past that for non-incentivized audiences, and a pulse survey lives or dies on consistent participation. SegmentOS's recurring pulse setup lets you run the same 5-question survey on a fixed cadence without rebuilding it each time. If you need questions beyond UX — pricing, brand, or satisfaction for a broader study — start from a fuller bank of market research survey questions.
Questions 8 and 9 are your leading indicators. Question 8 — "which features have you tried but stopped using, and why?" — is the most honest churn signal in the set, because abandoning a feature you once adopted is a stronger negative than never trying it. Track which features keep showing up here over successive waves and you've got an early warning of what's quietly failing. Question 9 — "what would you miss most if [product] went away?" — tells you what's actually load-bearing, which is the thing you protect at all costs and lead with in messaging. Watch both move across waves rather than reading either as a one-time snapshot.
Build a study, reach verified respondents in your market, and get answers back in days.
Everything a research team does. Without the research team.
With SegmentOS you can build the study, reach a verified audience, and get data you can actually trust. End to end, no research background required.
Data quality
Every study runs through device fingerprinting, speeding detection, attention checks, and screener disqualification.
The 5 UX Survey Mistakes That Invalidate Your Data
The questions above only work if the survey around them is sound. These five mistakes are the ones that quietly turn good questions into unusable data — and they're dangerous precisely because the survey still runs, responses still come in, and a dashboard still fills up. Nothing looks broken. You only discover the problem when you try to act on the results and realize they don't hold, or when a decision made on bad data fails downstream. Catching these before you send costs minutes; catching them after costs a launch.
1. Asking hypotheticals. "Would you use a feature that did X?" feels like research, but people are notoriously bad at predicting their own behavior — they'll tell you yes and then never touch it. Stated intent runs systematically higher than real adoption, so a survey full of hypotheticals reads as enthusiasm and ships you a feature nobody opens. Ask about current behavior instead: what they do today, what tool they reach for, what the workaround costs them. Past action predicts future action far better than stated intent, which is exactly why the discovery questions above ask "how do you currently handle this?" rather than "would you want a tool that…"
2. Leading questions. "How easy did you find our new and improved checkout?" has already told the respondent the answer you want. The words "easy" and "improved" prime them to agree. Strip the adjectives and balance the scale ends: "How easy or difficult was checkout?" lets the answer carry information instead of confirming your hopes. The fix is almost always to remove your opinion from the question and let the respondent supply theirs.
3. Making it too long. Past 8 minutes, completion rates fall below 50% for unsegmented audiences. This isn't a guideline — it's consistent across platforms regardless of incentive. A survey longer than 8 minutes doesn't get you a representative sample; it gets you the answers of people who finish things, which is its own kind of bias. Time your survey before sending it.
4. Wrong timing. An in-app modal that interrupts an active task is the worst possible moment to ask for feedback — you're measuring annoyance, not experience. Wait for natural pause points: task completion, session end, a return visit. The timing notes in each phase above exist precisely because the moment you ask shapes the answer you get.
5. No follow-up path. Collecting open-ended responses you have no plan to read is theater. Either commit to reading and coding the qualitative answers, or don't ask the question and save the respondent the effort. Unread open-ends are worse than no open-ends — they create the illusion that you listened, and that illusion is what lets a known problem sit untouched for two quarters. Before you add an open-ended question, name who will read the responses and when. If you can't, cut it and add a closed question you'll actually act on.
SegmentOS's Website & UX Feedback template includes 12 pre-structured questions covering navigation, content clarity, design, and task completion — with access to a targeted consumer panel if you need responses fast. See the template →
Frequently Asked Questions (FAQ)
What questions should I ask in a UX survey?
It depends on your phase. In discovery, ask open-ended questions about current behavior and pain points. During usability testing, ask about task ease and points of confusion. Post-launch, ask about adoption and unmet expectations. For ongoing pulse surveys, ask about satisfaction and recommendation. Match the UX survey questions to where you are in the product lifecycle.
How many questions should a UX survey have?
Keep it short. Recurring pulse surveys should cap at 5 questions, since completion rates drop sharply past that for non-incentivized audiences. One-off surveys can run longer, but stay under 8 minutes total — beyond that, completion falls below 50% and your sample skews toward people who simply finish things.
When should you send a UX survey?
Timing depends on phase. Send usability surveys within 24 hours of the test session, post-launch surveys 7–14 days after first use, and pulse surveys on a fixed recurring cadence. Avoid interrupting an active task with an in-app modal — wait for natural pause points like task completion or session end.
What's the difference between usability testing and post-launch survey questions?
Usability questions find friction in a specific flow before shipping — "where did you hesitate?" Post-launch questions check adoption and unexpected friction after real users have it — "what was missing?" One catches problems pre-release; the other catches what your test sessions missed. Both use UX survey question examples tied to a specific moment.
What makes a UX survey question bad?
Three things invalidate most UX survey questions: hypotheticals ("would you use…"), since people predict their own behavior poorly; leading wording ("how easy was our improved checkout?"), which primes the answer; and bad timing, like interrupting an active task. Ask about real behavior, strip loaded adjectives, and wait for a natural pause to ask.
