Comments on: A Story About a Crappy UX Study

By: James Skinner

James Skinner — Tue, 04 Sep 2012 15:25:21 +0000

Nothing quite as disheartening as a client who says “the users might have said that, but they’re wrong. I know what they want”. For me, the key is to spend a lot of time up front with the key stakeholders, and getting an impression of how genuinely they buy in to the whole process. If they don’t, bail.

By: Cindy Chiuchiolo

Cindy Chiuchiolo — Fri, 31 Aug 2012 18:37:26 +0000

I’m a usability recruiter, and part of my process is scheduling usability activities around the calendar of one developer (usually the lead dev). Also, one of the rules here is that if there isn’t at least one developer attending, the session doesn’t run. The theory behind me scheduling around one of their calendars is that at least one will show, but I know that making sure they attend still requires effort on the part of the usability specialists. I don’t know if that applies to even the smallest of phone interviews, but at least for a usability session with a prototype, there’s always a developer present here. Your story gives insight as to why we do things this way.

By: MsFlower

MsFlower — Tue, 28 Aug 2012 13:56:38 +0000

The product manager usually comes from all the walks. When the company don’t believe UX, usually most of them don’t, get to know the company and people better is the key before doing the research. In a real-life case, research results can be as dangerous as being against your shareholder’s idea and your colleague’s previous works, plus it’s not deliverable business. I bet people bitch about a researcher regarding their ‘invisible hard work’ as part of the office drama. So, research is good, timing is bad, cooperation needs more works.

By: Tomer Sharon

Tomer Sharon — Sat, 25 Aug 2012 00:33:30 +0000

Thanks for all of these great comments.

Erin: I’m not suggesting not to do research if nobody shows up. I’m saying it is more likely nobody would care about the results if that’s the case. One rare case is that the team trusts you so much that they don’t feel they need to attend. If you feel the same way, go for it. If that’s not the case, I highly recommend on having a serious, open conversation and try to agree that at least one-two team members attend sessions. Alternatively, you can schedule a workshop during which you show selected (longish) videos and have team members come to conclusions.

If there’s a will, there’s a way. I think Bill Clinton once said it about the peace process in the Middle East. So far, no will hence no way. I hope our stakeholders have will.

By: Alexis D

Alexis D — Fri, 24 Aug 2012 11:05:42 +0000

Interesting, and quite familiar. The flip side of involving product managers, owners, etc in the interviews, is again, they’re keen to be involved, but pick and choose which ones they come too. At the time of presenting the findings, the recommendations I made were either championed or knocked down based on the responses at the interview they attended. Still working on achieving that win-win situation… Thanks for your insight.

By: Rob Gillham

Rob Gillham — Tue, 21 Aug 2012 11:53:20 +0000

Very honest and revealing, thanks! Let’s face it, we’ve all been there…

By: Erin young

Erin young — Fri, 17 Aug 2012 00:41:33 +0000

I’m curious then, about a situation in which the team can’t be present. Perhaps they are handling others tasks or focused on other projects. Perhaps the expense of having ten people along for each interview is too great for a lean projwct to bear. Are you suggesting no research at all in that case?

By: dan turner

dan turner — Fri, 17 Aug 2012 00:17:02 +0000

I had a similar experience but in a different direction, in a way. Coming in on a project to adapt a quickly built web app for users in developing countries, I first put the existing site through a few rounds of standard user testing. I was looking forward to including the engineer who’d built and laid out the web app, but made sure to prep him about the usual “if you have a problem, it’s not you, it’s our design” talk we give to participants.

My concern was that if we just brought him the empirical results showing user confusion, etc., he’d see the UX process as just a black box that outputted “you did it wrong”. But after getting to see how users — that is, the people who did not actually build the site — react to the site, he was really excited about UX and put in extra time and effort as we moved forward in the larger project.

By: James

James — Thu, 16 Aug 2012 17:19:31 +0000

It seems like a pretty strange set-up where the Project Manager is producing the specification document. As UX designer, I see it as my job to take the research forward and turn it into a specification/brief that developers can work from. If I just presented my research to engineers I’d expect them to say ‘So what? What do you want me to do with that?’.

I also couldn’t imagine people arguing the toss about research methods and participants. That’s my area. I don’t tell the Project Manager that I’m unhappy with the margin or the developer that their code is crappy.

Overall, I’d say take the exact opposite away from your anecdote – it sounds like a classic case of too many cooks. I’d say you need less colloborative working and more people to sticking to what they’re good at.

By: Alex Sherman (@alex_sherman)

Alex Sherman (@alex_sherman) — Thu, 16 Aug 2012 17:13:35 +0000

Not all product managers act like this.