5 ms·

I really value unfiltered end user input. No third party customer contact is going to tell you that use looked for "Export" under the "File" menu instead of whe

I really value unfiltered end user input. No third party customer contact is going to tell you that use looked for "Export" under the "File" menu instead of where you had it the very first time they used the product. You have to watch over the users shoulder of have video. I reserve my mornings for "thinky" time. It's when I have the most energy. I answer emails in the afternoon. This may be controversial, but I try not to respond to email immediately. I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email. With an email question that gets answered say, once a day, the user will endeavor to phrase his questions more thoughtfully.

axegon_ 6y ago
> You have to watch over the users shoulder of have video. Perfect advice. Sadly...
- tluyben2 6y ago
  Depressing actually. I still don't understand how it works, really. I asked someone how to do something in Postman (I couldn't not immediately find it in Google); he sent me a 15 minute video. Slow, boring, not copy-pastable, etc but yeah it worked. I checked the description and the owner also wrote a blog post, which distilled the 15 minutes in 10 lines, 3 if you exclude the introduction. Vastly more effective; no idea why people prefer videos. I only do when i'm resting ; then I put on some (usually programming language) meetup/event video in the background while resting my eyes. That only helps because i'm not really doing something actionable, but when doing something actionable, reading is always faster and you can copy/paste when there are slabs of code...
  - VBprogrammer 6y ago
    I think you are getting the wrong end of the stick here. In trying to diagnose users issues a video of what they actually did is often 100 times more effective than asking them. It's analogous to having eye witness testimony compared to CCTV / body cam evidence backing up the testimony. In a previous job we used to use some web service where they got users to test your product providing commentary on what they are doing at the same time. It was so useful that we paid an intern to go through the videos and highlight bugs and annotate the times in the videos. I briefly considered creating a startup around similar ideas but got put off by the amount of hard work getting cross platform screen recording working would be.
    - tluyben2 6y ago
      Ah! Sorry, indeed I understood the reverse; that as product owner you have to make videos to show everything by making videos. Yep, absolutely right!
    - axegon_ 6y ago
      Exactly. Words cannot describe what sort of behaviors I've witnessed over the years. I.e. someone right-clicking copy-pasting 256 separate lines one by one into a text field. Normally a developer would never even consider such a scenario, given that it would take the user a good 40 minutes to do that. But there we go...
      - paledot 6y ago
        Incidentally, this happened to me yesterday. Roll20 told me that my library was full but didn't give me an obvious way to delete more than one item at a time, so I spent 40 minutes reverse engineering their API to batch delete everything I'd uploaded. Naturally, I found the bulk delete function as soon as I had finished.
  - korijn 6y ago
    Because a video captures the actual behavior, and writing is subject to what the author thinks is relevant. It might miss crucial bits of info, that cannot be left out in a video.
    - withinboredom 6y ago
      I remember a bug report that had the instructions meticulously written out to reproduce. Only, it didn't reproduce the issue. Luckily I also had a video, and when I watched it, it all made sense (well, why I couldn't reproduce it, the bug was ridiculous and required going through a very specific path to get the state juuuust right). You had to click the "icon" in the top left corner to eventually trigger the bug, not "go back to the app home page" via the back button like what I was doing.
PopeDotNinja 6y ago
> This may be controversial, but I try not to respond to email immediately. Interesting approach. Personally I just cancelled a premium service because the product didn't work as expected, and getting replies to customer service took a couple days.
- galoisgirl 6y ago
  Your emails were probably in a queue, handled by people who work on them full time. It's completely different than someone choosing to answer your email later. I do the same. Of course, it depends on the situation. When someone is blocked, or when it's a fellow dev, I respond fast. But responding immediately often teaches people (especially non-technical ones) that you have time and focus to always reply this fast. Value your own time, and manage others' expectations. Scheduling that e-mail for 15 minutes later will save you lots of time and frustration in the long run.
