"A database might give some people a false sense that they can count things that shouldn't be counted," says Anne McClard, Senior Researcher with market research company Doxus.

The purpose of building a database with qualitative data is not to quantify data, but to manage it so that it is easier to analyze and more useful to the researcher and the client. But once the database is built, you risk the temptation to quantify it.

On the other hand, building a database to analyze qualitative data by different segments makes the research much more useful than the seat-of-the-pants approach that is often used in market research, that of combing through transcripts looking for answers.

For example, last year McClard worked with Shauna Pettit-Brown of Intel on a research project to understand the needs of mobile application developers throughout the world.

Intel needed to be able to analyze the data from several different angles, including segment and geography, a daunting task complicated by the number of interviews, interviewers, and world languages.

"The interviews were about an hour long, and pretty substantial," McClard says. So, she needed to build a database to organize the transcripts in a way that made sense.

We talked with McClard about this project and how to build a research database from scratch, whether the research is coming from focus groups, one-to-one interviews, blogs, email threads, or any other form of data collection.

Steps to building a database:

-> Step #1. Choose your software

Although there are many specialized research analysis software packages available on the market, surprisingly McClard's advice is to use very basic tools.

In her case, she sticks with Microsoft Access, because it's something that most companies already have. Excel works, too, she says, but isn't quite as flexible.

One can streamline the process by using the same software for all aspects of the project. "Our screening process for recruiting is separate from the research process, and often we have to merge data into the database from several different formats," says McClard.

In the case of the Intel project the recruiters used Excel and the layout of the grids was different in each recruiting field, she says, "So in this case, we had some problems in getting all the data to match up between the screening data and actual participants, getting it all to merge."

-> Step #2. Decide if you'll build the database in advance or after data collection

Pros and cons of building in advance:

When you have a process that's highly structured with very specific questions -- and if you have the ability to take notes as you interview -- building a database in advance of the project can be useful.

"Look at the interview guide and chunk the data in a way that makes it easy to enter into the database," says McClard. "Doing it in advance provides clear structure for the people taking notes, because if you're taking notes freeform, you don't always know what's important, especially if you have not been involved in the project all along."

By having a database, the categories of importance are right there. "It also makes the entry of predictable and discreet responses faster," she says. For example, with the Intel project, McClard had pull-down menus of all programming languages, which made for faster entry and faster tallying.

On the other hand, says McClard, "You almost always have to redesign the database on the fly. The database practically never fits the research purpose perfectly, so you have to make some tweaks to it."

Pros and cons of building after data collection:

More often than not, this is how databases for research projects are built, McClard says. Doing it this way gives researchers greater control over the design of the database, the categories can be more specific, and you're less likely to try to predefine what the categories will be.

However, this can be more tedious when it comes to transfer of the data, and it adds time to the project.

With the Intel project, there wasn't enough lead time to put together a database in advance and with several different languages that would have been even more difficult.

(In other respects, McClard says, the study would have been well suited to having had the database prepared in advance, since the interviewers could have entered their phone notes directly into the database.)

-> Step #3. Organize the database

Consider the fields you'll need in order to answer your research questions and begin organizing the database in that way (this might be simply creating fields based on the exact questions you asked or will be asking).

Then look for patterns in the data itself that might naturally emerge and make them into their own categories. After that, says McClard, she simply begins cutting and pasting the data. As you enter data you'll begin to improve upon the database and you'll find it getting more and more structured.

-> Step #4. Organize for different groups within your company

Different types of data are useful for different departments within a company; once your database is organized you can sort it by various threads.

The Intel study had three different internal sponsors. "When it came to doing the analysis, we ended up creating multiple versions of the presentation targeted to individual audiences," Pettit-Brown says.

The database enabled her to go back into the data set to answer questions specific to the interests of the three different groups.

Finally, says McClard, be open-minded when you're putting together the database. "Often," she says, "when I come out of the field I have certain impressions of what happened. But a lot of times when I put them all into the database, I find that I'm really off base."