Thematic Analysis for Community Feedback: A Practical Guide

community engagementanalysisthematic analysis+1 more
Engagement staff grouping sticky notes into themes
Thematic analysis for engagement practitioners: the six phases, coding and themes, a worked example, and keeping every theme traceable.

Related guide: Community engagement delivery and analysis: a practice guide

Thematic analysis is a method for finding, organizing and reporting patterns of meaning across qualitative data such as survey comments, submissions and workshop notes. You label what each comment says (coding), group those labels into themes that describe what people are telling you, and check every theme against the original words. For community engagement, the test of a good analysis is simple: anyone can follow a theme back to the comments behind it.

Most guides to thematic analysis are written for students. This one is for the engagement officer with four hundred survey comments and a report due in three weeks: the method, a worked example, and the habits that make findings hold up when challenged.

What is thematic analysis in qualitative research?

In qualitative research, thematic analysis is one of the most widely used ways to analyze text. It became a recognized method largely through Virginia Braun and Victoria Clarke, whose 2006 paper set out a clear, step-by-step approach, and whose later work (including their 2021 book) refined it as reflexive thematic analysis.

It suits community engagement because it is flexible: it works on a dozen comments or several thousand, and it produces what decision makers need, a short list of themes with descriptions, counts and representative quotes.

What it is not is a word count. A theme is a pattern of shared meaning, organized around a central idea. "Lighting" is a label for where comments cluster. "People avoid the river path after dark because it feels unsafe" is a theme, because it says something.

Braun and Clarke's six phases of thematic analysis

Braun and Clarke describe six phases. They are not a strict sequence; expect to move back and forth.

  1. Familiarize yourself with the data. Read the responses, ideally all of them, before coding anything. Note first impressions, surprises and anything you do not understand.

  2. Generate initial codes. Work through the responses and attach short labels to anything relevant to your question. A single comment often carries several codes. Keep the response ID next to every code.

  3. Generate initial themes. Look across your codes for patterns. Group codes that share a central idea into candidate themes. Expect some codes not to fit anywhere yet.

  4. Develop and review themes. Check each candidate theme against the coded extracts and then against the full dataset. Merge, split or drop themes that do not hold together.

  5. Refine, define and name themes. Write a sentence or two describing each theme: what it captures and what it does not. Give it a name that says something, not just a label.

  6. Write up. Report each theme, its evidence and what it means for the decision. In engagement work, this is the what we heard report.

The phase names above follow Braun and Clarke's later wording; their 2006 paper uses slightly different labels ("searching for themes", "producing the report"), but the steps are the same.

Before phase 1: set up the dataset

Most analysis problems start before the first comment is read. Write down the decision the engagement informs and what was genuinely open to influence. List the questions people actually answered, word for word. Put every channel into one dataset with a stable ID, channel and date for each response. Keep the original text untouched in its own column, mask personal details you do not need, and flag duplicates rather than deleting them.

Group organized campaigns and form letters, record how many there are, and analyze the shared wording once. Then read each one for anything the person added to the template, which is often the most useful part.

Reflexive thematic analysis, in brief

Braun and Clarke now call their approach reflexive thematic analysis, to distinguish it from versions that rely on a fixed codebook and measure agreement between coders.

The core idea is that themes do not "emerge" from data on their own. People generate them, and the analyst's background, assumptions and purpose shape what they see. Reflexive thematic analysis treats that as something to acknowledge and reflect on, not something to eliminate.

The practical lesson for engagement teams: you have a view on the project and know which answers would be convenient. Write down your assumptions before you start, notice when a theme happens to match what the project already wanted, and have someone outside the project read a sample.

Thematic coding: what is the difference between codes and themes?

A code is a short label for a single idea in a piece of text. A theme is a broader pattern that brings several codes together around one central idea.

  • Code: "toilets locked early"

  • Code: "no change table"

  • Code: "shade sails torn, not repaired"

  • Theme: "Facilities exist but are not usable when people need them"

Codes stay close to what people said; themes interpret it.

Braun and Clarke also distinguish semantic coding (what the comment explicitly says) from latent coding (the assumptions or meanings underneath it). Most consultation analysis is mainly semantic, which keeps it close to people's words and easier to defend.

Inductive vs deductive thematic analysis

In an inductive approach, codes come from the data. In a deductive approach, you start from existing ideas and code against them.

Consultation work usually needs both. The deductive part comes from your engagement objectives and the questions you asked. If an objective was "understand barriers to using the park", then "barriers to access" is a starting code before you read a word. The inductive part catches what you did not expect, which is often the most important thing in the dataset.

