Felhasználói visszajelzések értelmezése

User Research Synthesis

Turn what people said and did into evidence a decision can rest on, without inventing anything.

Before collecting

• Name the decision the research informs, the questions to answer and the assumptions to check.
• In interviews, ask about past behavior, not opinions about your idea: "Walk me through the last time you …", "What did you use?", "What was hardest?", "What have you tried?", "What does it cost you in time or money?". Never pitch; compliments and "I would use that" are noise. Ask for a concrete example whenever an answer is general.

Process each source

• Record per source: participant type and context (segment, role, experience, how often they do the task), observations, pain points, workarounds, what works, and verbatim quotes.
• Keep behavior (what they did) apart from attitude (what they say they want). Behavior is stronger evidence; record contradictions between the two.
• Workarounds and emotional language (frustration, resignation) mark real needs.

Quotes and honesty

• Quote only words that appear in the source, verbatim; never compose, polish or merge quotes. Paraphrase is labeled as paraphrase.
• Attribute quotes to a participant type ("admin, 200-person team"), never to a name or private detail.
• A quote is evidence, not a finding; the finding is your interpretation, stated as such.
• Never fill gaps with what users probably think. Missing information stays missing.

Find the themes

• Tag every observation, group the tags into themes, name each theme in one sentence, and check that each has enough evidence and that themes do not overlap. Outliers stay visible.
• Count how many participants or sources support each theme, and rate its impact. Rank by frequency and impact: frequent and severe first; rare but severe matters for a segment; frequent but minor is quality of life.
• Triangulate: the same finding from several people, methods (interviews, survey, analytics, tickets) or times is much stronger. Disagreement between sources often reveals a segment.
• One customer's request is not a market need. A feature request is a proposed solution: ask what problem lies behind it and how many others have that problem.

Surveys and tickets

• Look at distributions and segments, not only averages; a mean can hide a split. Watch response bias and small samples; a tiny change in a score is noise.
• Code open answers like interview notes and count theme frequency.

Write the synthesis

• Overview: method, number and kind of participants or sources, time frame, the questions.
• 5–8 findings, each with: one-sentence statement, evidence with source attribution, how many sources, impact, and confidence (high: several sources and methods; medium: suggestive; low: one or two sources, a hypothesis).
• Segments or personas only when the data shows behavioral clusters; describe behavior and goals, not invented demographics.
• Opportunities and recommendations, each tied to findings and concrete enough to act on ("add a progress indicator to setup", not "improve onboarding").
• Open questions and the research that would answer them.

Before you finish

• Every quote is verbatim from a source; nothing is invented.
• Findings show how many sources support them and their confidence.
• Single requests are not presented as market needs.
• Recommendations trace to findings; gaps are stated.