What makes a good codeframe?

This may sound simple, but codeframes are central to the coding process and have a huge impact on the usefulness of the final analysis.

It’s important to get them right, so in this blog we take a look at what makes a good codeframe, and how codeit can help you build one.

Let’s define good

So, how do you know if your codeframe is “good” or “bad”? Unfortunately, things aren’t always quite as clear cut as that. It doesn’t make sense to lay down hard and fast rules, like “you should have no more than 50 codes” or “you should always use nets”.

Coding is often as much an art as it is a science, so what constitutes as “good” can vary from project to project.

So, below we lay out some guiding principles which we think all codeframes should live up to.

1. Research Objectives
   
   The acid test, and the most important principle, is whether the codeframe and the coding support the research objectives of the survey.
   
   For example, if an NPS survey seeks to understand why detractors are unhappy, the coding needs to reveal actionable reasons, so, say, “Staff politeness” rather than simply “Service”.
   
   Or if an awareness question seeks to measure awareness of brand variants, then the codeframe needs to capture data at that level, so, “Cadbury Fruit & Nut” rather than simply “Cadbury”.

2. Completeness
   
   For your analysis to be meaningful, your codeframe needs to be “complete”. It needs to capture all of the relevant themes expressed within your verbatim data. Typically, you apply a frequency threshold that a theme must reach before it is included in your codeframe. This threshold may vary depending on the research objectives.
   
   For example, if only one person expresses the theme “skin irritation”, should that be included in the codeframe? Usually not, but if you were coding product test data for adverse events, then it’s likely you would.
   
   So, what constitutes “completeness” can vary, but your aim should be to ensure that no significant theme is omitted from your codeframe.

3. Non-overlapping
   
   It is important that codes within your codeframe are distinct and do not overlap in any way. Otherwise, the ambiguity that this causes will make the downstream analysis step very difficult.
   
   For example, if you have both a “Taste” code and a “Flavor” code, then how is this meant to be interpreted at the analysis stage? Is ”Taste” different to “Flavor”? Can these be combined? Can a single verbatim be coded as both?
   
   You should avoid this kind of uncertainty by ensuring that the meaning of each code is clear and separated. Sometimes, if a theme does capture two similar concepts at once, then including both of these in the label can be a good approach to make things unambiguous, e.g. “Pool / Spa Facilities” or “Staff Friendliness / Staff Greeting”.

4. Granularity
   
   The devil is in the detail, as they say, and getting the level of detail right in a codeframe makes a huge difference to the final analysis. For example, should you have an overall code for “Flavor of Spices” – or should you have more fine-grained codes that break this down, e.g. “Flavor of cumin”, “Flavor of garam masala” etc...
   
   This is a bit of a “goldilocks” situation – too fine-grained and the analysis becomes mired in detail, too coarse and the final data is not actionable.
   
   The correct level depends, again on what you’re trying to achieve so will vary between projects.
   
   Sometimes nets can be useful in resolving this dilemma, allowing you to have it both ways. You can have a net for say, “Flavor of Spices” and separate codes within for each of the spices. This allows an analyst to view the data at the granular and coarse levels at the same time.

5. Maintainable
   
   Codeframes are often long-lived or reused on other projects. To some extent, you can think of a codeframe as a “living” document that can grow and evolve over time. Therefore, the codeframe you create must be self-explanatory, flexible and maintainable to make it easy for others (including yourself!) to work on it in future.
   

   All of the above points above lead to good codeframe hygiene and help make codeframes maintainable. Nets can also give your codeframes a structure that easily expand over time.
   
   Lastly, a good coding tool (like codeit) will give you the ability to add notes to your codes which provides documentation and help for future users of your codeframe.

So, you can see that codeframe creation is both an art and a science. codeit provides a set of tools that assists both the art and the science aspects. Our themeit tool can automatically extract themes from your verbatims and autocode them.

We’ve put all our knowledge and expertise into the themeit theme extraction process, and as a user you can guide it in terms of the desired end result (include nets, themes to include, maximum number of themes etc…)

This will get you a long way down the road using “science”, but we need to save room for the “art” too. We’ve seen above, the end result will always be improved by the application of a bit of human judgment and domain expertise.  With codeit you stay in control at all times. We make it easy to curate and refine the autogenerated results so you can be sure your codeframes are always up to scratch.

If you’d like to see for yourself how you can create high quality, actionable codeframes with codeit our 30-day trial is fully unlocked and totally free, sign up here.