Build a short starting frame from the objectives, define each code in one sentence, then add codes freely as the responses surprise you, logging each one.

A thematic analysis example: community feedback on a park upgrade

Here is a small worked example. The council is consulting on an upgrade to a hypothetical Riverside Park, and the survey asked: "What would make the park work better for you?" The comments are invented for illustration.

The comments

  • R01: "Please put lights on the river path. I walk home from the station after dark and it's pitch black."

  • R02: "More shade over the playground. The slide is too hot to touch by midday in summer."

  • R03: "Lights would be good but keep them low and pointed down. Our bedroom faces the path."

  • R04: "Don't waste money on lights. Nobody uses the park at night."

  • R05: "The toilets are locked by 4pm. With small kids, that means we go home."

  • R06: "Shade trees, not sails. The sails get torn and never get fixed."

  • R07: "I don't feel safe on the path on winter evenings. Lighting please."

  • R08: "Toilets that are open and clean, and a change table."

  • R09: "I use a wheelchair and the gravel near the north gate is impossible after rain. I've stopped coming."

  • R10: "Lighting, more shade, fix the toilets. Same as everyone's saying."

Step 1: initial codes

  • R01: path lighting request; evening commute; darkness

  • R02: playground shade; summer heat

  • R03: lighting with conditions; light spill on homes (adjoining resident)

  • R04: opposes lighting; cost; claim of low night use

  • R05: toilet opening hours; families with young children; visits cut short

  • R06: prefers trees over sails; sails not maintained

  • R07: feels unsafe; path lighting request; winter evenings

  • R08: toilet opening hours; cleanliness; change table

  • R09: path surface; wet weather; wheelchair access; stopped visiting

  • R10: path lighting request; playground shade; toilets; "same as everyone"

Step 2: candidate themes

A first pass groups the codes by subject: Lighting (R01, R03, R04, R07, R10), Safety (R01, R07), Shade (R02, R06, R10), Toilets (R05, R08, R10), Maintenance (R06, R08) and Access (R09).

These are buckets, not themes yet. Reviewing them shows three problems. "Lighting" and "Safety" are the same story told twice. "Lighting" also hides a disagreement: R03 wants conditions and R04 opposes it outright. And "Toilets" and "Maintenance" share a central idea: things the park already has are not usable when people are there.

Step 3: final themes

  1. People avoid the river path after dark because it feels unsafe, but lighting needs to respect neighbors. 5 of 10 responses (R01, R03, R04, R07, R10). Three ask for path lighting, one supports it with conditions, one opposes it. Representative quotes: "I walk home from the station after dark and it's pitch black" (R01); "keep them low and pointed down. Our bedroom faces the path" (R03).

  2. Summer heat limits use of the playground, and people prefer lasting shade. 3 of 10 (R02, R06, R10). Quote: "The slide is too hot to touch by midday in summer" (R02).

  3. Facilities exist but are not usable when people need them. 4 of 10 (R05, R06, R08, R10). Covers toilet hours, cleanliness, the missing change table and unrepaired sails. Quote: "The toilets are locked by 4pm. With small kids, that means we go home" (R05).

  4. The path surface shuts some people out of the park. 1 of 10 (R09), flagged as a high-impact view. Quote: "I've stopped coming" (R09).

What the example shows

Responses can sit in more than one theme, so counts add up to more than ten. R06 appears in both the shade and facilities themes because it says two things.

R04's claim that "nobody uses the park at night" is reported as a view, not a fact.

R03 is one comment, but it comes from someone directly affected by the change, which is why the theme names the condition and does not read as a simple request.

R09 is a single response, but it describes a barrier that may be keeping out people the consultation never heard from. Leaving it under "other" would be the most consequential mistake in this analysis.

How to keep thematic analysis defensible

Defensible analysis is analysis someone else can follow: if an elected member or an objector asks why a theme was reported that way, you can show the comments, the codes, the reasoning and who signed it off. Our guide to defensible community engagement covers this across the whole process. For analysis, it comes down to a few habits.

  • Link every theme to its comments. Each theme lists the response IDs behind it, and each response can be found in its original form.

  • Record your decisions. Keep a short log of codes merged, split or redefined, and why. Note how you handled campaigns and duplicates.

  • Count carefully: themes are not votes. Report how many responses raised a theme, with the denominator ("5 of 10 responses to this question"). Avoid "most people support" unless the question actually asked about support. Consultation participants choose to take part; they are not a representative sample.

  • Give the minority-but-important view its own place. A single comment from someone directly affected, from a group you struggled to reach, or offering information the project team did not have can matter more than fifty general comments.

  • Check who is missing. Compare who responded with who the project affects. If renters or young people are absent, say so. The stakeholder mapping tool helps you check the list of affected groups against who you actually heard from.

  • Record who did what. Note who coded, who checked a sample, which tools were used (including any AI) and who signed off.

