Transforming Qualitative Data into Actionable Information

by Joshua Ledwell

­­Interviews and open-text survey questions are two common user research methods that often result in large amounts of qualitative data. Some UX practitioners don't know where to start analyzing all the notes and open-text answers their research generates. Others may accurately analyze the data, but the results may take too long to generate or they may result in no business value for their stakeholders. 

To speed up the analysis process, consider coding your survey responses, interview notes and transcripts. A coding scheme establishes a framework for analysis by organizing the information into categories most useful for the researchers. After exhaustively reviewing a set of interview notes about our engineering software, we induced this list of nine workflow-oriented codes. We successfully used the same coding scheme on later survey results and interviews.

Code	Description	Useful to
Followup	A customer question or issue that requires an answer.	Mark specific issues for a customer service response.
Key quote	The customer's words.	Use a quote to emphasize a point to stakeholders.
Other tool	Participant uses another product to get the job done.	Learn how others products fit into a customer’s overall workflow.
Pain point	Something the participant doesn't like about the software.	Examine these issues to find improvement ideas.
Positive	Something the participant likes.	These help balance a report that might otherwise contain all negatives.
Process	How customers use the software.	Validate assumptions about how your users work.
User	Information specific to a firm or participant.	Effectively, this category is a catch-all for data that’s interesting but probably not actionable.
Wishlist	Customer feature requests.	Don’t turn these directly into requirements. Analyze wishlist requests to ensure you understand the root customer need.
Workaround	To get the job done, participant is using the software in unintended fashion.	These point to missing, difficult to discover, or inadequate features.

Coding of qualitative data may take place in the moment, as a facilitator takes notes during an interview. The coding may also take place retrospectively when analyzing survey responses or transcripts. Either way, the strength of this simple coding scheme is speed. The facilitator can use written shorthand symbols or macro keyboard shortcuts to quickly mark each sentence or statement. A method we found successful was to break up passages of text into bullet points or paragraphs, then paste the text into Microsoft Excel. Each item becomes a single row that can be tagged in another column with one of the codes, then sorted and manipulated at will.

Sometimes a single customer statement may apply to two or more codes. In these cases it’s often best to break the statement into its coded pieces. For example, a customer may say “We use the color-coding filter to mark which user owns each part, but it really slows down the software.” In this case you have both a Process note and a Pain point to consider.

This coding framework is simple enough that a whole team can collaborate on the analysis. By distributing pieces of a large survey or several interview transcripts across team members, a large amount of data can be processed in a shorter period of time. However, note-taking shorthand, word choice and handwriting may be difficult for a separate coder to understand, so it is usually best to have the original facilitator code their own notes, or at least ensure they are available to clear up any potential ambiguity.

Fictional example of coded interview notes:

Code	Note
Other tool	Enterprise Customer A uses our widget along with paper documents.
User	They are currently using our older product and weighing the purchase of our new product.
Key quote	"Widgets are more useful than paper, but why are they slower to use?"
Pain point	Their widgets take too long to boot up in the morning.
Followup	How can they set up their widgets to start up faster?
Process	For their planned upgrade, they'll need to roll out the new widgets one office at a time. Some offices will have the old widgets for a long time.
Wishlist	Need to be able to take control of the widgets in an entire office over the network.
Workaround	They implemented user interface based on old paper forms, but on the widget they just skip the fields that they don't need.
Positive	They like the idea of the mobile widget project.

Once your qualitative data is coded, some of it may be actionable immediately, especially “Followups” and “Pain points”. Other feedback, such as “Wishlist” and “Workaround” items, may lead to valuable discussion and creative ideas about how to enhance the software. The remaining items may go into a report for stakeholders, or be used in a holistic affinity diagramming exercise.

A final note: Our team has found the coding scheme above useful, but practitioners should consider what framework will best meet the goals of their customer research. If your goal is to create user personas, for example, your coding should relate to the components of your personas. Now, code away and enjoy transforming all of that text into actionable next steps for your organization!

References

Patton, M. Q. (2002). Qualitative Research and Evaluation Methods (3rd ed.). Thousand Oaks, CA: Sage.

Strauss, A. & Corbin, J. (1990). Basics of Qualitative Research. Thousand Oaks, CA: Sage.

Thomas, D. R. (2006). A general inductive approach for qualitative data analysis. American Journal of Evaluation 27 (2), 237-246

Comments

[Kate Russell]

Great article, Josh! Thanks for taking the time to share what methods have been working with your team. Very good approach too!