Set the decision
Start with the decision: Understand how users identify and resolve duplicates.
Product and software research · Practical survey guide
Understand how users identify and resolve duplicates.
Opens product registration. Example questions are not imported automatically.
EXAMPLE INVITATION BRIEF
Understand how users identify and resolve duplicates.
Before sending, explain handling, optional participation, and contact details. This example is not sent by the preview.
From question to next step
Start with the decision: Understand how users identify and resolve duplicates.
Invite people with relevant experience. Ask after someone has encountered the situation described in “How did you decide records were duplicates?”, while they can still recall the details. For material testing, show the actual draft first; for planning, ask before the next relevant activity.
Show a field-by-field merge preview.
Read the answers carefully
Do not assume similar names mean duplicate people.
Users cannot compare conflicting values before merging. This is a synthetic example, not a customer result. Do not assume similar names mean duplicate people.
A worked interpretation example
Illustrative scenario. These are not customer results.
Users cannot compare conflicting values before merging.
Show a field-by-field merge preview.
After trying the change, repeat “How did you decide records were duplicates?” with people who experienced it. Check whether they still describe the original issue: users cannot compare conflicting values before merging. Compare explanations and sample context, rather than claiming the change caused an improvement.
A useful starting point
Understand how users identify and resolve duplicates. Use the prompts relevant to your audience and allow people to skip situations they did not encounter. Keep response handling consistent with what you explain in the invitation.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate.
The basis used to identify duplicates reveals which attributes informed the decision. Compare relevant evidence without assuming similar names establish that records describe the same entity.
Missing merge context identifies what users need to compare records and understand consequences before deciding. Explain supported information and review steps, without assuming similar labels prove duplication or that every merge is reversible.
A useful comparison identifies the fields or source context needed before resolving duplicates. Verify merge consequences and recovery limits before changing live records.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate. How did you decide records were duplicates? What information was missing before merging? What would help compare the records?
Download the questions as text ↓
Examples to adapt, rather than a validated research instrument.
Before you send it
Would you agree that everything about duplicate record handling was clear and easy?
How did you decide records were duplicates?
The first wording combines an assumed positive outcome with two different judgments. The revised prompt asks about a specific experience and permits an inconvenient or uncertain answer.
Choose the response format
| Question | Suggested format | What to preserve |
|---|---|---|
| How did you decide records were duplicates? | Optional short text | Retain the specific point or condition described; avoid replacing it with an unexplained rating. |
| What information was missing before merging? | Optional written explanation | Keep context that distinguishes different experiences. Do not assume similar names mean duplicate people. |
| What would help compare the records? | Optional improvement suggestion | Keep the suggested change separate from whether it has been tested. Show a field-by-field merge preview. |
Make questions optional where appropriate. If you add a rating scale, label its endpoints, keep one idea per question, and retain a follow-up for reasons. These examples are not a validated measurement instrument.
Before you send it
Product users who attempted the described task. Ask only about steps each person encountered; do not treat a voluntary response sample as representative.
Ask after someone has encountered the situation described in “How did you decide records were duplicates?”, while they can still recall the details. For material testing, show the actual draft first; for planning, ask before the next relevant activity.
Users cannot compare conflicting values before merging. This is an illustrative pattern to look for, not a claim about your respondents. Do not assume similar names mean duplicate people.
Show a field-by-field merge preview. After trying the change, repeat “How did you decide records were duplicates?” with people who experienced it. Check whether they still describe the original issue: users cannot compare conflicting values before merging. Compare explanations and sample context, rather than claiming the change caused an improvement.
Missing merge context identifies what users need to compare records and understand consequences before deciding. Explain supported information and review steps, without assuming similar labels prove duplication or that every merge is reversible. Use an optional written explanation when predefined choices would hide relevant context.
Copy the prompts or download TXT, CSV, JSON, or a Markdown worksheet, then adapt them in your own survey. The CTA opens registration; it does not import this example automatically. Verify available features in your account.
Build with SurveyTeams
Use these examples to draft your questionnaire. Create a survey draft, add questions, and check the respondent preview in SurveyTeams. Additional features depend on your account and plan.
Opens product registration. Example questions are not imported automatically.
Learn about the product ↗Continue exploring