8 Reasons why you're doing it wrong
In the mid-1980's Microsoft produced the first version of Excel and now, over three decades later, it is an everyday part of office life. Its familiarity, flexibility and ubiquity means it's been pressed into use in a myriad of ways far beyond it's original spreadsheet roots (the Office 97 version even contained a flight simulator!). So, it seems only natural that people would turn to Excel as the tool of choice when coding verbatim data. What's wrong with that? Well, a few things as it happens which we'll have a look at in this article.
As an activity, Coding does not happen in isolation - it is part of the wider research process. Often coders will receive a set of verbatim data (usually as an Excel file) and set to work appending data to that file. Actually, this is pretty convenient for the coder, but stop and think for a minute about the process that has led up to this. Someone, somewhere has had to extract the data from their survey system, check it then email (email!) it over to you. They'll probably add password protection to the sheet while they're at it, then email the password to you. All of this is an unnecessary hassle for those involved. Oh, and when the coding is done, the same hassle is repeated again, in reverse.
No, not the name of a particularly slow attorneys practice - this refers to the fact that Coding is usually performed post-hoc, once all the fieldwork is done. Usually this is because of the hassle involved in assembling the data for Coding (see above) - it's usually too much hassle to extract the data repeatedly during fieldwork so people tend to wait until all the data is collected before starting to code. This creates an in-built lag in the research process, meaning the coded data often arrives days or weeks after the closed-end data is already analysed and ready for reporting.
What happens if you want multiple people to work on your Coding simultaneously? Perhaps you're in a hurry and you need lots of people to work on the data to get it done quickly. Or perhaps, your data is multilingual so you need different people to work on different languages? Whatever your reason you'll find it hard to achieve using Excel. You'll probably end up manually splitting the file into separate files and sharing the data that way. Suddenly, all the hassles above have been multiplied.
One of best things about Excel is also one of it's biggest weaknesses. It's completely generic, which means there's few restrictions on what you can do with it. When you're Coding, this is sometimes a bad thing. For example, you're only ever one misplaced sort away from completely mangling your data (yes, we've seen this happen). There's also nothing stopping you from tagging the data with invalid codes - e.g. codes that don't exist in your codeframe - without Excel complaining.
This isn't Excel's fault, but ultimately it's a spreadsheet tool so it isn't optimised to the task of Coding. There are many actions, such as searching, filtering, text matching, codeframe editing, etc... that are faster and smoother in a tool that's fine-tuned to the process of Coding.
In our experience, when you use a tool that's matched to the needs of real-world coders, then it makes a significant difference to the speed and productivity of your coders.
If you have data from a looped question, or a grid, then it's necessary to flatten that data into the 2-dimensional layout of rows and columns in Excel. This can get messy very fast. It can be hard to see how the data ties up which slows you down and can make the whole thing even more error prone (see above).
Oh, and if your data is multicoded, that introduces another level of complication which can make the layout even worse. It's no fun working in an Excel file with a layout as complicated as that!
Abiding by today's standards for data security is difficult when managing multiple verbatim files contained in Excel or any other general purpose application. A purpose-built verbatim coding and management application will provide secure access to any survey data by only those staff members with the appropriate credentials. Verbatim coding is commonly carried out by people working remotely and project suprevisors require tools to both manage the productivity of the coders and to safeguard the clients' data.
As the saying goes, "those who don't learn from history are doomed to repeat it". When your data is siloed in Excel spreadsheets, it makes it very hard to reuse the work from previous coding in new coding projects. So, if you're not careful, you end up having to code the same, or similar, items over and over again unnecessarily. Smart coding tools will learn, automatically, from your coding work and allow you to reuse and share that learning on new projects.
If you're interested in knowing more about how codeit can help you avoid all of these pitfalls, get in touch and we'll show you.
We will not share your information with any third parties
Try it for Free
Anything we can help you with? Ask us