by QSR

Supports robust qualitative and mixed methods research for virtually any data source and any research method.

Learn more

by QSR

Intuitive data analysis software designed for public policy experts analyzing surveys.

Learn more

Creating software to help you discover the rich insights from humanised data.

Learn more

Learning NVivo using the Five Level QDA(R) Method – Theory and Practice

29 January 2018 - BY Silvana di Gregorio

Review of Woolf, N. and Silver, C. (2018) Qualitative Analysis Using NVivo: The Five Level QDA(R) method, Routledge

Since 1998, Nick Woolf and Christina Silver have both worked as consultants and teachers on using software that supports the analysis of qualitative data. Together, they have experience of a wide range of CAQDAS* software. Christina manages the CAQDAS Networking Project at the University of Surrey, UK as well as her own business.  Nick has his own training and consultancy business based in the States.

They both recognized that there are common challenges new CAQDAS software users face regardless of which software they decide to use. The first set of challenges is to disabuse new users of some misconceptions about such software. These include:
  • NVivo nor any other CAQDAS package does the analysis for you
  • NVivo nor any other CAQDAS package is a method
 
The second set of challenges revolves around the best way to teach new users such software. Christina and Nick’s combined teaching experience led them to the conclusion that simply learning how to operate a CAQDAS program e.g. what happens when you click each button in NVivo, does not lead to using the software powerfully.
 
They have developed an alternative method for teaching software called – the Five Level QDA(R) Method. I have read their NVivo book and have also attended a two-day NVivo workshop run by Christina Silver with Sarah Bulloch to see the method in practice.
 
The book is in three parts: The first part describes the principles of the 5 level QDA method. These chapters are the same in all three books. The second part describes how to put this method in practice with NVivo and the final part has some case illustrations. The book is supported by a companion website with supporting videos, worksheets, and resources.
 
The key to their approach is to separate out analytic strategies – what you plan to do – from tactics – how you plan to do it. Tactics need to fit strategies. So you need to start with your strategies – what you plan to do with your research. The implications for learning NVivo is not to start with ‘how do I import data or how do I code?’ - but with, ‘what is the purpose of my study? What kind of data have I collected or need to collect? What approach to analysis is appropriate?’
 
Part One describes this process: learning how to first break down your strategies into a series of small analytical tasks. Then figuring out which tactics are best suited to achieve those analytical tasks. This is done with a real-life example that has nothing to do with software, but with meal preparation! Using this concrete example makes the theory much easier to understand.
 
Part Two focuses on how to translate analytical tasks into tactics to use in the software to achieve those tasks. You firstly need to frame your analytical tasks into one or more of three types of units; units of analysis – the major entities that are the subject of analysis , units of data – the type of data that you have collected, and units of meaning – which could be concepts or data segments that are meaningful. In addition, you should specify the purpose of an analytical task. Finally, you need to translate the task into the NVivo components that can achieve the task.
 
To simplify the process, Woolf and Silver have reduced NVivo into 13 components. Components are not the same as project items – components are things that can be acted upon. So not all project items are components but all components are project items. The components are:
 
Providing data:
  • Sources, folders, attribute-value, case
Conceptualising data:
  • Reference, node, coded-reference, query-result, set and search folders
Writing:
  • Annotation, memo
  • Map, and chart.
 
Each component can take on a number of different actions. Common actions are: create, rename, search, write, sort, and visualize. Once you have identified which component(s) are relevant for the analytical task, you need to identify whether NVivo already has a tool to fulfil that task or whether you need to construct a tool within NVivo. For example, if your analytical task is to find what words Donald Trump uses the most in his speeches, you would search (action) the sources (component) and select an existing tool in NVivo to do so – the Word Frequency tool. A constructed tool is where there is no one tool in NVivo that can achieve the task. To achieve the task you would need to combine a series of tools in NVivo.
 
Woolf and Silver provide worksheets and numerous worked examples of translating analytical tasks into relevant NVivo components and finally, deciding on the relevant tool(s) to achieve the analytical task. Part Three of the book contains two case illustrations from real NVivo projects.
 
I have long been an advocate of starting any training with thinking about your own project. Judy Davidson’s and my book on Qualitative Research Design for Software Users introduces the Design Framework as a first step in mapping out your research design on a worksheet so you can then ‘translate’ it (Woolf and Silver’s terminology) in the way you set up your project in NVivo. However, Woolf and Silver have gone beyond project set up into giving you the theory and tools to break down your whole analysis process in NVivo so you can learn how to harness the power of NVivo in the same way an expert user does intuitively.
 
My only concern is whether their approach could be overwhelming for a novice. I have simplified their method above but in their book and in the training they go through the theory in far more detail. As an expert NVivo user and former trainer, I endorse their approach. But I am not in a position to say what the experience is for a new user. However, on the first day of the workshop, they constructed an excellent way to start learning NVivo (after a morning of theory) – the NVivo component hunt. This was group work – where each group were assigned three/four components and had to find where they are located in NVivo, and what actions can be performed on them. Then each group reported back to the whole class about their assigned components. I found this a more effective way of learning about parts of NVivo than from a demo from the trainer. But there is still a lot to unpack.
 
Most of the people who attended the workshop had already started to work on their research in NVivo and I am confident that they found the two-day workshop very useful. I am not sure about the few who were completely new to the software. I think there was a bit too much detail about the theory in the workshop. However, it is still early days about applying this approach in practice and I am sure that this approach to training will evolve over time. The book itself is an extremely valuable resource for anyone who is teaching NVivo and a useful guide for anyone using NVivo. I highly recommend it.
 
*CAQDAS – Computer Assisted Qualitative Data AnalysiS
 
Reference: di Gregorio, S. and Davidson, J. (2008) Qualitative Research Design for Software Users, Maidenhead, Berks.: Open University Press/McGraw-Hill