3 ms·

Lots and lots of people don't read FAQs. They don't even read instructions on how to download something or register software, they just write to support ("where

by dchest 15y ago

Lots and lots of people don't read FAQs. They don't even read instructions on how to download something or register software, they just write to support ("where is my product?"), so my advice is: FIX YOUR SOFTWARE. Example: BlogJet (blog client I wrote) required entering XML-RPC endpoint URL for a blog to create an account. Of course, few people knew the endpoint URL for their blogging engine, so 80% of support requests were customers asking for help on configuring their blog. FAQ didn't help (yes, I tried); the solution was to automatically detect XML-RPC endpoint URL from their blog's URL. After I did this, the percentage of such support requests dramatically dropped. The next 80% was customers asking to resend their registration keys. I just wrote a system to automatically resend them, so people no longer wrote to me, they just filled a form and received a key. The next 80%... The point is, find those 80% identical support requests, fix your software or add automation to eliminate them, then repeat. Most questions that can be answered by FAQ are things you can fix in software. As for the system where customers enter their question and get redirected to the related question in the FAQ (see Wordpress.com, Google) -- people hate this, just like they hate browsing phone support systems looking for a way to contact a real person.

evanhamilton 15y ago
We totally agree. That's why we automatically pull up related FAQs but don't pull the customer away from their flow of writing a message to you. We've found it works quite well, as demonstrated by the numbers. It's not annoying like the latter system you mentioned, but surfaces those FAQs that could have helped with that 80%. -Evan Hamilton Community Manager, UserVoice
- dchest 15y ago
  I just watched your demo video, and the system looks nice and very useful, unlike those I wrote about in the last paragraph -- customers instantly see the answer to their question without interruption.
  - evanhamilton 15y ago
    Thanks! We hate being interrupted too, so we are very sensitive to that.
mcantor 15y ago
This is in line with the philosophy espoused in Donald Norman's book, "The Design of Everyday Things". Mr. Norman phrases it as, "a product ought to afford being used correctly", that is, one cannot help but use it without being confused or reaching a stopping point, simply due to the nature of its design. His prototypical counter-example is the lovingly-named "Norman door", which is any "PUSH" door having a handle, or any "PULL" door having a push-plate. "PUSH" and "PULL" signs are essentially FAQs that make up for the "poor design" of a door that does not afford being used correctly.
icefox 15y ago
When I worked on Qt I would monitor various mailinglists and when I would see more than one person asking how to do X I would often go and figure out why the documentation didn't provide that answer. One simple example is that when using QCryptographicHash a common operation is to compare the results to a hex string. QCryptographicHash::result() returned a QByteArray which isn't a hex string. So after seeing more than one person ask how to do this I added a "\seealso QByteArray::toHex()" to the documentation. http://doc.trolltech.com/4.7/qcryptographichash.html#result http://doc.trolltech.com/4.7/qcryptographichash.html#result Another favorite thing to do was if people were looking for a function say called "Foo::search", but it was actually called "Foo::query" I would add the word "search" inside of the Foo::query docs so at the bare minimum if they searched on the Foo page they would find the word search and the api they needed. Often after that help for Foo::search disappear. (or to do bla you have to call X() and Y(), mentioning bla in X and Y's docs really help) There was a lot of pride in the Qt documentation and little improvements like this all of the time really helped to make the dev experience better.

by dchest 15y ago

evanhamilton 15y ago

We totally agree. That's why we automatically pull up related FAQs but don't pull the customer away from their flow of writing a message to you. We've found it works quite well, as demonstrated by the numbers. It's not annoying like the latter system you mentioned, but surfaces those FAQs that could have helped with that 80%. -Evan Hamilton Community Manager, UserVoice

dchest 15y ago
I just watched your demo video, and the system looks nice and very useful, unlike those I wrote about in the last paragraph -- customers instantly see the answer to their question without interruption.
- evanhamilton 15y ago
  Thanks! We hate being interrupted too, so we are very sensitive to that.

mcantor 15y ago

This is in line with the philosophy espoused in Donald Norman's book, "The Design of Everyday Things". Mr. Norman phrases it as, "a product ought to afford being used correctly", that is, one cannot help but use it without being confused or reaching a stopping point, simply due to the nature of its design. His prototypical counter-example is the lovingly-named "Norman door", which is any "PUSH" door having a handle, or any "PULL" door having a push-plate. "PUSH" and "PULL" signs are essentially FAQs that make up for the "poor design" of a door that does not afford being used correctly.

icefox 15y ago

When I worked on Qt I would monitor various mailinglists and when I would see more than one person asking how to do X I would often go and figure out why the documentation didn't provide that answer. One simple example is that when using QCryptographicHash a common operation is to compare the results to a hex string. QCryptographicHash::result() returned a QByteArray which isn't a hex string. So after seeing more than one person ask how to do this I added a "\seealso QByteArray::toHex()" to the documentation. http://doc.trolltech.com/4.7/qcryptographichash.html#result http://doc.trolltech.com/4.7/qcryptographichash.html#result Another favorite thing to do was if people were looking for a function say called "Foo::search", but it was actually called "Foo::query" I would add the word "search" inside of the Foo::query docs so at the bare minimum if they searched on the Foo page they would find the word search and the api they needed. Often after that help for Foo::search disappear. (or to do bla you have to call X() and Y(), mentioning bla in X and Y's docs really help) There was a lot of pride in the Qt documentation and little improvements like this all of the time really helped to make the dev experience better.