If your organization's engagement framework is silent on how analysis should be done and recorded, every officer ends up inventing their own method. A free framework audit reviews your strategy, policy or framework against a fixed rubric and shows where staff would still be guessing.

For the wider picture of coding frameworks and governance, see our community engagement analysis guide.

Why word clouds mislead (and when they help)

Word clouds are often the first chart in a consultation report. They are easy to misread, because they count words, not meaning.

  • Frequency is not meaning. In the park example, "lights" would be one of the biggest words in a cloud, even though one of those comments opposes lighting and another supports it only with conditions.

  • Negation disappears. "Not safe", "no more lights" and "don't remove the trees" all split into words that suggest the opposite.

  • Synonyms split the signal. "Lights", "lighting", "lamps" and "dark" all describe the same concern, but a cloud shows them as four smaller words.

  • One person can dominate. A long submission that repeats a phrase twenty times outweighs twenty short comments.

  • Context is lost. The single word "access" could mean parking, wheelchair access or opening hours.

Word clouds are still useful as a first look. Use one during familiarization to see the vocabulary people used, spot a phrase repeated across many responses (a sign of a campaign), or notice a word you did not expect. Then do the analysis. If you want to see what your own data looks like, try our free word cloud generator on your own comments.

Tools for thematic analysis: spreadsheets, NVivo and AI

Spreadsheets

For many projects, a spreadsheet is enough. Use one row per response or per coded extract, with columns for ID, channel, question, original text, codes, theme and notes. Filtering by code or theme gives you the evidence for each finding, and the file itself becomes your audit trail.

Qualitative analysis software

Tools such as NVivo, ATLAS.ti and MAXQDA were built for qualitative research. They help with long documents, large codebooks and multiple coders, and are worth the learning curve for large or contested consultations.

AI

AI can speed up coding a great deal across thousands of responses. It reads without fatigue, notices the same point made in different words, and applies an agreed coding frame quickly.

It also fails in predictable ways. It can produce plausible themes supported by one or two comments, or none. Summaries tend to favor what is common, so the R09 comment is exactly what gets lost. It smooths disagreement into a tidy finding.

As we argue in reading is not coding, the risk is not that a model attaches labels. It is that a model asked to "find the themes" designs the framework itself, with nobody on the record for its assumptions. Use AI with your coding frame, response IDs in the input, quotes and IDs in the output, a spot-check against the source, and a named person signing off each theme.

Where CE Canvas fits

Done regularly, the hard part is keeping the thread from comment to theme to decision. CE Canvas groups responses into themes, each traced to the comments behind it, with people deciding what becomes a theme. Findings show their sources, and drafts wait for a person to sign off. When the analysis is done, the what we heard report template shows how to write it up section by section.

See the flow from comment to theme to report on how CE Canvas works. The method in this guide works just as well with a spreadsheet and a careful team.

Frequently asked questions

How many themes should I have?

There is no fixed number. For one consultation question, three to six is common; more usually means some are still codes. Keep a separate place for minority and high-impact views so they are not forced into a theme or dropped.

What is the difference between coding and themes?

Coding is attaching short labels to the ideas in each comment, staying close to what people said. Themes are broader patterns that bring related codes together around one central idea. Codes describe the data; themes interpret it and tell the reader what people are saying.

Can I use ChatGPT for thematic analysis?

It can help, particularly with large volumes, but it should not do the analysis alone. Use only a tool your organization has approved, remove personal information first, give every response an ID, provide your coding frame and question, ask for themes with supporting quotes and IDs, spot-check the output against the source, and have a named person sign off the findings.

Is thematic analysis qualitative or quantitative?

Thematic analysis is a qualitative method: it is about meaning, not measurement. Counting how many responses raised each theme is a helpful way to show the shape of the feedback, but the counts describe a self-selected group of participants. They are not a vote and not a survey of the whole community.

What is Braun and Clarke's thematic analysis?

It is the six-phase approach Virginia Braun and Victoria Clarke set out in 2006 and later developed as reflexive thematic analysis: familiarization, coding, generating initial themes, reviewing themes, defining and naming themes, and writing up. It is the version most people mean by "thematic analysis", and it adapts well to consultation feedback.

About CE Canvas Team

The CE Canvas team blends deep experience in community engagement with innovative product design to transform how organisations connect with their stakeholders.

More guides by CE Canvas Team