Template Analysis: Nigel King's Flexible Approach to Thematic Coding

Template analysis is a style of thematic analysis, developed by psychologist Nigel King, in which you build a hierarchical coding template from part of your data, often starting with a few themes chosen in advance, then apply it to the rest and revise it until it fits. It sits between fully inductive methods, where every theme comes from the data, and fixed codebooks, where every code is set before you start. That makes it a practical choice for applied research, where you know some of what you're looking for but want room to be surprised.

This guide explains how template analysis works, the six steps most researchers follow, how it differs from other thematic approaches, and where AI interview tools fit in.

What is template analysis?

Template analysis organises qualitative data, usually interview transcripts, around a coding template: a structured, hierarchical list of themes. Broad themes sit at the top, with narrower sub-themes nested beneath them. The template is the main output of the analysis and the basis for your write-up.

King developed and refined the method through the 1990s and 2000s at the University of Huddersfield, and the most widely cited account of it is Brooks, McCluskey, Turley and King's 2015 paper in Qualitative Research in Psychology, "The utility of template analysis in qualitative psychology research". Although it was born in psychology, it's now used across health, education, management and user research.

Three features define the method:

• A priori themes are allowed. You can start with a small number of themes decided before coding, drawn from your interview guide, earlier research or a theory. They're tentative: you drop or redefine them if the data doesn't support them.
• The template is built from a subset. You develop an initial version on part of the data, not the whole dataset, then apply and revise it.
• Hierarchy is flexible. You code more deeply where the data is richest. One theme may have three levels of sub-themes while another has none.

Template analysis vs other thematic approaches

Template analysis is easiest to understand next to its neighbours.

• Reflexive thematic analysis (Braun and Clarke) treats themes as something the researcher actively builds from the data, with no codebook and no a priori themes. It's ideal for open, interpretive work. See our guide to reflexive thematic analysis.
• Codebook approaches fix the codes up front, often with definitions and inclusion rules, so several coders can apply them consistently. See building a qualitative research codebook.
• Framework analysis builds a thematic framework, from early data or prior theory, then charts summarised data into a matrix of cases and themes. It is popular in policy and health research. See framework analysis.
• Template analysis takes the middle ground: some structure up front, but a template that keeps changing until it fits the data.

If your team needs the speed and shared structure of a codebook but your research question isn't fully settled, template analysis is usually the better fit.

How to do template analysis: the six steps

Brooks and colleagues describe the procedure in roughly these stages. In practice you'll loop back between them.

1. Get familiar with the data

Read through your transcripts, or at least a good sample of them, before coding anything. Note first impressions, surprises and recurring language.

2. Do some preliminary coding

Mark passages in a few transcripts that seem relevant to your research question. This is where a priori themes come in: if your study was built around, say, onboarding, pricing and support, you might start with those as tentative top-level themes. Keep them loose. A priori themes are a starting point, not a commitment.

3. Cluster the codes into themes

Group related codes and decide how they relate. Some become top-level themes; others become sub-themes underneath. Look for integrative themes too: ideas that cut across several themes, such as trust or time pressure, which King suggests can be shown separately in the template.

4. Write the initial template

Turn your clusters into a first version of the coding template, based on a subset of the data. For a study of 20 interviews, that might be four to six transcripts chosen to cover the range of participants. Write a short definition for each theme so others can apply it.

5. Apply the template and revise it

Code further transcripts with the template. Each time something doesn't fit, change the template. You might add a theme, split one in two, merge two that overlap, move a sub-theme to a different parent, or delete an a priori theme the data never supported. Keep a note of each change and why. Repeat until new transcripts no longer prompt meaningful changes.

6. Finalise and apply to the full dataset

Apply the final template to every transcript, then use it to structure your interpretation. The write-up usually follows the template, with themes illustrated by quotes and the template itself shown in full.

What a coding template looks like

A template is just an indented list. Here's a short example from a study on why trial users don't convert:

1. Getting started
   1.1 First session experience
   1.2 Setup effort
       1.2.1 Data import
       1.2.2 Inviting teammates
2. Perceived value
   2.1 The "aha" moment
   2.2 Comparison with current tool
3. Buying process
   3.1 Who needs to approve
   3.2 Timing against budget cycles

Integrative theme: time pressure (appears across all three)

Notice the uneven depth. Setup effort earned a third level because participants talked about it in detail; the buying process didn't.

Strengths and limitations

Strengths:

Photo by Jakub Żerdzicki on Unsplash

• Flexible. No fixed number of levels, no required set of codes.
• Efficient. Building the template on a subset saves time on large datasets.
• Good for teams. A shared template with definitions helps several researchers code consistently.
• Honest about prior knowledge. You can name the themes you expect instead of pretending you came in with a blank slate.

Limitations:

• A priori themes can blinker you. If you hold on to them too tightly, you'll find what you expected. Actively look for material that doesn't fit; negative case analysis is a useful discipline here.
• The template can become the analysis. A tidy hierarchy isn't an interpretation. You still need to explain what the themes mean and how they connect.
• Less suited to deeply interpretive or idiographic work, where approaches such as interpretative phenomenological analysis fit better.

Template analysis with AI interviews in Koji

Koji runs AI-moderated voice and text interviews and analyses each one automatically, which gives you a head start on several steps.

• Your brief supplies a priori themes. The questions and topics in your study's research brief are a natural first set of tentative themes, just as an interview guide is in a manual template analysis.
• Answers arrive sorted by question. Each interview is analysed against the questions you asked, including what came out in follow-ups. That makes preliminary coding (step 2) faster, because related material is already grouped.
• Themes across interviews. Koji's research report groups recurring themes across participants and shows how many people support each one. Use that as a draft to compare against your own template, not as a replacement for it.
• Every theme links to evidence. You can trace each finding back to the quotes behind it, which helps when you're checking whether a theme earns its place.
• Structured questions for the closed parts. If one part of your study is really a rating or a choice, ask it as one of Koji's structured questions and keep the template for the open material.

A sensible workflow: let Koji run and summarise the interviews, read a handful of full transcripts yourself to build your initial template, then use Koji's report and evidence panel to test and revise it against the rest.

Tips for a strong template analysis

• Limit a priori themes. Three to five is plenty. More and you're writing a codebook.
• Choose the subset deliberately. Include participants who differ in ways that matter: role, segment, outcome.
• Write definitions early. A one-line definition per theme prevents drift, especially in teams.
• Keep a change log. It's your audit trail, and it shows readers how the analysis evolved.
• Show the final template. Readers trust findings more when they can see the structure behind them.

Related Resources

• Structured questions in AI interviews: handle the closed parts of a study without coding
• Reflexive thematic analysis: the fully inductive alternative
• Building a qualitative research codebook: when codes should be fixed up front
• Framework analysis in qualitative research: the matrix-based neighbour
• Coding qualitative data: the basics of coding interviews
• Rapid qualitative analysis: when you need findings in days