What are the best practices for keeping and analyzing unstructured user feedback?

Question

To get and analyze users' feedback is vital for designing successful products as all of you perfectly know. It is more or less clear what to do with surveys' results, but what is the best way to keep results of interviews and unstructured user reports?

Shame but now I just keep feedback in a special mailbox and store interviews' summary in Notes. As a result, I create tickets in Jira after short analysis :) Previously when I had 3 more designers we used spreadsheets (excel, confluence, google sheets) but it takes too much time now when I'm the only designer (yet). The main issues with those approaches are:

• you can't really analyze anything (e.g. find alike or controversial things) in Notes and mail ))
• spreadsheets give some sort of analysis capabilities but it consumes too much time

Any hints on how to avoid spreadsheets? Thanks!

Answer 1

On the UX side I typically have the following principles:

• don't listen to the feedback, look at the problems users share
• listen to solutions offered but make sure that whatever is used follows the principles of the product goals
• organizer user feedback so each piece tells a complete story so the analysis is comprehensive

Putting my product management hat on, of also add:

• what kind of user is this (per analysis): uneducated, educated, or a power user?
• is the user right? Why or why not? And doors it matter?
• most importantly: what are the emotional decisions that led the user down this path, and are they similar or in-line with expectations? Why or why not?

Those principles have never steered me wrong. They're also time consuming, so if your company just wants to ship a product, best of luck conducting testing with these things in mind.

Answer 2

For me, it depends. I used to store all of my feedback so I could look for patterns, which helped me avoid catering to a squeaky wheel. However, doing so means that the feedback can sit somewhere, untriaged. I think not using feedback in the near future is worse than risking listening to one point that not everyone shares.

So now I tried to pull in some cross-discipline team members as soon as I get some feedback so we can quickly triage it: do something about it now or set it aside (and, realistically speaking, never look at it again).

If I can't or don't want to do that (e.g., it's not enough feedback to warrant bringing people together, or if I suspect the feedback is a one-off issue, or if I don't fully understand it and want to dig into that area deeper later), then I store it somewhere.

I used Excel for a while, but I didn't like that it was tough to share/collaborate with others on. Who had the latest file? Plus, Excel is very linear; you can't easily link a row about a piece of feedback to another row. And its text editing can be frustrating for large blobs of text.

So now I prefer to use task management systems (e.g., Jira) for the purpose of feedback storage. IMO, feedback is best stored in and retrieved from a database, and task management systems are essentially that. You can quickly create an item for a piece of feedback or an entire session, then link that feedback to other feedback items. You can create parent-child relationships, tag items for easier filtering, and it's easy to share these feedback items with others. What's nice is that usually someone else has already set up a task management system, complete with back ups. So it's usually just an issue of having an area of it designated for feedback, especially one where you can control access. Oh, and maybe creating a custom form that's better suited to feedback than a task, if your tool allows that.

I just switched jobs so I haven't suggested we do that yet (since task management systems are really meant for task management), so I'm currently experimenting with Sharepoint. Sharepoint lets you create Custom Lists, and each entry in that list can be defined with a custom form. It's stored on a server (backed up and secured), which allows me to share. I can filter the list view to see just stuff I want. However, Sharepoint doesn't handle cross-linking feedback points well, so we'll see how much I like it.

Answer 3

Keeping Feedback:

Probably Intercom - It's a great tool to manage all the feedback that comes in.

Analysing the data:

The problem with unstructured user feedback is that it's (mostly) qualitative, and the analysis of qualitative data is notoriously time-consuming. The most common method used for analyzing qualitative data is thematic analysis. It strives to identify patterns of themes (common stuff that people have said) in the feedback data.

If you're to read up about how it can be applied, you can read more here. It talks about the process in the context of user interviews, but the same principles should apply to user feedback as well.

Answer 4

From my experience, for in-person research, you should analyze the results of user interviews or tests as soon as possible, using the notes you took during these interviews/tests and revisiting audio or video records based on the notes. (It helps to annotate important notes with a time stamp.) You can link to summaries, notes, or recordings from the analysis itself if you ever need to revisit them, but you generally shouldn't need to.

As for user feedback that isn't given in person, that should probably be kept where it is until it's ready to be analyzed.