Hi everyone!
I'm looking for tips and tricks for efficient qualitative data coding in collaboration. We, two researchers, have data from about 8 focus groups and 3 interviews, 60-80 minutes each. We talked about what respondents do to make effective use of executive functions to solve a difficult problem or pursue a complex task. E.g.: what do you do to keep your focus when you’re studying a difficult topic for you thesis? Our goal is to make a list of 'all' possible strategies to use executive functions through coding, using Atlas.ti. So, we do have kind of a framework which consists of every executive function, but every EF can be considered as a category for which we do not have specific codes yet: these codes for ‘EF-strategies’ will emerge from the data. We aim to code in tandem or parallel. How to do this efficiently? I wonder for example: what if I'm a lumper and my partner is a splitter, while we work in the same project (Atlas.ti). We would then definitely use different codes. How can we manage this in an efficient manner? Any tips or literature are highly appreciated!
It sounds like you want to develop a list of codes where you will have a high level of agreement when you each apply them. If so, I recommend that you both begin by doing your own coding on a single transcript, and then systematically compare who coded which sections and what you choose to label those codes. From there, you can agree on an initial set of code labels and definitions. After that, you both should apply this tentative list to a different interview. By the time you have jointly coded two or three interviews, you will probably have a relatively stable codebook that you can each use independently, with the recognition that it will continue to evolve to a certain degree.
With regards to lumping and splitting, the way that ATLAS.ti and most other software programs work, it is easier to begin with a more refined coding system (i.e., splitting) and then collapse codes later on (lumping).
I agree with David Morgan, as stated above. Coding individually first and comparing them together will make a lot of sense before lumping them. I am not familiar with how ATLAS.ti does it. I used NVivo-12 Pro for my coding and analysis. From my research experience, NVIvo is excellent in qualitative data coding in collaboration. Using parallel coding is delicate but very tedious.
Good luck.
Check out the Braun and Clarke 2006 and 2013 papers for suitable method of analysis. I suppose it depends if you intend to use TA (Thematic Analysis) or RTA (Reflexive Thematic Analysis). Also look at papers by Murray and Wilde (2010) for their use of IPA (Interpretative Phenomenological Analysis). Hope this helps :). Good luck with your research, BW Ken.
It's so great to receive both practical advice AND references to literature. I love to read before/while doing, so I'm very delighted with all your suggestions. Thanks a lot!
We will use TA btw, seems the best method for a Qstudy. But it's of course very appriopriate to make a good comparison between other approaches.
Merry Xmas and happy holidays!.
TA seems most appropriate for a Qstudy, but it's of course very appriopriate to make a good comparison between other approaches.
Merry Xmas and happy holidays!
Dear Simone Hanegraaff
Everyone is different - I will tell you how I like to do it:-) and I suggest it is not a matter of being efficient in the way of being fast - it is more a matter of remaining content with what you get from the coding process. If you focus on theory development it will most likely be a cumbersome process with a lot of going back and forth. I would say it is an interative approach also between coders not only existing concepts and data.
I agree with Morgan that developing a list individually may be a good choice and then systematically compare. Either I would do that or, I would sit together and code the first couple of transcripts and continuously compare.
When I code I have used ENVIVO but always in parallel with lost of big drawing etc. on my wall because I find the visualization important in terms of understanding the content AND the extend of a code. With a complex data material there is always a risk of several types of biases when using the soft ware - I think the confirmatory bias is an important one to mention.
I find that after coding some transcripts one has to go back and 'redo' initial transcripts because changes most often happen in the beginning of a coding process - it might be after two transcripts it might be more depending on the nature of the interviews (how pen-ended / informal / unstructured) they have been. And then I concur with the above suggestion that a somewhat stable code list exists.
I have enjoyed several publications of Goia, Morgan and others - I have a small paper on some practical issues regarding coding you may find intersting.
BR Mai