Creating a coding frame with ATLAS.ti

What is a code?

A code in ATLAS.ti can be a simple description, a concept, a category, a subcategory, or a wildcard that modifies a link in a network. The software itself does not dictate how to use a code. It only provides this entity as an item in the toolbox. In this article, I give you some guidance on how to use the ATLAS.ti toolbox to build a coding system that helps you with advancing your analysis. To get started, I would like to play a virtual puzzle with you. You probably have played a puzzle before at some point in your life. You can apply the skills you learned when playing puzzles to coding qualitative data.

First steps in developing a code system

Unless you want to code deductively using an existing framework, keep an open mind when you begin to code your data, notice as many things as you can and collect them via coding. If you feel that it is essential to read all the data first and write down notes on a piece of paper before you create codes in ATLAS.ti, then this is a suitable way to proceed. If, however, after reading some of your data, you already have some ideas for codes, then go straight ahead and start coding in ATLAS.ti. Do whatever feels most natural to you.

At first, you will generate lots of new codes; in time, you will reuse more and more of the codes you already have, and you won’t need to create new ones. You have reached a first saturation point. In technical terms, you will drag and drop existing codes from the Code Manager or navigation panel onto the data segments. You have roughly described the various elements in the data at this stage. As soon as you reach this point, when you no longer add new codes (or only a few) and mostly use drag-and-drop coding, it is time to review your coding system. If you do it much later, it will need more work because then you will have to go through all the documents again to apply newly developed subcategories and recheck all other codings.

If you have noticed a lot of things – let’s say you already have 300 or more codes after coding a few interviews – your codes are probably very descriptive. Coders of this type are referred to as splintersin the literature. If you are a splinter, you need to stop coding new data at this point, review your coding and begin to merge your codes. After merging and reorganizing your codes, you will have a single code that might hold ten quotations in their original form. This is far better than ten codes that only summarize one data segment each. Instead of being conducive to your analysis, too many codes prevent further analysis.

Building categories and subcategories

The first categories that you develop are likely to be provisional, as they are based on very little coding. With more coding, they are likely to change and develop further. I like Saldaña’s idea of first cycle and second cycle coding (Saldaña, 2013: 8). The idea of the cycle fits the nature of the N-C-T model, where you have seen that qualitative analysis is cyclical rather than linear. First cycle coding, according to Saldaña (2009: 45), refers to those processes that happen during the initial coding. These are the ideas you notice and collect when you begin the coding process. Second-cycle coding is the next step. From experience, I would like to add that there are at least a third and fourth cycle of coding as well. When coding data in ATLAS.ti, the aim of this process is to develop a structured code list based on a subsample of your data. Once you have developed a first structure, you can apply the codes to the remaining data. You will likely continue to make changes to the code list and refine the structure the more you code. But this is OK.

Other authors also describe the coding process in a similar way (see, e.g., Bazeley, 2013; Bazeley and Richards, 2000; Charmaz, 2006; Fielding and Lee, 1998, Kuckartz, 1995; Richards, 2009; Richards and Morse, 2013; Silver and Lewins, 2014). Richards (2009), for example, refers to it as a catalog of codes. As advantages of a well-sorted catalog she mentions speed, reliability and efficiency. The problem, as I see repeatedly in my everyday work, is the translation of this process into mouse clicks and the technicalities of it in a software environment. Even if users know the technical aspects of coding, on the one hand, and read the useful tips, on the other, they often find it difficult to apply these skills. It is not so difficult, but neither is it self-explanatory. Therefore, the following two video tutorials walk you through the process of category and subcategory building.

References

• Bazeley, Pat (2013). Qualitative Data Analysis: Pratical Strategies. London: Sage.

• Bernard, Russel H. and Ryan, Gery W. (2010). Analysing Qualitative Data: Systematic Approaches. London: Sage.

• Charmaz, Kathy (2006/2014). Constructing Grounded Theory: A Practical Guide Through Qualitative Analysis. London: Sage.

• Friese, Susanne (2019). Grounded Theory Analysis and CAQDAS: A happy pairing or remodeling GT to QDA? In Tony Bryant and Kathy Charmaz (eds.), chapter 11. The SAGE Handbook of Grounded Theory. London: Sage.

• Friese, Susanne (2016). CAQDAS and Grounded Theory Analysis. MMG Working Paper 16-07

• Guest, Greg, Kathleen M. MacQueen, and Emily E. Namey (2012). Applied Thematic Analysis. Los Angeles: Sage.

• Richards, Lyn (2009, 2ed). Handling qualitative data: a practical guide. London: Sage.

• Richards, Lyn and Janice M. Morse (2013, 3ed). Readme first: for a user’s guide to Qualitative Methods. Los Angeles: Sage.

• Saldaña, Jonny (2009/2013/2015). The Coding Manual for Qualitative Researchers. London: Sage.

• Silver, Christine and Lewins, Ann (2014, 2ed). Using Software in Qualitative Research: A Step-by-step Guide. London: Sage.