Well, of course, all researchers will use some software. But should you use one of the specialist packages for qualitative work? (I refer to these products simply as ‘qualitative software’ or as QDAS (Qualitative Data Analysis Software. They also carry the acronym CAQDAS which I avoid because in Australian slang, if something is ‘cactus’ it’s dead – and QDA software is certainly not dead. ) 

Before taking that step, seriously reflect on the other ways you use computers, for communicating, reflecting, reporting, searching and exploring. These are the tasks associated with qualitative analysis. Do some thinking about which of these tools please you and help you, which extend your skills, and which impede your life and work.  Approach the specialist software in this context. Do you need them?  Do these packages offer to improve or impede your knowledge of data and your ability to explore data records and see patterns and meanings? Check out the comments on this site, as the contributors reflect back on their use of software. If you are new to specialist software, or concerned about the effects on your research, talk to others who have used it.

The qualitative software packages are usually designed to provide a safe container for all your data records and thinking about them.  By working with a qualitative software package you work within that container. For most users, data records or summaries of them have to be ‘in’ the program before they can be explored and analysed.  This makes the learning process more challenging for many researchers, as they can’t get started until they can manage the software, and often then feel distanced from their project once it is ‘in’ software they are still learning.

This is in sharp contrast with how, these days, all researchers manage their personal and professional data electronically, in a wide range of apps and packages, moving freely between them.  So the first advice is: don’t feel constrained to the stable of specialized qualitative computing tools. To explore the range of digital tools that may be familiar and useful, go to Paulus et al (2014).

Most qualitative researchers now use some specialist software, and most probably should. My exception to this assumption used to be researchers who are incompetent on computers and/or terrified of them. But it’s now very hard to be there and still researching. If you don't come into that category, it's highly likely that there is software that would help your research greatly, save you an extraordinary amount of time and allow you to do things with your data that couldn't be done manually. So long as you learn it and use it well.

But there’s the rub. Learning can be a long and infuriating process, especially if you start learning after your data records are building up. And using these software packages well is not the experience of many, even most users. The following pages are designed to help you approach the packages informed, and get to use them well.

A stranger to the early stable of qualitative computing programs (1980-2000) would be struck first by their similarity. These days, they are less alike. Most still contain a project within the software, and almost all to some extent rely on coding and retrieval of coded passages, but there is far more variety in the tools offered to the researcher. This variety is highly welcome: qualitative research has always contained a wondrously wide range of methods for making, handling and making sense of qualitative data.

QDA software is still less varied than our methods, and also less debated. It’s now normal for qualitative research, so not questioned. Site licensing means that many, even the majority of institution-based researchers have no effective choice of program, so miss the step of asking whether the licensed product actually does what they want it to do. The vast majority of advice for using software tools is written by their developers or by those who make a living teaching the package – so there is always a marketing purpose in such materials

There have also been few systematic and critical comparisons of the different effects of different products. Available online is an important though now outdated special issue of the Forum: Qualitative Research (FQS) Vol. 12, No. 1 (2011), from an experiment in 2010 known as the KWALON conference, in which developers reported analysis of a common provided database using their particular software. It’s a useful read, especially if read critically.

There have been even fewer discussions of the impact of using any from this stable of packages on your research. An earlier issue of FQS (Vol. 3 No. 2, 2002) provides one of the best collections of thoughtful articles. There have been some scholarly attempts to critique the efficacy of different packages in particular research settings, e.g., by MacMillan (2005) in FQS (Volume 6, No. 3)  on use of software for discourse analysis.

This book, and my previous book with Janice Morse, Readme First, attempts to fill some of these gaps. Throughout both, you are urged to think critically about whether you use software and what package you use, and consider not only the advantages but also the perils of using it.  A careful summary under three headings – approaches, advances and  alerts – ends each of the central chapters in Readme First: these summaries are provided on the website for Readme First.

In this situation how are you to find impartial, useful and non-marketing advice comparing software products?

The CAQDAS project  at the University of Surrey is funded to provide an up to date (and regularly updated) overview of the current programs available, with discussions and links to developer sites. You will find on the CAQDAS site detailed advice, with a review of each package, for choosing a software package.

The only current authoritative overview book, Using Software in Qualitative Research: A Step-by-Step Guide, was written by the CAQDAS project's experts, Ann Lewins and Christina Silver, in 2007. It is now in a second edition. On the associated website are detailed illustrations and case studies, along with step by step tutorials provided by all but one of the developers. Note these resources are from 2014.

More recent brief booklength introductions to some packages are provided by a consultancy group started by Christina Silver and gathering consultants familiar with the range of CAQDAS software, QDAServices. On their website are videos teaching their ‘five-level’ introductions to three products, and  books are available on these three.

Once you have explored the range of software available and made a choice, always go to the developer's site. This is as essential as is meeting the owner before you buy a dog. You need to learn not just about the software but about the people and commercial bodies producing, documenting, selling, marketing, supporting and upgrading it.

Several sites provide more extensive lists of currently available products that may be more relevant to your work than those in the CAQDAS stable, with comments and contact details for developers. At the time of writing, this is a comprehensive and updated list of programs for qualitative analysis. 

• Read the material on the CAQDAS site and the developer’s website to find what the software is designed for. (Are its tools relevant to your work?) Do a quick qualitative analysis of the text on their website: is this pertinent and sensible information or is it marketing hype? What does the software actually do and what doesn’t it do? (If you can't work this out from the website, worry. Maybe they don't want you to know?)
• Download free software and use it! (No free trial software? Ask, and if it's not available, go elsewhere. This may be exciting software in the future but it's not safe to commit your project to it.)
• Most sites have tutorials available online. This is by far the best way of getting a feel for what it would be like to work in that software. The tutorial should let you actually do something in the software, preferably a lot, following clear instructions, using free downloaded software. (If they don't offer a free detailed tutorial, ask for one. If they are charging money for help that should be free, or if you can't learn enough from the online free resources, beware!)
• If the developers have an online blog or discussion, join it and listen in. Is this a buzz of interesting research discussion or a litany of complaints? Do the developers contribute and does it sound as though they know about qualitative research and actually like to talk with researchers? (If not, they are not likely to be producing software that does what researchers are trying to do.) Does it sound as though people get into trouble with this product, and if they do, do they get helped? Really helped? Still unsure? Ask the contributors to the discussion list.

OK, you have chosen software (or had it chosen for you). Now what?

It's highly unlikely that you will find everything you need to do with that software package just by clicking around. It has to be learned, and the sooner you learn it the better. But you can choose how you learn it. There are many ways to learn software and nobody should tell you what will work best for you. You probably know how you like to learn. Alone or with workshop instruction? At your own pace or paced by a tutor? Playing with it or studiously doing something useful?

You may be helped by the reflections about the learner’s experience, and observations by trainers of their problems, provided on the website for Readme First.

There are – in person or online – courses in most products (many cost serious money). Think before you enrol in one. How big is this course, how relevant will it be to your work, how much individual attention will you get if you're stuck? Check out the tutor and their abilities; do they actually do research? (If not, will they be able to relate to the research goals you have?) For some researchers workshops fast track confidence, for others they sap it. Perhaps you'd do better quietly exploring tasks with a manual or a tutorial beside you. Or it may help to sit beside someone skilled in the software you are going to use and watch how they work.

But do learn it, and get to know this package before you put it to use. The best advice is to set out on some software learning task. You might use pilot or trial data (some developers provide this on their websites) in advance of starting your precious project in software.  Or explore by putting your project proposal and literature review into the software. But do some learning before you trial it with your ‘real’ data.  If you let learning happen (or not) as you work in your own data, you are likely to damage the data and end up hating (and blaming) the software. You will also learn only the software functions that do what you were doing without software (since these are the only tools you'll know to look for). At the end of the project, it's very frustrating to find that you could have asked quite different questions and made quite different discoveries had you known the software could support different ways of exploring and discovering.

Note that you don’t have to be stuck with one program. Especially if your institution has a site license, it’s tempting to accept this is the software you will use. But there is now a means of importing and exporting data from all major QDAS programs. Check out REFI-QDA exchange standard if you decide you should change horses in midstream!

Once you've decided about products, and once you have learned what tools are offered by the software and you can use them fairly competently – use it. You'll forget what you've learned if you don't try to use it for your purposes. It is essential to have the software working for you, in your project.

The next section offers a quick online guide to ‘Stepping into Software’ – loosely following the chapters of Handling Qualitative Data. It aims to get you up and running in any of the software products whilst focusing on your own project. For each step, the advice takes you through two sets of questions. What to ask about your project? And what needs to be done now?

It's important to ensure that what you do is directed by your method and goals, not by the software. Any sophisticated software will offer tools to do far more than you – in this or any future project – will ever want to do. If you try to do everything it supports, and invent a reason for doing it in your project, the task will become impossible and (much worse!) the project will lose its purpose.

There will also be some processes for which software doesn't offer a tool – for example, thinking. Don't assume that if something can't be done in software it shouldn't be done.

And finally, a more general warning. It's increasingly common for researchers to learn qualitative software without first learning about qualitative methods. To do so is not wrong or immoral, but it does add massive challenges as they start to use the software tools. Like any powerful tool (think of the chainsaw), qualitative software can be easily used to make dramatic and unintended changes. If the operator is unsure why this matters, serious damage can result. More importantly, like any tool, its power is wasted if the user cannot understand the purposes to which it can be put.

The most common result of researchers learning software without method is that they do very little with the software, reaching only for the most obvious processes, like coding, and continuing in them ritualistically. You can code for ever and the software won't stop you. You have to know the purpose of coding, in your project, to design your codes and coding to that purpose.  Starting a qualitative project can be daunting, even if you are not also starting with a software package. If you have no training in qualitative research, but confront the need to make sense of your data, please start there, with the skills taught in Handling Qualitative Data, not with a software product. Why are you doing this project, and what outcome are you seeking? Now – can software help? 

Go to the CAQDAS site for current lists of software and links to their sites. 

Lewins, A. & Silver, C. (2014) Using Software in Qualitative Research: A Step-by-Step Guide, 2e. London: SAGE. Visit the associated website for guides – at that date – to individual programs.

Tutorials and information are available at Qualitative Data Analysis Services, an independent consultancy service across all QDAS. This team has recently published books, with Routledge, so far on three programs, and the site offers video tutorials on those programs and blog posts about developments.    

Friese, S. (2019) Qualitative Data Analysis with ATLAS.ti, 3e. London: SAGE.  See especially Chapter 7: Recognizing and visualizing relationships - working with networks. Online resources on data visualization here.

Jackson, K. & Bazeley, P. (2019) Qualitative Data Analysis with NVivo, 3e. London: SAGE.

Kuckartz, U., Rädiker, S. (2020) Analyzing Qualitative Data with MAXQDA. Text, Audio, and Video. Switzerland: Springer Nature.

Salmona, M., Lieber, E. and Kaczynski, D. (2019) Qualitative and Mixed Methods Data Analysis Using Dedoose. A Practical Approach for Research Across the Social Sciences. London: SAGE.

Paulus, T., Lester, J.N. and Dempster, P. (2014) Digital Tools for Qualitative Research. London: SAGE.

‘The KWALON Experiment: Discussions on Qualitative Data Analysis Software by Developers and Users.’ Special issue of the Forum: Qualitative Research (FQS) Vol. 12, No. 1 (2011)

Several universities offer comparisons:

• Johns Hopkins Sheridan Libraries: Qualitative Data Analysis Software – a video is included
• New York University Libraries: Choosing QDA Software
• BU TechWeb: Qualitative Data Analysis Software Comparison
• GMU Universities Libraries: Qualitative Research & Tools

And if you made the wrong choice? Check out the process of transferring a project between software packages here:

• Evers, J., Caprioli, M. U., Nöst, S. & Wiedemann, G. (2020). ‘What is the REFI-QDA Standard: Experimenting With the Transfer of Analyzed Research Projects Between QDA Software.’ Forum: Qualitative Social Research, 21(2), Art. 22