Most surveys suck. Think about how many you've seen and just sighed, or clicked away from in frustration, or struggled to understand. They suck. Partly, this is because survey design is hard - requiring sound statistical and research methodological experience, and a grasp of information design.
Partly. You can make surveys suck a whole lot less by doing two really, really basic things:
- Think about how your user thinks, and if possible don't make them do it at all
- Sort out the writing
The first one is the really, really important one. The second one is just getting it across.
Ask a silly question

Yes, it's a pathological example, but it's quite closely based on a survey I came across last week.
The survey designer here clearly wants nice, clean, quantitative data about users' creature nibbling predilections. Who wouldn't. Problem is, they don't seem to care about how much cognitive load they impose to get it. Most folks don't have quantitative breakdowns of all their behaviours on the tips of their tongues, and in this case they're being asked for one in a madly counterintuitive way. It takes too long to parse the question, much less answer it.
I'm going to take a wild guess and suggest that this kind of thing typically happens when people lose sight of a vey well-worn usability cliché: remember your user isn't you.
For surveys this means the information you want isn't necessarily something you can ask them for directly. They are likely to understand things differently, and almost certain not to share your grounding assumptions.
Terminology
Make sure you're phrasing things in a way the users think about them. (Why are the number of legs important, and what does that mean about implicit categories?). For instance, being British, I might be expecting a totally different kind of answer to most Americans if I asked a question about "football". More usefully, do the way your users experience your business, and the way you talk about it match?
Here at Red Gate, two of our business divisions are SQL Developer Tools and DBA Tools. If we asked somebody, say, "What is your most used Red Gate DBA tool?", they'd be well within their rights to answer "SQL Data Compare". That's a fairly toothless example (and the "wrong" answers might themselves be interesting) but you get the idea.
Use their terminology over yours. And if that means you have to do some thinking at the end, tough. If the question isn't instantly easily intelligible, you'll get lousy data.
Again, thinking is your job, not the users'.
(As a side-note, psychometric tests are a fascinating counterexample. Many are riddled with weirdly obscure assumed categories, requiring you to decide if you're more "Mauve and insouciance" or "goal-oriented and butterscotch". Personally, they just make me incredibly angry. Presumably some subtle wizardry is going on)
Instructions
We've got a smug adage in technical communications: if it's hard to explain, it's probably hard to do.
A survey question that runs into multiple sentences is probably badly-phrased or overloaded, or both. If it really needs to be that complicated, make sure you use line breaks, and every trick you know to make it easier to read.
In our bad example, "Choices must add up to 10" is foregrounded, it's the first thing you read. Which, for a second leaves you with no idea of what choices or why. It's just in the wrong place - its predicate hasn't yet been established. It's also by no means the most important part of the instructions.
In practice, you'd re-write the whole thing:
It's not quite the same question, sure, but it's massively simpler, and it's phrased in terms people can easily visualise.
Also, concrete units that readily relate to users everyday experiences make questions much simpler to answer. If we'd asked them, for instance, to estimate goat consumption in tonnes per financial year, or assign twenty-two billion points rather than ten, we'd have lost them even more.
Quick wins
Sometimes I edit surveys. The big scary stats stuff isn't quite my field, but this is what I do to the words:
- Paragraphs and line breaks
These are critical for ease of reading. People skim web text, so don't make it dense. Most of what I do when somebody asks me to edit a survey is breaking up the text. - Don't say please
Get right to the point in the fewest words possible. Avoid "Please supply your email address so we can contact you". "Email (optional):" will do. - No maths
If you must make me think, don't make me add up. Try and re-frame the question. - Keep it on one page
Or few, rationally grouped pages. - Keep it short
Every extra question raises the dropout rate. It's probably also worth keeping each page's content above the fold. - Make sure questions aren't leading (unless they need to be)
You can get some real gems from those "Any other feedback" style free-text fields. But you mostly get nothing. It can be worth adding some gentle suggestions.
Any other tips for making surveys less soul-destroying?