Hacker News Reader

Comment by Gary404 | Hacker News Reader

I'm working on b2b software and when working with the designers at http://fairpixels.pro I've learned many things from their approach as to why (a lot of) software sucks. Personal example: I've been measuring qualitative feedback users have been giving us and passing it to them to make design updates. They (design team) would come back with me with questions about data & metrics. They were more interested in what the users DID vs what they told me. This sounds small, but has made a huge difference in the way I look at product design & development. The things users told us in a few cases, didn't match the way they were acting in the product. After some research, we found out why and managed to redesign those features and solve the problems.

The thing with most software, just like ours, is that many of us engineers don't have the deeper design knowledge to really understand how a product needs to be build from a user's perspective.

View on HN

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

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?

I'm suddenly reminded of the car that Homer built:

http://simpsons.wikia.com/wiki/The_Homer

I suspect there is a lesson there about using aggregate feedback, rather than listening to single individuals.

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.

Just to add onto this, there's a whole field of people who design things with human psychology in mind. For example, when you got onto Twitter, they _could_ show you how many notifications you have right away, but they implemented an artificial delay so you stare at it intently and when it finally shows you feel gratification [1].

So while a design may not make sense right away, there may be other factors at play.

[1] https://www.vice.com/en_ca/article/vv5jkb/the-secret-ways-so...

Reply on news.ycombinator.com