Introduction
To turn an existing questionnaire into a fieldable online survey, decide item by item whether to preserve or adapt it, rewrite anything built for paper or phone for the screen it’ll be read on, and write every skip, display and randomization rule down. Then define who should answer and how many, and pretest the programmed instrument with real respondents. Importing the document is the fastest step, not the finished one.
Last updated October 2026.
Why a Questionnaire Isn't a Study
A questionnaire is a list of questions. A fieldable study is that list plus a population, a mode, a routing specification, a sample plan and evidence that respondents read the questions the way the author meant them. Most inherited questionnaires arrive with only the first part, and the missing parts are where studies fail.
Three kinds of document show up on a researcher’s desk. A colleague’s Word file is the easiest, because the author is a message away. A vendor or agency instrument carries logic that lives in someone’s head. A published or validated scale carries wording you may not be free to change.
When Converting an Existing Questionnaire Makes Sense
Conversion makes sense when the questions are already right and only the container has to change. That’s a narrower condition than it sounds, and it’s worth testing against three situations before you start.
You Need Comparability With Past Data
If last year’s results sit in a report that leadership trusts, the new study has to produce numbers that line up with them. Keep the trend items word for word, keep their order and response scales, and bridge any mode change with an overlap, as covered later in this guide.
The Instrument Is Validated or Required
A validated scale earns its credibility from being administered as published. Regulatory, customer or board reporting sometimes names the exact questions. In both cases the work is faithful transfer, and your adaptation budget is close to zero.
Time Matters More Than Novelty
A team with a launch decision in two weeks gets more from a reviewed, reused instrument than from a new one written under pressure. The Census Bureau’s Statistical Quality Standard A2 exempts questions with a track record, though not deadlines: "Pretesting is not required for questions that performed adequately in another survey."
When Not to Convert One
A converted questionnaire inherits its author’s objective, and no amount of programming fixes a wrong objective. Four situations call for a different instrument, and each names its better alternative.
The Questions Answer a Different Question Than the One You Have
If the questionnaire was written to measure satisfaction and your decision is about prioritization, converting it gives you a well-programmed answer to the wrong question. For "which of these matters most," use MaxDiff rather than an importance grid. For "why did this happen," use interviews, either moderated or AI-moderated, and treat the survey as a follow-on.
Stated Intent Can't Replace Pricing Research
A questionnaire that asks "would you buy this at that price" can’t tell you what people will pay. Use Van Westendorp or Gabor-Granger, both built to estimate price sensitivity from structured items.
You Can't Tell Whether Respondents Still Read the Questions the Way the Author Did
Wording ages. A product name changes, a competitor disappears, and a phrase like "online banking" means something different to a respondent now than it did when the instrument was written. When that’s possible, run cognitive interviews before you program anything. A converted instrument that hasn’t been tested with people is unvalidated.
The Old Numbers Will Be Compared With the New Ones, and the Mode Has Changed
A phone or paper questionnaire moved to a web survey is a different measurement, even with identical wording.
Dillman and Smyth (2007, American Journal of Preventive Medicine 32(5), S90 to S96) report that question formats used in other modes perform differently on the web. If a trend line matters, run a bridge study, a parallel field period on both modes. Our Qualtrics migration guide covers bridge design in full.
Reviewing the Original Before You Convert
Read the questionnaire as a respondent would before you convert anything. Conversion is the cheapest moment to catch problems, because you’re already touching every item. The list below covers the faults that most often survive years of reuse.
Common Faults in Inherited Questionnaires
- Double-barreled items. "How satisfied are you with the speed and accuracy of support?" asks two things at once. Split it, or decide which one you need.
- Leading wording. An item that signals the expected answer, such as "How much did you enjoy...", produces agreement. Neutralize it, and log the change.
- Missing options. A closed list with no "Other" or "None of these" forces a wrong answer from respondents who don’t fit.
- Undefined time frames. "Recently" means a week to one respondent and a year to another. Name the window.
- Dated or internal terms. A product that was renamed, a competitor that no longer exists or a team’s jargon can make an item unanswerable.
- Overlapping ranges. Age or income bands that share an endpoint put some respondents in two categories.
Fix Only What You Can Defend
Every fix to an item that feeds a comparison is a break with the past. Fix a fault when its cost to the new study exceeds the cost of the break, and write both down. If you leave a known fault in a trend item, say so in the change log so a later analyst understands why.
The Fork: Preserve or Adapt Each Item
Decide per item, never per questionnaire. A preserve-everything policy ports paper-era formats onto phone screens, and an adapt-everything policy breaks trend lines and validated scales.
The Decision Tree
- Is the item part of a validated scale or a required report? Preserve the wording, order and scale. Check the license before you reproduce it.
- Does the item feed a trend line you’ll compare with past results? Preserve it and plan a bridge if the mode is changing.
- Does the item rely on something the new mode can’t deliver, such as a show card, an interviewer probe or a page reference? Adapt it, and log what changed.
- Does the item have a known problem, such as double-barreled wording, a missing option or a dated term? Adapt it, and pretest the new version.
- Is the item new to your team and untested anywhere? Keep it as written and let the pretest decide.
What "Preserve" Does and Doesn't Cover
Preserving an item covers its wording, its response options, their order and their labels. It doesn’t cover the visual layout. A seven-column grid can keep its seven scale points and its labels while changing from a grid to a stacked layout on small screens, though a layout change is still a change to log.
Sprig note. Sprig documents randomization at the survey level, within a block, over a random subset of a block, and across response options, but it documents no way to assign each respondent to one of several survey versions. If your source questionnaire runs a monadic split, where every respondent sees exactly one of several concepts, that design needs a different setup. Check this before you commit to the platform.
Log Every Change
Keep a change log with three columns: the original item, the converted item and the reason. It’s the only record that lets a later analyst decide whether a difference in results could come from wording. Without it, you can’t separate a real shift from an edit.
Adapting Items to the Screen
The constructs below cause most mode problems. The table maps each to a screen equivalent, the risk the change carries and the action to take. Use it as a lift-ready audit sheet.
| Source Construct | Screen Equivalent | Risk | Action |
|---|
| Show card read aloud | List displayed with the question | Order effects, since respondents now see every option at once | Randomize options unless order is meaningful |
| Interviewer-volunteered "don't know" | Visible "Don't know" option or none | A visible option raises "don't know" rates | Decide deliberately and log it |
| Wide grid of statements | Stacked, one item per screen section | Longer scroll, more screens | Stack on small screens, test completion time |
| "If yes, skip to Q12" printed instruction | Programmed skip or display rule | Respondents never see the instruction, so errors become routing errors | Write the rule in the spec |
| Open numeric field for age or count | Validated numeric entry | Free entry invites typos and nonsense | Add range validation and test it |
| Interviewer probe: "Anything else?" | Follow-up open-text question | Self-completed probes get shorter answers | Keep the probe, accept shorter text |
| Page header with a long preamble | Short intro screen | Long intros raise abandonment | Cut to what respondents need to consent and start |
Read down the table and the pattern is the same: on a screen, show-card options need randomizing unless their order matters, a visible "Don’t know" raises "don’t know" rates, wide grids stack on small screens, printed skip instructions become programmed rules, numeric entries need range checks, self-completed probes get shorter answers and long preambles raise abandonment.
Grids Deserve Their Own Warning
To adapt a grid question for mobile, stack the statements one above another on small screens, keep the same statements, scale points and labels, then test completion time and straightlining before launch and log the layout change. The evidence below explains why.
Grids are a construct that often gets carried over unchanged. Richards, Powell, Murphy, Nguyen and Yu (2016, Survey Practice 9(3)) compared traditional grids on large screens with stacked layouts on small screens in a web survey of 14,613 registry respondents. Straightlining was significantly higher in the traditional grid for all five grids tested.
The comparison was observational, so device and respondent type are confounded with layout. It’s a reason to test a stacked layout, not proof that stacking fixes straightlining.
Interviewer-Administered Instruments Change Most
A questionnaire written for a phone interviewer assumes someone clarifies, paces and probes. A self-completed web survey has none of that. Read the instrument as a respondent with no help, and flag every instruction that was addressed to the interviewer. Those instructions either become programmed logic or disappear.
A Worked Example: Converting a Phone Questionnaire
The example below is illustrative and uses invented items. A regional services company has a 24-item customer satisfaction questionnaire that interviewers have read aloud by phone for years. The team wants to field it as a link survey sent by email. Walking six items through the fork shows how the decisions come out.
Item by Item
| Item | Source Wording | Decision | Change Made |
|---|
| Q1 | Overall satisfaction, 1 to 5 with read-out anchors | Preserve | None. It feeds the trend line, so wording, points and anchors stay |
| Q4 | "Interviewer: show card A" | Adapt | Show card options appear under the question, randomization off because the order is meaningful |
| Q7 | "If no to Q6, skip to Q10" | Adapt | Programmed as a skip rule, written in the spec as a condition |
| Q9 | Grid of eight service statements | Adapt | Stacked layout on small screens, same statements and scale |
| Q12 | "Interviewer: probe for specifics" | Adapt | Follow-up open-text question, shorter answers expected |
| Q18 | Respondent age as an open number | Adapt | Numeric entry with a range check |
What the Example Shows
Q1 keeps its wording, points and anchors. Q4 shows the card’s options under the question with randomization off, because the printed order is meaningful. Q7 becomes a programmed skip rule, Q9 a stacked grid, Q12 a follow-up open-text question and Q18 a numeric entry with a range check.
Only one of the six items stays untouched, and it’s the one that carries the trend. Every other change is forced by the mode, not by taste. The change log for this questionnaire would hold five entries, each with the original item, the converted item and the reason.
What the Team Still Has to Decide
The conversion doesn’t settle whether the trend item will read the same on the web. That needs a bridge, covered below. It also doesn’t settle whether respondents understand the stacked grid statements the way phone respondents understood the spoken ones. That’s a question for cognitive interviews, and the spec is only ready for them once the change log exists.
Preserving Versus Changing Scales
A scale is a measurement, so changing its length, labels or direction changes what the numbers mean. The default is to hold the scale for any item that feeds a comparison.
Hold Constant What Feeds a Comparison
Keep the number of points, the verbal anchors, the direction and whether a midpoint exists. Reversing a scale direction is the quietest change a converter can make, and it’s one respondents react to even when the labels are clear.
Change Only With a Reason and a Bridge
If a scale has to change, say because the old one was an 11-point grid that doesn’t fit a phone, field both versions to comparable respondents for a period and compare. A scale conversion applied to the old data afterward is an assumption, not a measurement.
Label Decisions to Make Before Programming
Decide whether every point carries a label or only the endpoints, whether "Not applicable" is a separate option and whether a "Don’t know" sits inside or outside the scale. Write each decision in the spec so the person programming doesn’t make it by default.
Writing the Programming Spec
A programming spec is the document a person or a tool builds the survey from. A spec with every rule written down can be built by anyone and checked by someone else, and one without it gets rebuilt from memory. Write it before you import anything, because the import step reads the document and the spec is what the import should reproduce.
The Spec Template
Use one block per question, in survey order. Lift the format below as written.
- Header: study title, goals and objectives, channel, estimated length
- Question number and text: numbered, ending in a question mark
- Type in brackets: for example [Multiple Choice], [Rating Scale], [Open Text], [Rank Order]
- Response options: in display order, with the label for each scale point
- Required status: required or optional
- Routing: the skip or display rule, written as a condition and an action
- Randomization: which options, questions or pages, and which items stay pinned
- Piping: which earlier answer or attribute appears in the text
- Validation: type, range or length limits for open entries
Write Routing as Conditions
In a survey programming spec, write each skip rule as a condition and an action, such as "if Q4 equals 'No', skip to Q9," never as a flowchart arrow, and note which page each question sits on.
A skip rule between two questions on one page needs a page break first. A condition can be checked against the programmed survey line by line. An arrow depends on whoever drew it.
Group Questions Into Pages Deliberately
Decide which questions share a screen. Page breaks control how much a respondent sees at once, and they change how skip rules behave, so settle the page structure before you write the rules.
Why the Spec Doubles as an Import File
Several tools read a structured document and build a draft. The more your spec follows a documented convention, the more of the survey arrives correct. The next section compares those conventions.
Sprig note. Sprig’s AI File Upload Builder reads a document with a header holding the title and goals, numbered questions ending in question marks, the type in brackets, and the prefixes REQUIRED:, SKIP LOGIC:, DISPLAY LOGIC: and RANDOMIZE:. It also reads page start and end markers, and without them each question gets its own page.
The limit: it depends on the document following those rules, so an unformatted Word file produces a weaker draft. Skip logic can’t redirect a respondent between two questions on the same page, so a skip rule between neighbors needs a page break first. Display Logic is documented as available only on Enterprise plans.
Importing the Document: What Each Tool Does With It
Four widely used tools take an existing questionnaire as input, and they differ most in what they leave out. None of them carries logic across reliably, so treat any import as a draft of the questions, not of the study.
Qualtrics
Qualtrics documents import from QSF files, from TXT in a simple or advanced format, and from DOCX files that follow the TXT format. The simple format suits multiple choice and matrix questions only. The advanced format adds codes for text entry, constant sum, rank order and text or graphic blocks.
Files must be tab-delimited TXT, and a file saved as UTF-16 won’t upload. A DOCX import always creates a new survey.
A fixed format makes the result predictable, which is where Qualtrics wins on this task.
SurveyMonkey
SurveyMonkey offers a "Paste your content" option, with a manual mode for multiple choice and single textbox questions and an AI-powered mode that sends pasted text to OpenAI or Azure OpenAI.
Its documentation states that "page breaks, logic, and unsupported question types won’t be captured," and that "the import may result in inaccuracies."
It lists a cap of 50 pastes per month and advises against pasting sensitive information such as names.
Typeform
Typeform’s importer takes pasted text, with a documented limit of 6,000 characters in the text box, and recommends Typeform AI as the preferred route. Question types are assigned automatically from content and can be changed afterward. Typeform’s article doesn’t say which plans include the feature, and it treats logic as something you add after importing, so expect to build it by hand.
Sprig
The Design Agent includes the AI File Upload Builder, which accepts a .pdf or .docx file up to 25 MB on Enterprise plans. The builder processes the file, chooses a study type, generates questions and options, sets required status, randomization, skip logic and display logic, validates the survey and presents an audit log.
Sprig’s documentation says you can get a complete survey from a document in under 2 minutes, a claim we haven’t timed independently.
Its documented gaps are MaxDiff questions and prototype links, which have to be added by hand, and the documentation lists only .pdf and .docx, so CSV, TXT and QSF aren’t listed.
Choosing Among Them
SurveyMonkey’s and Typeform’s import pages document no plan gating, while the builder is documented as Enterprise-only, so a team on a lower tier should weigh that first.
| Tool | Accepted Input | Logic Handling | Documented Gaps |
|---|
| Qualtrics | QSF, TXT, DOCX in TXT format | Not stated on the import page | Simple TXT limited to multiple choice and matrix |
| SurveyMonkey | Pasted text, manual or AI mode | Not captured | Page breaks, logic, unsupported types, 50 pastes per month |
| Typeform | Pasted text, up to 6,000 characters | Added after import | Plan gating not documented |
| Sprig | PDF or DOCX, up to 25 MB | Reads skip, display and randomize directives | MaxDiff, prototype links, Enterprise only |
Choosing Distribution and Channel
The same questions read differently in an email, on a phone in a hallway and inside a product, so a channel change is a mode change and triggers the preserve-or-adapt fork again.
Match the Channel to Who You Can Reach
Email and link surveys suit a known customer list. A research panel reaches people outside it. In-product delivery reaches people mid-task, which shapes both who answers and how carefully.
Sprig note. Sprig documents delivery by email, shareable links (including by SMS), embeds and QR codes, panels, and in-product surveys on web and mobile. The limit: it documents no native telephone interviewing, in-person interviewing or offline fieldwork.
Interviewer Modes Don't Move Over Intact
If you need to keep telephone, in-person or offline fieldwork, use a platform built for interviewers, since the note above documents none of those modes. Otherwise the questionnaire gets converted to self-completion, with all the adaptation that implies.
Mind the Length You're Importing
A paper questionnaire can run to 20 pages without feeling long. The same items on a screen feel longer. Estimate completion time on the programmed survey, not the document, and trim before launch rather than after the first abandonment report.
Sample and Quota Frame
A converted questionnaire still needs a defined population, and the original sample rarely transfers. Write down who the instrument should reach, how you’ll reach them and what precision the decision needs before you set a launch date.
Define the Population in One Sentence
Name the people, the time window and the behavior or relationship that qualifies them. "Customers who completed onboarding in the last 90 days" is a population. "Our users" isn’t.
Size the Study From Precision, Not Habit
Decide the margin of error you can live with for the segments that matter, then derive the sample from it. A subgroup you plan to report separately needs its own sample. A total of several hundred responses can still leave a segment of 30, and at 30 responses the margin of error is about ±18 points, from the formula below.
A Derived Sample-Size Table
The table below is derived, not sourced from a methodology reference. It uses the standard formula for a proportion, n = z² × p × (1 − p) ÷ e², with z = 1.96 for 95 percent confidence and p = 0.5, the most conservative case. It assumes a simple random sample and a large population, and it ignores nonresponse and design effects, so treat the result as a floor for each reported group.
| Margin of Error | Arithmetic | Completed Responses |
|---|
| ±10 points | 0.9604 ÷ 0.0100 = 96.04 | 97 |
| ±5 points | 0.9604 ÷ 0.0025 = 384.16 | 385 |
| ±3 points | 0.9604 ÷ 0.0009 = 1,067.11 | 1,068 |
A ±10 point margin needs 97 completed responses, a ±5 point margin needs 385 and a ±3 point margin needs 1,068. Apply the table to each group you plan to report separately. If you want a ±5 point margin for each of three customer segments, you need about 385 completed responses in each, not 385 in total.
Quotas and Screeners
A quota keeps a convenient sample from drifting toward whoever answers first. It works by ending respondents whose answers fall in a group that has already reached its target, so the screener has to come first.
Sprig note. Sprig documents quotas on Enterprise plans, driven by answers to single select, rating scale or NPS screener questions.
The limit: attribute-based quotas aren’t documented, and quotas can’t be deleted from an active survey.
The questions, response values and operators in a quota can’t change after launch, though targets can be raised or lowered. Decide the quota design before launch, and test it in the soft launch.
Don't Reuse the Old Sample Frame by Default
The respondents who answered the original study may not be the people you need now. If the frame changed, a comparison with past results is a comparison between samples as much as between time periods.
Screening and Eligibility
A screener decides who gets to answer, and an inherited questionnaire usually has an opening that assumed the interviewer already knew. A phone interviewer called a number from a list and confirmed a few facts. A link survey can be forwarded, opened by the wrong person or answered twice.
Write the Eligibility Rule as a Condition
State the rule the same way you state routing: "continue if Q1 equals 'Yes' and Q2 is in the last 90 days." Put it at the start, keep it short and end ineligible respondents politely on a screen that thanks them.
Don't Let the Screener Reveal the Answer
If a screener asks "Do you use product X?" and the survey is about product X, respondents learn what a qualifying answer is. Mix the target behavior into a list of several and decide qualification from the pattern of answers.
Plan for Duplicates and Forwarding
A personalized link tied to a known contact is harder to forward than an open link. If you use an open link, add a check question that eligible respondents can answer and others can’t, and decide in advance how you’ll handle duplicate submissions.
Timing and Cadence
Conversion changes timing in two ways. The field period has to account for the pretest and the soft launch before the main launch, and the send time affects who responds.
Build the Schedule Backward
Start from the date you need results and work back through the soft launch, the pilot, cognitive interviews, programming and spec writing. Teams that start from the launch date and skip the middle steps tend to rediscover them as incidents.
Log Send Time as a Variable
Phone fieldwork controlled when people were called. A link survey hands that control to the respondent, so record the send time and the response time. If the original study had a fixed calling window, note that the new study doesn’t.
Repeat Studies Need a Frozen Instrument
If the survey will run again, freeze the converted version and record the date. Edits between waves are changes to the instrument, and without a record they look like changes in the population.
Pretesting Before You Launch
The Census Bureau’s Statistical Quality Standard A2 lists cognitive interviews, behavior coding, respondent debriefings, split panel tests and certain focus group and usability techniques as acceptable methods. It also says methodological expert reviews generally don’t satisfy the requirement.
Cognitive Interviews Test Meaning
A cognitive interview asks a respondent to answer and then explain what they thought the question meant. Use open probes. Willis (2018, American Association for Public Opinion Research webinar), citing Fred Conrad, reports that asking about specific problems leads respondents to affirm problems that may not exist.
A Pilot Tests the Mechanics
A pilot field period with real respondents tests routing, timing and technical behavior. It doesn’t tell you what a question meant to anyone, so it doesn’t replace cognitive interviews. Run cognitive interviews first, fix the wording, then pilot the programmed version.
Speed and Coverage Trade Off
Willis distinguishes reparative testing, which fixes broken items quickly with small samples, from descriptive testing, which maps the full range of interpretations with larger ones. He cites Blair and Conrad as needing 50 or more interviews to find all problems in the reparative setting. Treat that as a reason to prioritize which items to test, not as a floor you must meet.
Plan the Interview Round
Choose the items to test before you recruit. Prioritize items you changed, items that carry the decision and items that touch sensitive or unfamiliar topics. Recruit people who resemble the target population, since a colleague who knows the product will read an item differently than a customer who doesn’t. Write the probes in advance, and keep them open.
Read the Results Item by Item
Sort what you hear into three groups: items respondents understood as intended, items they understood differently and items they couldn’t answer. Fix the second and third groups, then test the revised wording on new respondents. Record the finding for each item, because Willis notes that reporting often has gaps and findings get lost.
Test the Logic Yourself
Walk every path through the programmed survey. For each skip and display rule in the spec, answer to trigger it and answer to avoid it. A rule that has never fired in testing is a rule that might not fire in the field.
Sprig note. The Design Agent page describes detecting broken or conflicting logic, flagging unclear or inconsistent questions, estimating time to complete and showing how responses vary across key customer archetypes. Use these as a first screen. The limit is that a simulation isn’t a pretest: no person has read the questions, so none of it replaces cognitive interviews.
Soft Launch and the First Responses
A soft launch sends the survey to a small slice of the sample, then stops to read what came back. Its job is to catch breakage, not to produce results. Set a stop rule before you start, such as pausing if a screener ends nearly everyone or if completion time lands far from your estimate.
What to Read in the First Responses
Look at where respondents leave, how long completion takes, which questions have unusual blank rates, whether open-text answers are on topic, and whether the routing sent people where you expected. Check the screener and quota counts against what you planned.
What Not to Read
Don’t read results. Early responses come from whoever answers first, who aren’t a random slice, and acting on them invites a decision based on a skewed handful.
The Benchmark Question
No published benchmark says how long a questionnaire conversion should take or how many errors an AI importer introduces, so the only defensible measure is a diff of your programmed study against the source, item by item.
Quality Control and Data Hygiene
A converted survey needs quality checks that the original may have gotten for free from an interviewer. A person on the phone noticed a respondent who was clearly not paying attention. A screen doesn’t.
Decide Your Quality Rules Before Fielding
Write down what counts as a poor-quality response before the data comes in: straightlining across a grid, implausibly fast completion, nonsense open-text answers and duplicate entries. Deciding afterward invites choosing the rules that favor the result you wanted.
Replace What the Interviewer Used to Catch
An interviewer noticed distraction, confusion and implausible answers. A screen doesn’t, so decide which of those you’ll detect by rule, such as completion time and identical answers across a grid, and which you’ll accept.
Keep the Raw File
Store the untouched export before any cleaning. Cleaning rules change, and you’ll want to rerun them. Record each removal with its reason, so the final sample can be reconstructed from the raw one.
Protect Respondent Identity
A converted survey often carries contact attributes that the original didn’t, such as an email address or a customer ID passed in the link. Decide which attributes you need for analysis, and drop the rest before the data moves anywhere else.
Keeping Old and New Results Comparable
If the study repeats an earlier one, the conversion creates a comparison problem that no amount of careful programming removes. A change in platform, mode or layout can move a number even when respondents haven’t changed.
The Two Ways a Number Moves
A difference between old and new results can come from the respondents or from the measurement. Dillman and Smyth (2007) describe how formats perform differently across modes, which is a measurement effect. A change in who answers is a sample effect. A single comparison can’t separate them, which is why a bridge study is needed.
Designing a Bridge
A bridge study fields the old and new versions to comparable respondents in the same period. Hold constant the population, the field dates and the wording of the items you want to compare. Vary only the version. Then compare the trend items across versions before you compare either with history.
Deciding What the Bridge Says
Set the decision rule before you look. If the versions agree within the precision your sample supports, treat the series as continuous and note the conversion in the report. If they don’t, report the break, don’t smooth it, and say which version future waves will use.
When You Can't Run a Bridge
Sometimes budget or time rules it out. In that case, label the first converted wave as a new baseline, don’t chart it as a continuation of the old series without a visible break, and avoid reporting small changes as findings.
Documenting the Conversion
The people who read your results later, including you in a year, will want to know what the instrument was, what changed and why. Five documents cover it, and each takes minutes to keep current if you write it as you go.
The Five Records
- The source. Keep the original questionnaire exactly as received, with its date and where it came from.
- The change log. List every adapted item with its original, its converted form and the reason.
- The spec. Store the final version, including every routing, randomization and validation rule.
- The pretest notes. Record what respondents understood, what they didn’t and what you changed in response.
- The soft-launch audit. Keep the table from the first responses and the decision you made after reading it.
Who Reads Them
An analyst reads the change log to decide whether a difference could come from wording. A successor reads the spec to rebuild the survey. A reviewer reads the pretest notes to judge how far to trust an item. None of them should have to ask you.
Version the Instrument
Give each frozen version a name and a date, and put the version in the data file. When a later wave edits an item, the version label is the only reliable way to tell which respondents saw which wording.
Pre-Launch Checklist
Run this list in order before the main launch. Each line is a check someone can mark done or not done.
- Record the objective and the population in one sentence each.
- Complete the change log, with every adapted item listed beside its original.
- Write the spec, with every routing rule stated as a condition.
- Build the survey from the spec, by import or by hand.
- Diff the programmed survey against the source, item by item, including response options and their order.
- Walk every routing path, answering to trigger and to avoid each rule.
- Check each scale for direction, point count and labels against the spec.
- Confirm required and optional status on every question.
- Test the survey on a phone and on a desktop, in more than one browser.
- Run cognitive interviews on every changed item, with open probes.
- Fix the wording, rebuild the affected items and retest the routing around them.
- Estimate completion time on the programmed survey and trim if it’s longer than planned.
- Set quotas and screeners, and confirm which settings lock once the survey is live.
- Write the quality rules for straightlining, speed and duplicates.
- Set the stop rule for the soft launch.
- Send the soft launch to a small slice and read for breakage only.
- Read the respondent-facing text aloud, including the intro, the thank-you and the ineligible screen.
- Test the email or link that respondents will actually receive, including sender name and subject line.
- Confirm what personal data the survey collects and where it goes.
- Freeze the instrument and record the date.
Converting and Auditing the Questionnaire With Claude or ChatGPT
Claude and ChatGPT are good at the clerical half of conversion: turning an unstructured document into a numbered spec, and counting what’s in it. They’re unreliable at the judgment half, which is deciding what the questions mean. Use the two prompts below for the first and keep a person on the second.
What the Analysis Produces
Prompt one returns a programming spec and a fidelity report that compares the source with the spec. Prompt two reads a soft-launch export and returns item-level blank rates, straightlining flags and routing breaks. Neither one interprets what respondents said, and neither should.
Prompt One: Questionnaire to Spec
What this prompt does: Converts the questionnaire below into a numbered programming spec and checks that nothing was lost or changed.
What it returns: A spec table, a fidelity report, and a file named [OUTPUT FILE NAME, default: questionnaire_spec.csv].
Use code to calculate this, not estimation.
Source mode: [SOURCE MODE, default: phone]
Target channel: [TARGET CHANNEL, default: link survey]
Questionnaire:
[PASTE QUESTIONNAIRE TEXT]
Steps:
1. Copy every question and response option exactly as written. Don’t reword, fix or improve anything. Put problems in a separate Flag column.
2. For each question, record its number, text, type, response options in order, required status, routing rule, randomization and validation.
3. Ignore blank lines, headers, footers and page numbers when counting. List every interviewer-only instruction in a separate table instead of dropping it. Count "Don’t know" or "Refused" as options only if they’re printed in the source.
4. If the source contains fewer than [MIN QUESTIONS, default 5] numbered questions, including zero, stop and report that the file may not have been read correctly.
5. Count the questions twice by two different methods. First count numbered items with a pattern match. Then count separately the lines ending in a question mark. Count response options twice the same way, by line prefix and by marker.
6. If any two counts disagree, report both and don’t correct either.
7. Save the spec as [OUTPUT FILE NAME].
Prompt Two: Soft-Launch Export Audit
What this prompt does: Audits the first responses to a survey for breakage, without interpreting any answers.
What it returns: An item-level table and a file named [OUTPUT FILE NAME, default: soft_launch_audit.csv].
Use code to calculate this, not estimation.
Data: the attached CSV, one row per respondent.
Routing rules: [PASTE ROUTING RULES]
Grid questions: [GRID COLUMNS, default: none]
Duration column: [DURATION COLUMN, default: none]
Steps:
1. For each question, count respondents who should have seen it under the routing rules, then count blanks among them. A blank on a question that should have been shown is a nonresponse. A blank on a question that should have been skipped isn’t applicable and is excluded.
2. Report nonresponse as a share only for questions with at least [MIN ANSWERS, default 20] eligible respondents. A question with fewer, including zero, is reported as under threshold with its count, not as a rate.
3. For each grid, flag respondents who gave the same answer to every row, and report the share of eligible respondents flagged.
4. If a duration column is given, report the median, the minimum and the maximum.
5. List any answer that appears on a path the routing rules say it shouldn’t.
6. Recompute every nonresponse count by a different method: first with a dataframe, then with a plain loop over the raw CSV rows. Report both.
7. If the counts disagree, report both and don’t correct either.
8. Don’t report any answer distribution or interpret any open text. Save the table as [OUTPUT FILE NAME].
Preparing Your Input
Paste the questionnaire text above the instruction, not below it. Liu and colleagues (2024, Transactions of the Association for Computational Linguistics) found models use information at the start and end of a long input better than the middle. For a long instrument, run it in sections and merge the specs yourself.
Reading the Output
These prompts haven’t been benchmarked across models, and two matching counts can both be wrong if the model misread the file, so the spot-check against the source is required.
Read the fidelity report before you read the spec. If the two question counts agree and the option counts agree, spot-check 10 items against the source. If they disagree, the disagreement is the finding. Open the source and find the item.
What to Verify Before You Rely on It
Check three things by hand. Compare every routing rule against the source’s printed instruction. Read each item the model flagged and decide whether you agree. And compare the wording of any item the model touched, since a model asked to copy exactly will still occasionally smooth a sentence.
Pitfalls
- Silent edits. A model improves wording unless told not to, and it won’t always report that it did. The fidelity counts catch dropped items but not reworded ones, so diff the wording.
- Non-determinism. Thinking Machines Lab (2025) reported 80 unique outputs from 1,000 completions at temperature zero on an open model, so identical prompts don’t guarantee identical output. Neither chat client exposes a seed, so run anything you plan to rely on twice.
- Agreeableness. Sharma and colleagues (2024, ICLR) document sycophancy in assistants. Never ask a model to confirm that your questionnaire is fine. Ask it to find problems.
- Confidential content. A questionnaire can carry unreleased product names, and a soft-launch export carries respondent data. Check which plan and data controls apply before pasting either, and remove identifiers from the export first.
Sprig note. Sprig’s MCP connector lets a supported AI client draft a study from a plain-language description and create it as a draft in Sprig, which suits rebuilding the question list.
The documentation describes one study created at a time with no templates, and it documents no file input or logic setup. The client can’t launch the study. Creating one requires an Editor or Admin role. A person reviews and launches it in the Sprig editor.
The Critique You Should Know
The standard advice, "reuse the questionnaire that already worked," rests on an assumption that proof travels. The research says it travels less well than people assume, and three findings shape how much faith to place in it.
The Critique: Wording Doesn't Carry Its Performance Across Modes
Dillman and Smyth (2007) argue that question formats from paper and telephone perform differently on the web and that visual design can shift answers in ways designers don’t anticipate. A questionnaire that worked on the phone has proved only that it worked on the phone. Their paper also notes that systematic research is still lacking on many web design choices, which means a documented answer often doesn’t exist.
The Critique Applied to Grids
Richards and colleagues (2016) found more straightlining in traditional grids than in stacked layouts across all five grids they examined. Their own caveat limits the claim. Respondents weren’t randomly assigned, and smartphone users were younger and less educated, so part of the difference may reflect who uses each device, though the authors controlled for age, education and gender.
The Counter-Critique: Re-Pretesting Everything Is Waste
Census Standard A2 says "pretesting is not required for questions that performed adequately in another survey." A team that sends every reused item through cognitive interviews spends weeks re-verifying questions that have years of clean results behind them. The standard still requires pretesting when a new instrument is developed or an existing one has substantive modifications, so the exception covers unchanged items, not a converted instrument as a whole.
The Counter-Critique: Pretesting Has Its Own Failure Modes
Willis (2018) reports that asking respondents about specific problems prompts them to affirm problems that may not exist, that think-aloud is hard for respondents with limited survey experience, and that web probing allows only a few scripted probes with no follow-up. A pretest is evidence, not proof, and the quality of the method sets the quality of the evidence.
A Peer-Reviewed Note on Pretest Evidence
Presser and colleagues (2004, Public Opinion Quarterly 68(1)) reviewed methods for testing and evaluating survey questions and called for more research on how well those methods find real problems. That cuts both ways. It argues against treating any one pretest as definitive, and it argues against skipping testing because the evidence for a particular method is thin.
What to Take From Both Sides
Preserve and bridge the items that feed comparisons. Test the items you changed. Skip re-testing the items you left alone and that have a clean record in the same mode.
Common Mistakes
Most conversion failures come from treating the import as the finish line. These are the ones that recur, with what to do instead.
- Trusting the import. Every tool’s own documentation says some elements don’t carry over. Diff the programmed survey against the source, item by item, before anything else.
- Losing the routing. Every import page reviewed here either drops logic or needs special syntax for it. Write rules as conditions in the spec and walk every path.
- Keeping interviewer instructions. "Probe if unclear" printed on a respondent’s screen is noise. Convert each instruction to logic or remove it, and log which.
- Porting grids unchanged. Test a stacked layout on small screens and compare completion time and straightlining.
- Changing a scale without a bridge. A reversed or shortened scale breaks the trend line, and you can’t repair it afterward.
- Skipping the pretest because the instrument is old. An item that worked years ago hasn’t been tested on today’s respondents or today’s screens.
- Setting quotas after launch. Some tools lock a quota’s questions and values once the survey is live, so check what can still change before launch.
- Reading results from the soft launch. The first respondents aren’t a random slice. Read for breakage and stop there.
Alternatives and Adjacent Methods
The right alternative depends on what’s wrong with the questionnaire you have.
Rewrite From the Objective
When the questionnaire answers a different question than the one you have, start from your objective and write new items. Keep what’s useful from the old instrument, and treat the rest as reference. This costs more time and gives you an instrument that fits.
Use a Validated Instrument Instead
If a published scale measures the construct you need, administer it as published. Check the license, keep the items and order intact and cite the source. This is faster than writing your own and gives you a record other researchers can interpret.
Choose a Different Method Entirely
Some objectives are poorly served by any survey. Use MaxDiff for ranking priorities, conjoint for trade-offs between attributes, Van Westendorp or Gabor-Granger for price sensitivity, and interviews for questions about why. The conversion work above applies to a survey, so confirm a survey is the right instrument before you spend the time.
Frequently Asked Questions
How Do I Turn an Existing Questionnaire Into an Online Survey?
Convert a questionnaire by deciding, for each item, whether to preserve or adapt it. Then rewrite paper, phone and interviewer-only elements for the screen, write routing rules as conditions in a spec, import or program the survey from that spec, and pretest it with real respondents. An import produces a draft of the questions, so you still diff the result against the source.
Can I Import a Word Document Into a Survey Tool?
You can import a Word document into some survey tools. Qualtrics imports a DOCX that follows its TXT format. SurveyMonkey and Typeform take pasted text rather than a file. The Design Agent’s AI File Upload Builder reads a .pdf or .docx up to 25 MB on Enterprise plans. In each case you review the result, because every tool documents elements that don’t carry over.
Does Importing a Questionnaire Carry Over Skip Logic?
Usually not reliably. SurveyMonkey states that logic isn’t captured, Typeform’s article treats logic as a step after import, and Qualtrics’ import page doesn’t say. The Design Agent’s builder reads skip and display directives, but only when the document uses its documented prefixes. Treat logic as something you rebuild and test, not something you import.
Do I Need to Pretest a Questionnaire That's Already Been Used?
A reused questionnaire needs pretesting only for what changed. Census Standard A2 doesn’t require pretesting for questions that performed adequately in another survey, and it does require it for a new instrument or an existing one with substantive modifications. Changing the mode, the wording or the scale counts as modification, so pretest the changed items.
Should I Change the Wording When I Move a Survey Online?
Change the wording only where the old wording depends on something the screen can’t deliver, such as a show card or an interviewer probe. Keep trend and validated items word for word. If a mode change is unavoidable, run a bridge study so you can tell a wording or mode effect from a real change.
How Long Does a Conversion Take?
No published benchmark exists for it, so the honest answer is that it depends on length, logic and how much needs pretesting. The import takes minutes. The spec, the pretest and the soft launch are where the time goes. Plan the schedule from those steps rather than from the import.
How Many People Should I Pretest With?
No single number applies. Willis (2018) distinguishes quick fixes with small samples from descriptive testing with larger ones, and cites Blair and Conrad as needing 50 or more interviews to find all problems in the first setting. Prioritize the items you changed and the ones that carry the decision, and test those first.
Can Claude or ChatGPT Convert a Questionnaire?
They can draft a spec and count items, and they can’t be trusted to leave wording alone. Ask for an exact copy, require counts by two different methods and diff the wording yourself. Run it twice, since the same prompt can return different outputs.
What's the Difference Between a Pilot and a Soft Launch?
A pilot tests the programmed survey with a small group, often recruited for the purpose, before the real field period. A soft launch sends the live survey to a small slice of the actual sample and then pauses. Both read for breakage. A pilot can be run on recruited respondents, and a soft launch uses the real invitation and the real channel.
Can I Use AI-Simulated Respondents Instead of Pretesting?
No. A simulation can screen for broken logic, unclear wording and likely drop-off, but no person has read the questions. It can shorten the list of items you take to cognitive interviews, and it doesn’t replace the interviews.
Can I Reuse a Published Scale Without Asking?
Check the owner’s terms first. Many published scales carry copyright or licensing conditions, and some restrict commercial use. Administer a validated scale exactly as published, cite it, and have counsel review any scale you plan to reproduce in a commercial study.
Which Channel Should I Use for a Converted Survey?
Match the channel to who you can reach. Email and link surveys suit a known list, a research panel reaches people outside it, and in-product delivery reaches people mid-task. Each is a different mode, so revisit the preserve-or-adapt decision for any item that depends on how it’s presented.
