18

I'm in the middle of a UX project, including on-site user tests.

Colleagues are drip-feeding me ideas / suggestions / feedback etc from random users that I haven't tested.

In some ways it's fair enough - they want me to have all the facts at my fingertips. Some of the feedback is helpful, and I feel like I shouldn't ignore it.

On the other hand, it's totally unstructured and completely removed from the UX process - for example, I haven't met these users, I don't know much or anything about them, I don't fully understand their goals, etc.

Should I take this feedback, collate it and work with it as best I can or should I politely say that I can't take it into account and just stick to the structured UX process I'm going through?

  • Thanks for both answers so far - they confirmed my instincts and added some useful advice. – Tom H Feb 23 '15 at 14:41
  • No problem. Best of luck! – Majo0od Feb 23 '15 at 15:15
  • 1
    A couple more really helpful answers - thanks all. (Ken, I found that article from the MailChimp guy this morning while Googling the issue.) My solution was to thank colleagues for feedback so far, and encourage them to keep it coming. I then included a bit of 'awareness-raising' about the UX project (it's a new concept for most people here!) and said that, while I'm grateful for all feedback, it's not the same as user testing etc, and I would put it to one side for the time being / review it later as a means of corroborating/contradicting my findings. – Tom H Feb 23 '15 at 17:06
  • ... also as a possible way of suggesting things that you might want to concentrate on in testing. I.e. if more than one piece of informal feedback suggests there might be a problem with a specific area then you could give that area extra attention as part of your structured process. – A E Feb 24 '15 at 10:30
17

You don’t know the weight of this information or how to compare it to other data. From that perspective it is useless for your own research. But don’t throw it away, it is still real feedback so better take it seriously. Once you’ve gathered your own data, don’t mix it up with this low quality feedback but use it to see if there are similarities.

The reason you want to keep this feedback is that you can use it in presentations to promote your ideas. Using real world examples that your colleagues will recognize is good to create a support base.

If there are contradictions between your own data and the feedback, find out if it was the feedback or the research that wasn't accurate.

6

It seems to me that a bug tracking or issue tracking tool (i.e. JIRA, Bugzilla, YouTrack) could help here, especially if the colleagues can create issues there directly (and not have to route through you). You can create a sprint or category called Backlog or Archive or Attic. You can capture any and all feedback there, but cherry pick issues and move them to "real" versions as they match your structured process.

  • 1
    This is how I've done it (mostly). It's a customer service function, the record of which should be available to multiple departments via your org's choice of distribution. Forwarding things via email to whatever dept occurs to the sender is a recipe for failed communication. – plainclothes Feb 23 '15 at 18:25
3

I think you should do two things:

  1. Tell them to not send feedback every so often, because that interrupts the design process, much like it does for me at work. I get something done, then another "requirement" springs in. The design changes almost entirely to accommodate the newly found "requirement." If they want to send feedback, let them do it in an ordered fashion (even before you start work).
  2. Get them to give you some context to the tests. Context is important: for instance if they send you details about a user who wasn't using your software properly without the age, then that doesn't help at all. If the user was old and didn't care for technology, that says a lot.

Build structure with them, tell them that you need all requirements before hand, because this trend keeps going if it isn't stopped in the beginning.

If something is sent in a vague fashion, ask for more details. Ask for context and more details. If they don't know, then the data is unreliable. Unreliable data is just as bad as not having any data to begin with (because you can't really do anything with it).

Good luck. I know the frustrations all too well.

  • I wish I could give you +100 for the mid-project, knee-jerk changes! I hear ya! – AaronD Feb 23 '15 at 17:02
  • Oh God yes... It's really annoying. – Majo0od Feb 23 '15 at 20:15
3

Collecting knowledge is extremely important. Keep that barrier to entry low. It is a good thing to get data like this without friction. Unless you don't want the information, I would discourage you from telling people not to send or limit their sending. The issue is how do you manage the aggregated data efficiently.

Data is a good thing, but only if you can analyze it. Also having an healthy feedback channel is an advantage. This establishes a dialog and communication within your organization - something to be nurtured.

Aaron Walter, Director of UX for MailChimp had a similar problem and wrote about on a List Apart back in Aug of 2013.

He basically found the best way for his organization to make the information searchable and organized. I recommend you attempt the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.