I briefly mentioned in my last blog post an interesting new article by Silver and Woolf (2015) on teaching QDA (Qualitative Data Analysis) and CAQDAS (Computer Assisted Qualitative Data AnalysiS). It’s a great article, not only because it draws from more than 20 years combined pedagogical experience, but suggests a new way to guide students through using software for qualitative analysis.

The basis of the strategy is the ‘Five-Level QDA’ approach, which essentially aims to get students to stop and think about how they want to do their qualitative analysis before they dive head-first into learning a particular CAQDAS package. Users are guided through a five-step tool that I would paraphrase as:

1. Stating the analysis/research objectives
2. Devising an analytic plan
3. Identifying matches between the plan and available tools
4. Selecting which operations to do in which tools
5. Creating a workflow of tools and software to meet all the aims above

For more detail, it’s worth checking out the full article which includes example worksheets, and there is also a textbook due out covering the approach in more depth. It’s also interesting to see how they describe the development of their pedagogical approach in the last decade or so.

The Five-Level method is designed to be delivered remotely, as well as in workshops, but to start out with being a software agnostic approach, drawing from the experience of the trainers to choose the best approach for each researcher and research project. Based around Analytic Planning Worksheets, it feels like the main aim is to get people to step back and think about their needs before learning the software.

This is often badly needed, mostly due to the practical limitations. Firstly, many people (especially new researchers) don’t do a detailed analytical plan when designing their project or research questions. In qualitative research, this is not always a disaster, often one source of investigation ends up being much richer than anticipated, and the variety of methods used mean that data doesn’t always look as we thought it would when we started (for better or worse).

However, there are also some very practical limitations which lead to people learning a CAQDAS package before they start their research journey. Often training courses are only offered once a semester (or year), so you need to take advantage of that when you can. While ideally there would be an interactive process between learning the capabilities and refining the analytical strategy, in the timescale of one project this is not always feasible. Often people have learnt so much after their first qualitative project, that the next time their analytical approach is extremely different.

The other issue is what CAQDAS is actually available: often a department or school will have a licence for just one (or maybe two) packages, and understandably, the training offered will often focus on those. There are also practical limitations when working as part of a team (especially people in a different institution) who might not have access to the same software. This affects the approach a lot, because it’s important to choose a workflow that everyone can participate in. I’ve been involved in projects where we end up using Excel for analysis, because everyone had access and familiarity with spreadsheet software.

I think that this is the kind of consideration that the Silver and Woolf worksheets are trying to tease out, and their examples illustrate how by point 5 people have chosen a number of tools that they can use together to answer their research questions.

As a final point, I think that RTP (Research Training Programmes) courses offered for post-grad students sometimes leave a lot to be desired on this front. Even those that are specifically on qualitative methodologies (where available) tend in my experience to have little more than a slide on the whole analysis process, and sometimes just a bullet point on software! I spend a lot of time talking to people about CAQDAS, and I am always surprised at how few people have heard even of NVivo, let alone a dozen alternative packages that I could name off the top of my head. Yet each has its own strengths and weaknesses: Transana is great for video, the Provalis products for stats geeks, MaxQDA a friendly all-rounder, Dedoose for working remotely, and Quirkos obviously for beginners.

But it’s a chicken and egg problem – to know what which software is best, you need to know what you can do with it. Which is why it can help so much to draw on the experience of CAQDAS trainers, but not just to go on a course and learn one package, but to go with an open mind and a research question, and let them suggest the best combination for each approach. In short, ask not what your CAQDAS can do for you, ask what you want to do with your CAQDAS!

Update (14/8/15):

Christain Schmieder has written a response to this blog post and the 5-level QDA, and how it links into his curriculum for qualitative question generation using CAQDAS.

I’m increasingly seeing qualitative research software as being the middle piece of a jigsaw puzzle that has three stages: collection, coding/exploring, and communication. These steps are not always clear cut, and generally there should be a fluid link between them. But the process, and enacting of these steps is often quite distinct, and the more I think about the ‘typical’ workflow for qualitative analysis, the more I see these stages, and most critically, a need to be flexible, and allow people different ways of working.

