35 ms·

I'm working on b2b software and when working with the designers at http://fairpixels.pro http://fairpixels.pro I've learned many things from their approach as t

I'm working on b2b software and when working with the designers at http://fairpixels.pro 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.

fgonzag 9y ago
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.
lamlam 9y ago
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-social-media-is-built-for-addiction https://www.vice.com/en_ca/article/vv5jkb/the-secret-ways-so...

fgonzag 9y ago

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.

lamlam 9y ago

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-social-media-is-built-for-addiction https://www.vice.com/en_ca/article/vv5jkb/the-secret-ways-so...