Don’t just hate, write bug reports

I have seen this pattern very often in the last year: someone found a bug in a product and instantly wrote a twitter message with a #fail hashtag. Or even worse: wrote a bad rating for an iPhone app just saying : “Doesn’t work. This is shit!”.

As a user you usually want a good experience using a service. If it wasn’t good for you, complain. It’s your right to do so. And you should. As loud as you want. But if you do, please use a way that opens the possibility for the other side to answer your problems. If you rate an app in the iphone store, the vendor of that app can’t reach you. Your complaint is lost. Never to be answered. Maybe the vendor needs some data from you to fix your issue. Or you just overlooked that important setting in the options pane. And please mention exactly what your problem is. “Doesn’t work” just shows that you’re a fucking idiot. And if the vendor helped you after you tweeted your problem, you should inform your followers that the issue is resolved. Be nice and thankful, don’t behave like the grumpy old fuck from next door.

I had a lot of great chats with support people after sending a short mail and explaining what the problem was. And a lot of them took my complaint seriously and fixed the problems or showed me how to get what I wanted. Sometimes you even get stuff for being nice and helpful. Early Betas to test, some goodies or information about coming features.

You can still rate that app in two days and say that the customer support is awful. But at least you have more to write than “this is shit” :) .

And for god’s sake don’t use #fail for minor mistakes. I have seen a lot of “the button xy in that app is on the left, not on the right #fail”-kind of stuff in my twitter feed. That’s not even close to be a #fail.

This entry was posted in Development and tagged .

14 Responses to Don’t just hate, write bug reports

  1. Jimboooo! says:

    Here’s a bug report: It spelled ‘complaint’.

  2. bitboxer says:

    Thanks. Fixed it.

  3. pesco says:

    While what you write is certainly true, there are also enough cases where the author of same software clearly hasn’t spent enough thought on whatever he was doing. So I think there are both trends. And I’d like to hilight the other one as quite regrettable also. Sure, you release open source software without liability for fitness for any particular purpose, but that’s the letter of the law. I feel that public release does bring responsibility for a certain expectation of reasonable quality.

    Just a side note.

  4. pesco says:

    Sorry, I meant to write “some software”, not “same software”.

  5. bitboxer says:

    Yes, if you release something, you are responsible for it. And that’s good. If you don’t want to be responsible for the software after the release of it, you should clearly say so in the readme or on the homepage.

    And even if your app doesn’t fit the needs of a certain user, you can clearly say that in your response to his report. That’s what communication is about. Everything is better without a “XY sucks” or “You suck”. Both sides should know their responsibility and take the other side seriously.

  6. karim says:

    well, the above blog can only be understood by tech savvy person. everyone cannot exactly comment on what is gone wrong with the product because every one does not understand the product, say for eg. if some guy callz up the customer service of an internet company then the customer will always say “I does not work”. customers donot know the product.

  7. Jan Rychter says:

    All too often once I take the time to write a proper bug report, I see the author a) is annoyed at me for being troublesome, or b) shrugs the bug off as “not reproducible” (therefore unexisting), or both.

    I think it might be worthwile to educate software writers that EVERY bug report is valuable. If something happens and someone reports it to you, it means it has happened to hundreds or thousands of others, who haven’t bothered. So don’t ignore bug reports.

  8. bitboxer says:

    @Karim: That’s not true. Everybody can say what they expect and what they see. “I press the button there and it does not open a new dialog”. That’s a sentence even my grandma can write.

    Everybody is in the position to formulate a sentence that is better than “doesn’t work”. Really.

  9. I always recommend software vendors to include some high-level error wrapping functionality which will prompt user with a nice message like “We’re sorry for the caused trouble: please, write what were you doing when the “%error%” occurred and press “Send feedback”.

    Of course, not all people will use it properly, but some feedback is better than nothing.

  10. bitboxer says:

    Yes, adding those dialogs is definitely a good start. But there are lots of situations where the software works as designed but the user still has problems. Maybe because the GUI is not good, the user expects something different when pushing a button or the app is missing a feature.

  11. One more feedback magnet can be “Get Satisfaction”-like badge. Make it application- or site-wide and easy to use and it will become another source of feedback.

    But, from the other point of view, it can add some feel of uncertainty or immaturity.

  12. bitboxer says:

    You can do that all, but the main problem is that there are tons of people who just want to write “this is shit” on twitter and everywhere they can instead of using those features. That’s very very sad and somehow this should be changed. I don’t know how you can change those people, but I see this blog post as a start :)

  13. My personal opinion is just to ignore those shit-throwers. How can you force a dumb ass to think before say?

    Give smart people an ability to get in touch and forget about those, who doesn’t bother to spend a second on deliberate action.

  14. Torley says:

    I’m with you there, Alexander.

    Amplify the awesome and chop the slop!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>