A survey that skips the five checks — question quality / branching behavior / mobile / pilot / final pre-launch confirmation — loses 1–2 weeks to rework once main fielding starts. Wording pitfalls show up in the respondent drop-off rate within 30 minutes of going live, and the quality of data you've already collected is essentially impossible to recover. This article organizes the five steps to run right before launch, together with operational procedures and deep-dive links to each dedicated article.
A 30-minute investment before launch prevents 1–2 weeks of rework after main fielding — that's the biggest reason to turn the pre-launch checklist into a ritual.
Step 1: Question Quality Check — Eliminate Double-Barreled, Leading, and Double-Negative Items
The quality of your question wording directly determines the quality of your responses. Simply reading each question aloud one by one right before launch is enough to catch most of the dangerous patterns.
Check items:
- Double-barreled questions: Are you asking about two elements in one question, like "Are you satisfied with the price and quality?"
- Leading questions: Are you pre-announcing the response direction, like "What do you think about the wonderful ~?"
- Double negatives: Are you using confusing structures like "Don't you think it isn't better not to ~?"
- Jargon and loanwords: Are there terms respondents don't use in daily life?
- Vague time references: Are you avoiding words like "recently" or "in general" whose interpretation varies?
Where many people fail: It's hard to notice errors in questions you wrote yourself. The single best defense is to have someone not involved in the design read them once. Another internal team, someone close to the customer, or even a family member will do.
For details, see Survey Question Wording — Complete Guide, which organizes seven dangerous patterns and rewrite examples based on Tourangeau's four-stage cognitive model.
Step 2: Branching Logic Verification — Walk Every Path on a Real Device
When branching logic (skip / display conditions / piping / carry-forward) is built in, the minimum bar is to walk every branch on a real device.
Minimum test procedure:
- For each branching trigger question, test-answer every expected response pattern (YES / NO / each option)
- After each answer, verify you reach the expected next question
- For piping questions, visually verify that the previous answer's text is correctly embedded
- For carry-forward questions, verify that the set of options being carried over is correct
Where many people fail: Testing only the "happy path" and overlooking edge cases (invalid responses, behavior when "Not applicable" is selected, back-navigation after a branch). It's common during main fielding for only respondents who selected "Not applicable" to get sent to a blank screen.
For details, see Complete Guide to Survey Branching Logic, which organizes how to use four types of branching features and design-time pitfalls.
Step 3: Mobile Real-Device Check — Don't Judge by PC Responsive View
The modern standard is that mobile accounts for 70% or more of web survey responses. Real-device verification on at least two devices — one iOS and one Android — is the core of the pre-launch check.
Check items:
- No layout breakage in both portrait and landscape orientations
- No horizontal scrolling on matrix questions
- Font sizes not too small (14px minimum recommended)
- Tap targets sufficient (44×44px minimum recommended)
- Appropriate textarea size for open-ended questions
- Progress bar displays correctly
Where many people fail: Judging "looks OK when I shrink it" using a PC browser's responsive view and never touching a real device. The responsive view and real devices differ completely in fonts, tap sensitivity, and IME behavior.
For details, see Mobile Survey Design Guide, which organizes five design principles for reducing cognitive load and the differences between iOS and Android.
Step 4: Pilot Distribution — Eliminate Main-Run Risks with N=30–100
Before launch, distribute to 30–100 people with attributes close to your target and detect main-fielding risks in advance. Dillman, Smyth, & Christian (2014) Internet, Phone, Mail, and Mixed-Mode Surveys: The Tailored Design Method (4th ed.) also positions pre-launch piloting as a required process.
Metrics to measure in the pilot:
- Completion rate: If below 80%, there's a problem with the question count or question quality
- Per-question drop-off rate: If a specific question alone has ≥50% drop-off, that question is the culprit
- Average response time: If it exceeds 1.5× the estimate, questions are too complex
- Open-ended content: If you see "I don't know" or "I don't understand the question," revisit the wording
Where many people fail: Skipping the pilot "because there's no time." You end up losing 1–2 weeks to rework after main fielding anyway, and the data you've already collected can't have its quality guaranteed.
For details, see Pilot Testing for Surveys — How Far to Validate Before Going Live, which organizes what you can validate with N=30–100 and how to combine cognitive interviews.
Step 5: Final Pre-Launch Confirmation — Intro, Thank-You Page, Distribution Settings
Beyond the questions themselves, final confirmation of the experience around the response (intro, thank-you page, notification emails) is also mandatory. Skipping this leads to complaints from respondents and a drop in completion rates.
Final check items:
- Intro copy: Does it clearly state expected duration / data usage purpose / whether there's a thank-you?
- Thank-you page: Beyond "Thank you for your response," is there a path to the next action (coupon receipt, result notification signup) if needed?
- Distribution URL: Decide whether you're using a shortened URL, QR code, or the direct URL
- Response cap / deadline: Cap values to prevent unexpected response overflow, and an automatic closing date/time
- Reminder emails: Settings for when and how many times to send, and that the unsubscribe link works
- Auto-reply emails: Final confirmation of the From address (don't leave it as no-reply), subject line, and body
Where many people fail: Sending with the From address left as "no-reply@" so respondents can't reply with their inquiries → complaint emails arrive at operations through a separate channel.
For details, see Survey Intro and Closing Message Guide, which organizes the design of four pieces of copy that drive completion rates.
Editor's Perspective — Turn the Check into a "Ritual"
From the standpoint of continuously following industry articles and public cases, here are three tips for putting pre-launch checks into actual implementation.
- Fix the checklist in your team's documentation. Persist the "five pre-launch items" in Notion / Confluence / Google Docs so check quality doesn't drop when the owner changes. Personalization is the biggest risk.
- Insert a ritual of "walking the five items together with another person" in the hour before launch. Solo checks miss things; in pairs, 30 minutes prevents 90% of incidents. A 30-minute investment is the best ROI for saving a week later.
- Have someone monitor for the first 30 minutes after launch. Anomaly detection on drop-off rates and per-question completion is easier to recover from the earlier you find it. If you detect within 30 minutes, you can minimize damage by swapping out questions or halting distribution.
Pre-Launch Checks with the Kicue Survey Tool
Feature coverage when running this checklist on Kicue:
- Preview mode: Walk through all questions on one screen. You can directly edit and save question text and options on the preview screen, so the round-trip from finding a defect to fixing it is the shortest possible (effective for Step 1 and Step 2)
- Mobile real-device testing: A dedicated mobile / PC toggle preview feature is not provided. The operation is to open the issued test URL on a real smartphone and verify the response experience, or use a browser's inspector mode (Chrome DevTools Device Mode, etc.) as a substitute (Step 3)
- Dedicated URL for pilot distribution: A test distribution of N=30–100 is possible via a URL separate from the main run (Step 4)
- Post-launch response monitoring dashboard: Real-time confirmation of completion rate and per-question drop-off (Editor's Perspective 3)
Note that Kicue itself does not have an email delivery feature, so when using reminder emails or auto-reply emails, the operation becomes distributing the URL through an external email delivery tool (Mailchimp / SendGrid / your own SMTP, etc.). For Step 5's "final pre-launch confirmation," email body and timing settings should be handled on those external tools.
Summary — Prevent 1–2 Weeks of Rework with Five Items
- Step 1 Question quality: Have someone else read it once → Question Wording Guide
- Step 2 Branching behavior: Walk every branch on a real device → Branching Logic Guide
- Step 3 Mobile real-device: Verify on one iOS and one Android device → Mobile Design Guide
- Step 4 Pilot distribution: Detect main-run risks with N=30–100 → Pilot Testing Guide
- Step 5 Final delivery settings: Intro, thank-you page, auto-reply emails → Intro and Closing Message Guide
A 30-minute investment before launch prevents 1–2 weeks of rework after main fielding. Embedding the "five-item ritual" in your team is the most direct lift to operational quality.
If you want to run the core of your pre-launch checklist in a single tool, try the free survey tool Kicue. From in-place question and option editing on the preview screen, to pilot distribution with a dedicated URL, and a real-time response monitoring dashboard — you can execute the main pre-launch checks in a single account (mobile real-device testing is handled via the issued URL on your phone, and email delivery is operated through external tools).
References (1)
- Dillman, D. A., Smyth, J. D., & Christian, L. M. (2014). Internet, Phone, Mail, and Mixed-Mode Surveys: The Tailored Design Method (4th ed.). Wiley.