At any stage it’s important to choose the best tools (and approach) for the job. For qualitative analysis, people have so many different approaches and needs, that it’s impossible to impose a ‘one-size-fits-all’ approach. Some people might be working with multimedia sources, have anything from 3 to 300 sources, and be using various different methodological and conceptual approaches. On top of all this are the more mundane, but important practical limitations, such as time, familiarity with computers, and what software packages their institution makes available to them.

But my contention is that the best way to go about facilitating a workflow is not to be a jack-of-all trades, but a master of one. For CAQDAS (Computer Assisted Qualitative Data AnalysiS) software, it should focus on what it does best: aiding the analysis process, and realise that it has to co-exist with many other software packages.

For the first stage, collection and transcription of data, I would generally not recommend people use any CAQDAS package. If you are recording transcripts, these are best done on a Dictaphone, and transcribing them is best done in proper word-processing software. While it’s technically possible to type directly into nearly all CAQDAS software tools (including Quirkos), why would you? Nearly everyone has access to Word or LibreOffice, which gives excellent spell-checking tools for typos, and much more control over saving and formatting each source. Even if you are working with multimedia data, you are probably going to trim audio transcripts in Audacity (or Pro-Tools), and resize and colour correct pictures in Photoshop.

So I think that qualitative analysis software needs to recognise this, and take in data from as many different sources as possible, and not try and tie people to one format or platform. It’s great to have tight integration with something like Evernote or SurveyMonkey, but both of those cost extra, and aren’t always the right approach for people, so it’s better to be input-agnostic.

But once you’ve got data in, it’s stage 2 where qualitative software shines. CAQDAS software is dedicated to the coding and sorting of qualitative data, and has tools and interfaces specifically designed to make this part of the process easier and quicker. However, that’s not how everyone wants to work. Some people are working in teams where not everyone has access to CAQDAS, and others prefer to use Word and Excel to sort and code data. That should be OK too, because for most people the comfortable and familiar way is the easiest path, and what it’s easy to forget as a software developer is that people want to focus on the data and findings, not the tools and process.

So CAQDAS should ideally be able to bring in data coded in other ways, for people that prefer to just do the visualisation and exploration in qualitative software. But CAQDAS should also be able to export coded data at this stage, so that people can play with the data in other ways. Some people want to do statistical analysis, so it should connect with SPSS or R. And it should also be able to work with spreadsheet software, because so many people are familiar with it, and it can be used to make very specific graphs.

Again, it’s possible to do all of this in most CAQDAS software, but I’ve yet to see any package that gives the statistical possibilities and rigour that R does, and while graphs seem to get prettier with every new version, I still prefer the greater customisation and export options you get in Excel.

The final stage is sharing and communicating, and once again this should be flexible too. Some people will have to get across their findings in a presentation, so generate images for this. Many will be writing up longer reports, so export options for getting quotes into word-processing software is essential again. At this stage you will (hopefully) be engaging with an ever widening audience, so outputs need to be completely software agnostic so everyone can read them.

When you start seeing all the different tools that people use in the course of their research project, this concept of CAQDAS being a middle piece of the puzzle becomes really clear, and allowing people flexibility is really important. Developing CAQDAS software is a challenge, because everyone has slightly different needs. But the solution usually seems to be more ways in, and more ways out. That way people can rely on the software as little or as much as they like, and always find an easy way to integrate with all the tools in their workflow.

I was inspired to write this by reading a recent article on the Five-level QDA approach, written by Christine Silver and Nick Woolf. They outline a really strong ‘Analytic Planning Worksheet’ that is designed to get people to stop and break down their analytical tasks before they start coding, so that they can identify the best tools and process for each stage. This helps researchers create a customisable workflow for their projects, which they can use with trainers to identify which software is best for each step.

Next week, I’m going to write a blog post more specifically about the Five-level QDA, and pedagogical issues that the article raises about learning qualitative research software. Watch this space!

