We recently added a support request form to Basecamp (there used to be just a direct email link). The goal of this form: To prioritize support inquiries, reduce uncertainty, and get people the answers they need faster. It also reduces the number of back and forth information-gathering emails, which ultimately makes everyone more satisfied with the support experience.
It’s worked really well so far too. But the last question in the original form was missing the mark:
We wanted to know how important the problem was and gauge the emotional state of the person writing to us. But this pulldown just didn’t cut it.
First off, it required too much reading for a pulldown menu. Who wants to process this much info when there’s a problem? Also bad: It’s a pulldown but the options aren’t mutually exclusive. Someone could very well be confused AND worried AND upset. This pulldown just muddies the waters.
So we decided to change it to an actual scale. 1 = not a big deal, 4 = I need help ASAP.
Much easier to process but it still wasn’t helping us learn whether or not this query was a top priority or not. Why? Because everyone’s problem is urgent.
For example, let’s say someone’s having trouble uploading a file. If they can’t figure out how to upload a file, they’ll say it’s urgent. If file uploading is broken, they’ll still say it’s urgent.
That’s no help to us. Of course, we’ll get back to them either way. But if file uploading is broken, we need to know that immediately so we can fix it. If it’s just confusing someone, that’s a different ballgame. We’ll still quickly resolve the issue, but it’s not a fire that has to be put out instantly.
We thought about adding in a radio button question that asked “Is something broken?” But we didn’t want to make the form any longer. (No one likes feeling interrogated while seeking help.)
So we went back to the drawing board and came up with this solution:
This gets at what we really want to know here: What kind of problem is this? We lost the subjective nature of the original “give us your emotional state” question and replaced it with a clear question with a clear answer. It’s better to ask for facts than emotions.
Now, if something’s broken, we can spot it and fix it right away. A system failure is much more important to us (and our customers) than a feature request or general feedback. This method lets us prioritize these queries accordingly, instead of treating them like they’re all the same.
Update: Per feedback on this thread, we’ve adjusted the menu to the following (more consistent language, no more “general feedback” category since “other” is close enough). Thanks for your comments.
Related: Copywriting is Interface Design [Getting Real]