chrisbennet 6y ago
"I really value unfiltered end user input. No third party customer contact is going to tell you that the user looked for "Export" under the "File" menu instead of where you had it the very first time they used the product. You have to watch over the users shoulder of have video." To clarify, the users first impression or actions are a one time only event that you want to capture as a developer because they won't do it the same ever again. The analogy I use is: Suppose the carpet on the door sill of your cubical is unglued so it sticks up a little. The very first time you walk over the threshold you may trip. After that, you unconsciously lift you foot a little higher every time you go into you cubicle. In your role as a product designer, you want to avoid "tripping" the user if at all possible. When I'm working on a GUI, I want it to be "invisible" to the user - it just works. I rarely succeed 100%, but I try. The developer who says "the user is doing it wrong" should re-access their attitude. (I've developed CAD programs, solid modelers, oscilloscopes, etc. Basically, tools for technical people.)
- DJHenk 6y ago
  I think the amount of times the user is allowed to trip should be proportional to the intensity with which the user is going to use the tool. If the tripping enables advanced use, of course, which is not the case in your example. First time use is completely different than prolonged use. Efficient use is not necessarily the same as ease of discovery. The first time I rode a bike, I fell off. Does that mean bikes are badly designed? I get the feeling most designers who make an effort only look at that first time use. I get it, if the user comes around only once a month, your product should be super easy en intuitive. But if it is used daily, your product is a tool and is allowed to require skill to master. If the end result is better in some way. Either because it is more efficient, or because it takes time before one sees that there is actually more logic in that interface than you thought the first time you used it.
fbelzile 6y ago
> I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email. For me, this doesn't happen as much as I thought it would. I consistently get told how my support emails are a breath of fresh air compared to other software companies. Support emails can be an effective marketing tool. Done correctly, fast replies can definitely increase conversions or help with word-of-mouth marketing. As a one person business, doing things that don't scale is the advantage you have over other larger companies. I don't respond to all emails immediately, especially low effort ones (or ones with dozens of questions that can be answered by using a free trial). However, I do believe there's a skill in learning how to read emails "between the lines" and determining if there's value in replying quickly.
chrisbennet 6y ago
"Falling Into the Pit of Success" by Jeff Atwood https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... "I think this concept extends even farther, to applications of all kinds: big, small, web, GUIs, console applications, you name it. I've often said that a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things. If we design our applications properly, our users should be inexorably drawn into the pit of success. Some may take longer than others, but they should all get there eventually. If users aren't finding success on their own – or if they're not finding it within a reasonable amount of time – it's not their fault. It's our fault. We didn't make it easy enough for them to fall into the pit of success. Consider your project a Big Dig: your job is to constantly rearchitect your language, your API, or your application to make that pit of success ever deeper and wider."

axegon_ 6y ago

> You have to watch over the users shoulder of have video. Perfect advice. Sadly...

tluyben2 6y ago
Depressing actually. I still don't understand how it works, really. I asked someone how to do something in Postman (I couldn't not immediately find it in Google); he sent me a 15 minute video. Slow, boring, not copy-pastable, etc but yeah it worked. I checked the description and the owner also wrote a blog post, which distilled the 15 minutes in 10 lines, 3 if you exclude the introduction. Vastly more effective; no idea why people prefer videos. I only do when i'm resting ; then I put on some (usually programming language) meetup/event video in the background while resting my eyes. That only helps because i'm not really doing something actionable, but when doing something actionable, reading is always faster and you can copy/paste when there are slabs of code...
- VBprogrammer 6y ago
  I think you are getting the wrong end of the stick here. In trying to diagnose users issues a video of what they actually did is often 100 times more effective than asking them. It's analogous to having eye witness testimony compared to CCTV / body cam evidence backing up the testimony. In a previous job we used to use some web service where they got users to test your product providing commentary on what they are doing at the same time. It was so useful that we paid an intern to go through the videos and highlight bugs and annotate the times in the videos. I briefly considered creating a startup around similar ideas but got put off by the amount of hard work getting cross platform screen recording working would be.
  - tluyben2 6y ago
    Ah! Sorry, indeed I understood the reverse; that as product owner you have to make videos to show everything by making videos. Yep, absolutely right!
  - axegon_ 6y ago
    Exactly. Words cannot describe what sort of behaviors I've witnessed over the years. I.e. someone right-clicking copy-pasting 256 separate lines one by one into a text field. Normally a developer would never even consider such a scenario, given that it would take the user a good 40 minutes to do that. But there we go...
    - paledot 6y ago
      Incidentally, this happened to me yesterday. Roll20 told me that my library was full but didn't give me an obvious way to delete more than one item at a time, so I spent 40 minutes reverse engineering their API to batch delete everything I'd uploaded. Naturally, I found the bulk delete function as soon as I had finished.