This week, something completely different! A guest blog from our own Kristin Schroeder!

Most of our blog is a serious and (hopefully) useful exploration of current topics in qualitative research and how to use Quirkos to help you with your research. However we thought it might be fun to share something a little different.

I first encountered qualitative research in a serious manner when I joined Quirkos in January this year, and to help me get up to speed I tried to code a few things to help me understand the software.
One of the texts I used was a chapter from The Lord of the Rings, because, I thought, with something I already know like the back of my hand I could concentrate on the mechanics of coding without being distracted too much by the content.

I chose ‘The Council of Elrond’ – one of the longest chapters in the book and one often derided for being little more than an extended information dump. Essentially lots and lots of characters (some of whom only appear in this one scene in the whole book) sit around and tell each other about stuff that happened much earlier. It’s probably not Tolkien’s finest writing, and I suppose, most modern editors would demand that all that verbal exposition should either be cut or converted into actual action chapters.

I have always loved the Council chapter, however, as to me it’s part of the fascinating backdrop of the Lord of the Rings. As Tolkien himself puts it in one of his Letters:

“Part of the attraction of the L.R. is, I think, due to the glimpses of a large history in the background: an attraction like that of viewing far off an unvisited island, or seeing the towers of a distant city gleaming in a sunlit mist.”

Of course, if you are a Tolkien fan(atic) you can go off and explore these unvisited islands and distant cities in the Silmarillion and the Histories of Middle Earth, and then bore your friends by smugly explaining all the fascinating First and Second Age references, and just why Elrond won’t accept an Oath from the Fellowship. (Yes, I am guilty of that…)

Looking at the chapter using Quirkos I expected to see bubbles growing around the exchange of news, around power and wisdom, and maybe to get some interesting overlap views on Frodo or Aragorn. However, the topic that surprised me most in this chapter in particular was Friendship.

I coded the topic ‘Friendship’ 29 times – as often as ‘Relaying News’ and ‘History’, and more often even than collective mentions of Elves (27), Humans (19) or the Black Riders (24).

The overlap view of ‘Friendship’ was especially unexpected:

The topics ‘Gandalf’ and ‘Friendship’ overlap 22 times, which is not totally surprising since Gandalf does most of the talking throughout the chapter, and he is the only character who knows everyone else in the Council already. But the second most frequent overlap is with Elrond: he intersects with Friendship eight times, which is more often than Frodo who only gets five overlaps with Friendship!

Like most of the Elves in Lord of the Rings, Elrond is rather aloof and even in his own council acts as a remote facilitator for the other characters. Yet, the cluster view on Friendship led me to reconsider his relationship not only with Gandalf (when Gandalf recites the Ring inscription in the Black Speech, he strongly presumes on Elrond’s friendship, and Elrond forgives him because of that friendship) but also with Bilbo.

Re-reading Elrond’s exchanges with Bilbo during the Council, I was struck by the gentle teasing apparent in the hobbit’s reminders of his need for lunch and Elrond’s requests that Bilbo should tell his story without too many embellishments and it need not be in verse. The friendship between Bilbo and Elrond also rather explains how Bilbo had the guts to compose and perform a song about Elrond’s father Eärendil in the previous chapter, something even Aragorn, Elrond’s foster son, described as a daring act.

Perhaps none of this is terribly surprising. Within the unfolding story of the Lord of the Rings, Bilbo has been living in Elrond’s house for 17 years - time enough even for busy Elflords to get to know their house guests. And for readers who grew up with the tale of The Hobbit, Bilbo’s centrality may also not be much of a surprise. For me, however, looking at the chapter using Quirkos opened up a rather pleasing new dimension and led me to reconsider a couple of beloved characters in a new light.

Engaging participants in the research process can be a valuable and insightful endeavour, leading to researchers addressing the right issues, and asking the right questions. Many funding boards in the UK (especially in health) make engaging with members of the public, or targets of the research a requirement in publicly funded research.

