Keep It Simple, Survey (Author)

In my last post I emphasized the need to prevent getting “journey-jammed”, focusing too much on too large a goal than is practical to handle all at once. Here’ I’d like to comment on the tactical elements to get good, viable data from each journey touch point.

First, a survey do not do
Seems counter-intuitive, coming from someone whose job it is to run customer experience research projects, I agree. And yet it is still true. Before you being to build a new survey project, identify the resources already available to you. Does the data you’re looking to capture in the survey live in a CRM, HRIS or other corporate resource? If so, and the data is current, no need for a survey. If not, a survey can actually be quite helpful, so proceed!

If you must, do it well you must
The elements of a good survey include personalization, contextualization and consistency. Use the data you have on hand to welcome your survey guests, and to reinforce (which can coincidentally improve) the relationship. Use your knowledge to have your participants confirm, correct and/or update key data fields (panel-based surveys make this easy, read more here. Use of consistent response scales is critical here, as well. If you need to compare year-over-year findings from the same audience, track or compare metrics between survey projects, use of consistent response scales is key. Unipolar or bipolar, you ask? I prefer my scales balanced (and my martinis dry, thank-you-very-much), but there’s plenty on good scales here.

To cut, the first instinct of surgeons and authors, should be.
And cut you should. Surveys inundate us daily, even hourly, it seems. The key difference between a survey that gets results and solid response rates and one that doesn’t? Length. If you’ve created a survey that will ask more than 25 questions of any given participant, you’re doing it wrong. OK, may not wrong, but there is certainly room to make the survey more efficient. If the question isn’t on topic, is nice-to-have, can be answered by looking into existing systems or resources, you need to cut it out. Save it for another day, and you save your audience for future projects. My maxim in this regard is, think haiku, not epic poetry.

The end in mind, begin you must

It’s been said before, and said by many, but being with the end in mind. In this case, there are two ends: the respondent’s experience and the analyst’s experience. Test the survey, make sure the data pre-loads, piping and personalization work as expected. Test each branch of logic, and send the survey around to the smartest people you know (I always send mine to my wife, who is easily the smartest person I know, despite her choice in a partner!) and ask them to test various paths. Check for spelling, flow, layout, etc. But don’t skimp on the data side! I have designed some pretty useless, but great looking (if I do say so myself) surveys, and catching this before going live makes life with the boss much easier than not. Use test data generators and sample submits from your survey testers to build out your trial reports. Make sure that if you need to export the data and marry it up with data or systems elsewhere, you run through this using your test data, too.

These are my four guidelines for making my surveys successful. What are yours? Use the comments option below and let me know!