This is an Eval Central archive copy, find the original at evalacademy.com.
This article is rated as:
What is a codebook?
A codebook for qualitative research is a stand-alone document that contains a list of themes, codes, and definitions that you are using in your qualitative analysis. A codebook helps to keep the entire team on the same page about the qualitative analysis and supports turning your analysis into a clear summary, where you can easily add or consolidate details as needed. A codebook can be used with both inductive and deductive coding approaches. In inductive coding, you aim to develop a theory or develop codes and themes as you go. With deductive coding, you aim to test an existing theory, meaning you have a coding structure developed in advance.
Having a codebook can help you keep track of themes and codes, especially when you have multiple coders or emerging themes. While some qualitative analysis software provides you with a space to include the information contained within a codebook, the information isn’t all contained in one place. Having a separate codebook allows you to have one easily updatable document that contains all the information in one place. I like to keep my codebook open in a separate tab while I am coding regardless of whether I’m coding in fancy software or in Excel or Word.
I like to build my qualitative codebook in Excel, adding columns and rows to fit whatever analysis I’m completing. Typically, my codebooks start with the same 4 key components:
-
Theme and code headings
-
Code definition and description
-
Examples or key quotes
-
References to source documents
How to create a codebook
To help you understand how to create and use a codebook, I’ll walk through each of these key components, then provide you with two examples.
Theme and code headings
The first few columns in my codebook are dedicated to the theme, subtheme (if necessary) and code. Each row in the codebook is dedicated to one code. If you are using a deductive coding approach, you would build these columns and rows into your codebook before you start coding, populating the themes and codes in advance.
Code definition and description
Next up are the code definition and description columns. Sometimes I just create one combined definition and description column, but in more detailed projects it is helpful to keep them separate. With a deductive coding approach, you can complete the code definition column in advance, while if you are taking an inductive approach, you will complete these as you go. Codes should be clearly defined to avoid overlap between codes. Even with a deductive coding approach, the definition of what is included in each code will likely evolve over time or need clarification as you dive into coding. When coding as a group, the group should discuss all changes to code definitions before they are made. The code description section is where you can jot down some high-level details of what you are finding within the code. This section also helps you summarize your findings and write your reports. Just remember, the code definition is where you put what the code is about, while the code description is where you put the details of what you are finding in each code.
Examples or key quotes
This section is where I put high-quality examples of findings in a code. Sometimes I have an ‘examples’ column and a ‘quotes’ column and sometimes just one column will do. Make sure to include references to your source documents (e.g., which interview or focus group the quote came from) when including quotes in these columns.
References
This is one of the most subjective sections that will vary from project to project, but typically I use this space to indicate which interviews or focus groups the code was discussed in. If I’m analyzing interviews or focus groups that fall into different categories, you can use the reference columns to indicate whether the code was discussed in each category or not. If your code doesn’t include directionality (e.g., a code about “wait times” doesn’t indicate if the discussion was positive or negative) it can be helpful to note if certain groups discussed the code in different ways. This section can also help you quantify your qualitative data if necessary (see our “How to Quantify Qualitative Data” and “3 Easy Ways to Quantify Your Qualitative Data” articles for more on this!).
Example Codebooks
Here are two example codebooks to help you understand how the excel sheets can be set up and tailored to your specific analysis.
Example 1
In the first example, the Examples column is used for lengthier, more descriptive quotes or examples, while the Quotes column contains the shorter, punchier quotes that I might want to include in a report. The References section highlights which groups discussed the code and specifically denotes which focus groups the code was referenced in.
Example 2
In the second example, the Examples column serves as both the Examples and Quotes column. The References section shows which focus groups the code was discussed in and the directionality of the discussion (positive or negative). In Example 2, the focus groups may have been heterogenous, and included a mix of all participants, hence the sub-columns were unnecessary.
While codebooks are useful tools to support your qualitative analysis, they don’t help you understand how to code. If you are looking for more resources to help you learn about qualitative coding, check out some of our articles:
– Definition of qualitative analysis
– Definition of thematic analysis
Let us know if you have other questions about qualitative analysis that we can help answer!