While there are similar obligations to provide dissemination and research outputs that are targeted at ‘lay’ members of the public, the engagement process usually ends in the planning stage. It is rare for researchers to have participants, or even major organisational stakeholders, become part of the analysis process, and use their interpretations to translate the data into meaningful findings.

With surprisingly little training, I believe that anyone can do qualitative analysis, and get engaged in actions like coding and topic discovery in qualitative data sets.

I’ve written about this before but earlier this year we actually had a chance to try this out with Quirkos. It was one of the main reasons we wanted to design new qualitative analysis software; existing solutions were too difficult to learn for non-expert researchers (and quite a lot of experienced experts too).

So when we did our research project on the Scottish Referendum, we invited all of the participants to come along to a series of workshops and try analysing the data themselves. Out of 12, only 3 actually came along, but none of these people had any experience of doing qualitative research before.

And they were great at it!

In a two hour session, respondents were given a quick overview of how to do coding in Quirkos (in just 15 minutes), and a basic framework of codes they could use to analyse the text. They were free to use these topics, or create their own as they wished – all 3 participants chose to add codes to the existing framework.

They were each given transcripts from someone else’s anonymised interview: as these were group sessions, we didn’t want people to be identified while coding their own transcript. Each were 30 minute interviews, around 5000 words in length. In the two hour session, all participants had coded one interview completely, and done most (or all) of the second. One participant was so engrossed in the process, he had to be sent home before he missed his dinner, but took a copy of Quirkos and the data home to keep working on his own computer.

The graph below shows how quickly the participants learnt how to code. The y axis shows the number of seconds between each ‘coding event’: every time someone coded a new piece of text (and numbered sequentially along the x axis). The time taken to code starts off high, with questions and missteps meaning each event takes a minute or more. However, the time between events quickly decreases, and in fact the average time for the respondents was to add a code every 20 seconds. This is after any gaps longer than 3 minutes have been removed – these are assumed to be breaks for tea or debate! Each user made at least 140 tags, assigning text to one or more categories.

So participants can be used as cheap labour to speed up or triangulate the coding process? Well, it can be more than this. The topics they chose to add to the framework (‘love of Scotland’, ‘anti-English feelings’, ‘Scottish Difference’) highlighted their own interpretations of the data, showing their own opinions and variations. It also prompted discussion with other coders, about what they thought about the views of people in the dataset, how they had interpreted the data:

“Suspicion, oh yeah, that’s negative trust. Love of Scotland, oh! I put anti-English feelings which is the opposite! Ours are like inverse pictures of each other’s!”

Yes: obviously we recorded and transcribed the discussions and reflections, and analysed them in Quirkos! And these revealed that people expressed familiar issues with reflexivity, reliability and process that could have come from experienced qualitative researchers:

“My view on what the categories mean or what the person is saying might change before the end, so I could have actually read the whole thing through before doing the comments”

“I started adding in categories, and then thinking, ooh, if I’d added that in earlier I could actually have tied it up to such-and-such comment”

“I thought that bit revealed a lot about her political beliefs, and I could feel my emotions entering into my judgement”

“I also didn’t want to leave any comment unclassified, but we could do, couldn’t we? That to me is about the mechanics of using the computer, ticky box thing.”

This is probably the most useful part of the project to a researcher: the input of participants can be used as stimulus for additional discussion and data collection, or to challenge the way researchers do their own coding. I found myself being challenged about how I had assigned codes to controversial topics, and researchers could use a more formal triangulation process to compare coding between researchers and participants, thus verifying themes, or identifying and challenging significant differences.

Obviously, this is a tiny experimental project, and the experience of 3 well educated, middle-class Scots should not be interpreted as meaning that anyone can (or would want to) do this kind of analysis. But I believe we should do try this kind of approach whenever it is appropriate. For most social research, the experts are the people who are always in the field – the participants who are living these lives every day.

You can download the full report, as well as the transcripts and coded data as a Quirkos file from http://www.quirkos.com/workshops/referendum/