Defining a Category
Codes and categories are essential for the validity of Qualitative Data Analysis. Therefore, these seemingly neutral tags that are applied to our text segments deserve some serious thinking. Unlike a simple code – that can be any tag that we apply – categories are more sophisticated. QDA-software does not differentiate between the two and they are often used synonymously (e.g. Rädiker; Kuckartz 2019, p. 69). Still, from a methodological perspective we can see a difference between temporary tags (codes) and well defined categories (Saldaña 2016, p. 12).
If our categories are poorly defined or inconsistent our research will create invalid results. In the worst case we might not notice until it’s too late. Therefore, an important step in QDA is a clear definition of categories/codes and a well established code system.
Fortunately, some people already spent decades thinking about just that! One of the most influential is Philipp Mayring (2015) who has clear demands in what makes up a proper category: A definition, an example and coding rules (Mayring 2015, p. 48-49).
The definition is a string of words that we use to describe what is meant with that category. For example:
“A crocodile is a large predatory reptile, that lives in the water and spends its days eating gnus, zebras and people. It usually has a long snout and sharp teeth.”
An example we often pick from our coded segments, usually we choose one that is most typical. In the case of our crocodile let’s use an image to represent that.
Coding rules are created during our process of coding text segments. They always need to be defined whenever we are not sure where a coded segment belongs. Not all categories may have them and other categories may have many of them, but they are essential to keep track of what we are doing. For our crocodiles we might think we are done with defining them, until someone tells us, that the first animal above is actually an alligator. There, we might need to define a coding rule like:
“If the snout of the animal is “V” shaped, it’s a crocodile, if it’S “U” shaped, it’s an alligator.”
(In my humble opinion we need to set up two more aspects to define a category in QDA: Its scope and its quantity, but we will look into this in a later article.)
QDA – a dynamic process
When setting up our code system, we must not forget that coding rules, definitions and even the existence or non-existence of codes are subject to change during the working process (Mayring 2015, p. 52). We might start with very broad categories and update them to higher precision when we encounter similar content. Furthermore we might start with a clear cut system of categories just to encounter phenomenons that are highly relevant, but that we did not anticipate. This brings us to where our codes are coming from; from the data or from our conceptual knowledge?
Inductive and Deductive
Basically, there are two different kinds of categories; inductive and deductive.
Inductive categories (or data-driven categories) are created from working with the text. We read the text and when we notice a theme that is reappearing or a meaningful concept that is addressed again and again, we might turn it into a code and later into a category. The system that results is called an inductive or data-driven code system. We will often do that when we approach new data, that we are not familiar with or when we do research in an area that has hardly been studied before (see Mayring 2015 p. 85-87).
Deductive categories (or concept-driven categories) on the contrary, are coming from our research question, conceptual ideas, prior experience, from literature or theory. Often when we define our research question we will already anticipate certain types of answers or fields of interest, these may be fed into our analysis even before we have read the first line of text (see Kuckartz 2014, p. 77-98).
In day to day analysis we often use not one or the other, but varying degrees of both. Quite often we will have “main” or top-level codes coming from our research interests and we will create more detailed “subcodes” when working with the material. Furthermore, we often encounter topics or concepts that we did not anticipate before and we would be ill advised, to just leave them aside. On the contrary, it would be fairly impossible (and even ignorant) to dismiss all our previous knowledge and the results of other researchers when working exclusively with data-driven codes (Kuckartz 2014, p. 52-53).
The Fork in the Road: general or specific codes?
Often we will start with temporary codes following the scheme: “relevant-statement-for-my-research-question”. It is valid to do that and we are indeed well advised to do so when encountering data for the very first time. But as soon as we have gained some insight, we will turn towards a more sophisticated approach. In principle, there are two different ways that we can follow: either starting with general or with specific codes (see Rädiker; Kuckarzt 2019, p. 72-74).
When working with quite general codes (also called broad-brush coding), we read our text while applying very broad categories that bring some general order into our data and tell the gold from the scrap. When we have done that, we go through the content of these categories again and start to split them up into subcodes.
The plus side is that we go through everything twice and we can easily eliminate “false positives” (segments that do not belong here). On the contrary we might get too focused on that preselected content and forget to include material that we have missed in the first place (we get many “false negatives”).
The other way would be to work with highly specific codes (also called micro coding). Here, many segments get their own and often unique code. Later, we end up with a list of dozens or even hundreds of codes and then start grouping and merging them by building proper categories or top-level codes above them.
In this scenario definitions become important only much later and we might not so easily miss important segments. On the other hand, it might easily descend into a confusing mess of poorly defined codes without a chance of back-checking on what we did.
Whichever way you choose, general-to-specific or specific-to-general (broad-brush coding or micro-coding) or however you wish to combine them, both of them are valid. I rather prefer the first way, but this is due to my own methodological background. It seems to me that the first way is more strongly correlated with Qualitative Content Analysis (Mayring 2015, Kuckartz 2014) and MAXQDA; whereas the second way fits better with Grounded Theory (e.g. Strauss-Corbin 2010) and ATLAS.ti. As always, don’t follow me. You have to (re)consider the best road for yourself!