4 ms·

One thing I've learned is that the user's complaint is always valid, the user's proposals seldom are. That is to say, users know when they don't like something

One thing I've learned is that the user's complaint is always valid, the user's proposals seldom are. That is to say, users know when they don't like something, but they are often wrong about why they dislike it or what is interrupting their workflow. Our job is to find and fix the root cause starting from user feedback, and fix the product in accordance to what the user is actually trying to accomplish. This is often very hard

Gary404 9y ago
Exactly this. What I used to do is listen to the user's proposal and go build that. 80% of the time it's not the correct thing to work on. I know spend much more time talking with users about their problems/pains, and then use metrics to figure out what they are trying to do. The combination of these two + a good set of eyes will point you in the right direction. Very very hard to do, but it's at least a leap better from my previous approach.
milesvp 9y ago
What's interesting about this, is that user complaints can be suspect too. I read an anecdote recently about the American auto industry. They'd ask people about what they didn't like about the cars they bought. And they'd get all these complaints, then try to build cars based on those complaints. The problem was, many of the complaints were for things that took them out of the market for the car they bought. For instance, people who bought sports cars would complain about lack of doors, or lack of back seat, and so GM or Ford would build a car that wasn't quite a sports car, because it was too big, and it wasn't quite a sedan (for whatever reason, too sporty? whatever that means?), and so no one bought it. I honestly don't know what the solution to this problem is, since feedback is invaluable. I guess, always be careful?
- stevekemp 9y ago
  I'm suddenly reminded of the car that Homer built: http://simpsons.wikia.com/wiki/The_Homer http://simpsons.wikia.com/wiki/The_Homer I suspect there is a lesson there about using aggregate feedback, rather than listening to single individuals.
WillReplyfFood 9y ago
Classic case- ui-paradigm shift in the middle of the programm- for once the right click does not present options - but does something else entirely that undoes work. Its strange- but usually this is found on components that had a developer-UI attached to it and where stand alone. Its easy to craft a pre-mature UI-decision into the working of a component- and run out of time for a redesign. Another classic there- you have a UI and suddenly it gets terminal- as in you have to enter commandline shortkeys to archive efficient workspeed with it.

Gary404 9y ago

Exactly this. What I used to do is listen to the user's proposal and go build that. 80% of the time it's not the correct thing to work on. I know spend much more time talking with users about their problems/pains, and then use metrics to figure out what they are trying to do. The combination of these two + a good set of eyes will point you in the right direction. Very very hard to do, but it's at least a leap better from my previous approach.

milesvp 9y ago

What's interesting about this, is that user complaints can be suspect too. I read an anecdote recently about the American auto industry. They'd ask people about what they didn't like about the cars they bought. And they'd get all these complaints, then try to build cars based on those complaints. The problem was, many of the complaints were for things that took them out of the market for the car they bought. For instance, people who bought sports cars would complain about lack of doors, or lack of back seat, and so GM or Ford would build a car that wasn't quite a sports car, because it was too big, and it wasn't quite a sedan (for whatever reason, too sporty? whatever that means?), and so no one bought it. I honestly don't know what the solution to this problem is, since feedback is invaluable. I guess, always be careful?

stevekemp 9y ago
I'm suddenly reminded of the car that Homer built: http://simpsons.wikia.com/wiki/The_Homer http://simpsons.wikia.com/wiki/The_Homer I suspect there is a lesson there about using aggregate feedback, rather than listening to single individuals.

WillReplyfFood 9y ago

Classic case- ui-paradigm shift in the middle of the programm- for once the right click does not present options - but does something else entirely that undoes work. Its strange- but usually this is found on components that had a developer-UI attached to it and where stand alone. Its easy to craft a pre-mature UI-decision into the working of a component- and run out of time for a redesign. Another classic there- you have a UI and suddenly it gets terminal- as in you have to enter commandline shortkeys to archive efficient workspeed with it.