My dissertation is the first project I’ve done involving qualitative analysis of data – specifically, the coding and analysis of 30+ student interviews. So when it came time to choose a program with which to do all that analysis, I felt somewhat at a loss. I’d had a few recommendations from fellow grads and professors, but since I’m A) a Mac user and B) on a pretty tight budget, I found none of the recommendations fit my practical limitations. On top of that, trying to understand the features and capabilities of all the available choices was pretty intimidating, since I was working on so little experience. I worked up a lot of anxiety, not just about making the choice but about what would come afterwards as well.
On the advice of my adviser, I checked out Dedoose, a web-based program that charges per month, rather than a one-time license fee. These features, combined with a reputation for strong customer support and an intuitive, well-designed interface, struck me as a good fit for me and my project – so I went for it.
Once I decided on Dedoose, getting started was kind of exciting. The program was as intuitive as promised, and it felt good to arrange all the data I’d so painstakingly collected and transcribed into the project space. I was happy to find that many of the features promised were indeed as easy to figure out as I’d hoped, and it took only one day to upload and organize all my existing data. There were a few snags – for example, the system for categorizing data files proved difficult to understand even after repeatedly consulting the support documents – but overall, it seemed like the anxiety I’d developed about working with an analysis program during my selection process were unfounded.
The first stage of coding went fine – even great – with Dedoose’s excellent customer support on full display. Just a few weeks before, at the suggestion of another grounded theory user like myself, Dedoose had added a coding widget designed to facilitate line-by-line coding and other methods where codes are generated from the data, rather than applied to it. The widget worked like magic – line by line coding was now incredibly simple, and I was able to focus on thinking about what I saw and how best to describe it. For the first month using Dedoose, I felt back-pattingly good about my choice of program.
It wasn’t until I got elbows-deep in the coding process that the drawbacks of Dedoose for my methods started to present themselves. Turns out, while Dedoose makes initial coding a piece of cake, it has very little support for turning those initial codes into more focused sets. During my initial coding phase, I generated 195 codes – a lot, yes, but not out of proportion with the 30+ interviews I conducted. To progress to focused coding, I wanted to slot these initial codes into four “trees,” then look at which interviews and terms showed up most across the codes in those trees. But Dedoose’s interface is extremely unfriendly to this kind of sorting. The only way to place codes into trees is through drag-and-drop using this list interface. Since the interface displays only 1/5 of my codes at a time, dragging and dropping is a very slow, incredibly tedious process. So tedious, in fact, that despite starting it more than a month ago I’ve yet to finish; I keep finding as many ways as possible to work on the project without having finished the coding process.
This wasn’t something I had even thought to look into when I was selecting a program. Since grounded theory is a relatively common choice for qualitative data projects, it hadn’t occurred to me that support for its sprawling and relatively disorganized initial coding stage might be something I needed to look for specifically. It made me feel somewhat naive – but also a little wiser. Next time I choose a program for data analysis, or give advice to someone on doing so (like now!), I know to emphasize a close look at tools for coding. I knew going into my selection that coding tools were the major use I’d be putting to use, but I was too impatient to get going and too new to the process to know exactly what to look for – or, looked at another way, how to adapt my methods to the tools I’d chosen.
The shape of a project should guide the selection of tools, it’s true. But given my hardware and financial limitations, I didn’t have a wide range of choices available to me; from a practical standpoint, Dedoose was the clear choice. So the lesson I learned here is that sometimes, the project should (at least to some degree) follow from the tools available. For now though, I’m stuck with the project I’ve got – which reminds me: I’ve got some coding to do.
6 Comments
Are there other tools like Dedoose that you might also recommend? I’m trying to find a tool that can analyze data from a variety of sources – qualitative and quantitative – such as interviews, surveys, social media, reviews, etc.
Thanks for sharing your experiences. I am also doing qualitative researcher, also new to research, and a Mac user, and on a tight budget. And most of what I’ve read has pointed me towards Dedoose, but like you, I have a huge amount of interview data to code and analyse (3 case studies, 20-30 i/vs in each), so the issues you raise are incredibly valuable to be reading at this time.
Knowing what you know now, do you think you could have approached the initial coding process differently, in order to facilitate the focused coding stage? And being a few months further along in your project when you wrote this post, would you use Dedoose again? Thanks for any further thoughts you can share!
Glad to hear this was useful to you! If I had the initial coding to do again, I think I would have tried harder to think about using the same codes repeatedly from an earlier stage; Dedoose just cannot support organizing true “open” initial coding into something focused without insane amounts of tedious effort, and so I’d have modified my approach to start thinking about what trees I wanted earlier. I’d also have been more conscientious about using the exact same wording for codes wherever possible – rather than being a little sloppy/overspecific and using, say, both “deterred by frustrations with interface” and “mentions interface difficulties as deterrent.”
As to whether I’d use Dedoose again if I had it to do over – well, yes. In part because of its strengths, but honestly even more because I still don’t know of a better alternative.
Thanks Becca! really helpful. I think I’ll sign up for my free month and see how I go (if I stay in the hunt for the perfect tool, I might find I never get started coding anything). Cheers!
Hi Becca,
It think you’ve started a very important conversation here. At Dedoose we fully appreciate workflow challenges and are always working to increase efficiency. Your code tree management concerns are valid and something we are already thinking about in terms of how we can ease the process. For you and any others, we are always happy to hear about suggestions in what improvements might look like. A great example is the quick code widget which greatly smoothed work-flow in excerpting and coding and, indeed, was designed by a Dedoose user. The evolution of a code system is a more unwieldy process to streamline within an application. Landscape is limited, there is no limit to the number of codes that can be created, and the merging or deleting of codes are important code-by-code decisions. Thus, we’ve yet to wrap our heads around how to design useful modifications and functionality. We are wide open to suggestions and, sometimes it can, indeed, be more efficient to consider some broader stable categories as initial codes and then build in more nuance as you become more familiar with your data and what will ultimately become important sub codes.
Carry on and we’ll be here to offer all we can,
Eli
Wouldn’t it be possible to export your codes in an excel file, alter there, and then import in the newly sorted and nested order you want?