- korijn 6y ago
  Because a video captures the actual behavior, and writing is subject to what the author thinks is relevant. It might miss crucial bits of info, that cannot be left out in a video.
  - withinboredom 6y ago
    I remember a bug report that had the instructions meticulously written out to reproduce. Only, it didn't reproduce the issue. Luckily I also had a video, and when I watched it, it all made sense (well, why I couldn't reproduce it, the bug was ridiculous and required going through a very specific path to get the state juuuust right). You had to click the "icon" in the top left corner to eventually trigger the bug, not "go back to the app home page" via the back button like what I was doing.

PopeDotNinja 6y ago

> This may be controversial, but I try not to respond to email immediately. Interesting approach. Personally I just cancelled a premium service because the product didn't work as expected, and getting replies to customer service took a couple days.

galoisgirl 6y ago
Your emails were probably in a queue, handled by people who work on them full time. It's completely different than someone choosing to answer your email later. I do the same. Of course, it depends on the situation. When someone is blocked, or when it's a fellow dev, I respond fast. But responding immediately often teaches people (especially non-technical ones) that you have time and focus to always reply this fast. Value your own time, and manage others' expectations. Scheduling that e-mail for 15 minutes later will save you lots of time and frustration in the long run.

chrisbennet 6y ago

"I really value unfiltered end user input. No third party customer contact is going to tell you that the user looked for "Export" under the "File" menu instead of where you had it the very first time they used the product. You have to watch over the users shoulder of have video." To clarify, the users first impression or actions are a one time only event that you want to capture as a developer because they won't do it the same ever again. The analogy I use is: Suppose the carpet on the door sill of your cubical is unglued so it sticks up a little. The very first time you walk over the threshold you may trip. After that, you unconsciously lift you foot a little higher every time you go into you cubicle. In your role as a product designer, you want to avoid "tripping" the user if at all possible. When I'm working on a GUI, I want it to be "invisible" to the user - it just works. I rarely succeed 100%, but I try. The developer who says "the user is doing it wrong" should re-access their attitude. (I've developed CAD programs, solid modelers, oscilloscopes, etc. Basically, tools for technical people.)

DJHenk 6y ago
I think the amount of times the user is allowed to trip should be proportional to the intensity with which the user is going to use the tool. If the tripping enables advanced use, of course, which is not the case in your example. First time use is completely different than prolonged use. Efficient use is not necessarily the same as ease of discovery. The first time I rode a bike, I fell off. Does that mean bikes are badly designed? I get the feeling most designers who make an effort only look at that first time use. I get it, if the user comes around only once a month, your product should be super easy en intuitive. But if it is used daily, your product is a tool and is allowed to require skill to master. If the end result is better in some way. Either because it is more efficient, or because it takes time before one sees that there is actually more logic in that interface than you thought the first time you used it.

fbelzile 6y ago

> I believe when you do that, the client/customer will coming to expect a quick response leading a "conversation" instead of an asynchronous email. For me, this doesn't happen as much as I thought it would. I consistently get told how my support emails are a breath of fresh air compared to other software companies. Support emails can be an effective marketing tool. Done correctly, fast replies can definitely increase conversions or help with word-of-mouth marketing. As a one person business, doing things that don't scale is the advantage you have over other larger companies. I don't respond to all emails immediately, especially low effort ones (or ones with dozens of questions that can be answered by using a free trial). However, I do believe there's a skill in learning how to read emails "between the lines" and determining if there's value in replying quickly.

chrisbennet 6y ago

"Falling Into the Pit of Success" by Jeff Atwood https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... "I think this concept extends even farther, to applications of all kinds: big, small, web, GUIs, console applications, you name it. I've often said that a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things. If we design our applications properly, our users should be inexorably drawn into the pit of success. Some may take longer than others, but they should all get there eventually. If users aren't finding success on their own – or if they're not finding it within a reasonable amount of time – it's not their fault. It's our fault. We didn't make it easy enough for them to fall into the pit of success. Consider your project a Big Dig: your job is to constantly rearchitect your language, your API, or your application to make that pit of success ever deeper and wider."