All right. I'll bite. But rant first: Even though I understand exactly what people mean when they say "don't listen to your customers" or "don't pay attention to what users say, pay attention to what they do," these things irk the hell out of me. Of course you should listen to your customers--as you should listen to your kids, and your pets, and your friends, and your enemies, and everyone and everything that has the ability to express itself. Duh!
But listening to your customers is not the same thing as listening to your parents when you're 5 years old. You don't have to do what they say, just because they say so. So to begin with, it would make sense to ask people only for information you actually are going to want to listen to. (I don't ask my cat whether he wants his flea medicine; I do ask, in one way or another, whether he prefers the beef-goop or the salmon-goop that comes out of the can of cat food.) Okay, now that I've got that off my chest ... your post actually brings up a great question about what kind of research will get you what kind of results. For instance, testing prototypes is not a good way to suss out what (small?) percentage of people is going to do something like write reviews, tag their expenses, or do some other "power user" type of thing which demands a lot more dedication than the average user would bring to it. That requires a different (and likely more quantitative) type of research. To run a useful study on such prototypes, you'd want to make sure you have figured out what kinds of people are the most likely to do power-X and then recruit _them_. This might mean recruiting for people who study and analyze and dissect their quarterly credit card expense breakdowns. Or, frankly, the people who tag their expenses on Wesabe and Mint. If _they_ don't like the functionality you're building, then you should wonder whether you're doing the right thing. In short, absolutely listen to your customers, but only the right ones responding to the right questions. marijke John said >For us in the IxD arena when we're trying to create something unique and >something innovative we press ahead with the development of prototypes and >visuals that may reflect an interface and design that doesn't reflect where >our users are today and, because they've not seen the insight we might have >done, simply don't get why they'd need it. A case in point: a piece of work >I've been involved with presented the idea that banking customers could tag >transactions in their account - customers didn't get it: "why would I do >that" . but we know from Mint [3], Wesabe [4] and others that people do use >this feature. The problem being that the client has heard too many users in >testing being dismissive about the idea and therefore increasingly thinks >it's a waste of time. Granted, we could have fleshed out the prototype with >'why would I do this' type content and is this the failing here or simply >that users don't always know best? ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
