# What is a good tool and format for representing and communicating the design content of a survey?

Are there any decent tools for writing/designing questionnaires before providing to programmers? Currently Microsoft Word is being used and tracking changes and keeping it standardized has become a headache.

Update: I think I'm being a little misunderstood here. Here's a scenario: A client speaks to a statistician/expert in survey design so they can design a survey to receive feedback from their customers. Once that survey is designed (not in the fashion sense) they might give it to an artist and programmer to actually create the survey (for the web or whatever). I am wondering what some good ways to communicate the logical design of the survey to the programmer might be.

• docs.google.com – Carlos Accioly Nov 11 '10 at 20:54
• Are you interested in publishing (online or offline) or editing solutions, finally? – chl Nov 11 '10 at 21:05
• I've changed the question wording to "communicate" to, hopefully, demonstrate what I mean a little clearer – Joe Phillips Nov 11 '10 at 21:37
• In retrospect (now that I've answered), StackOverflow is probably the ideal place for this question. Who better to answer than a bunch of programmers? – Matt Parker Nov 11 '10 at 22:06
• @Matt this question is not intended to have anything to do with programming. It's about communicating a questionnaire, strictly from a statisticians point of view, to a programmer – Joe Phillips Nov 18 '10 at 14:31

## 5 Answers

As you and Matt Parker both noted, there can be a big difference in the preparation of a survey script that is digested by your client and how you prepare the script for your programmers. In a professional setting, "client" friendly scripts generally win focus and the programmers are left to put the pieces together as they go along. However, there are some things you can do to make your programmer happy. The scripts we generally develop are Word based so my tips are related to Word, but should be fairly transferable to other platforms. A few tips or suggestions:

1. Include "preamble" for your script that outlines what is conveyed in the document. This may include question text, question answers, branching logic, programmer notes, etc. How you differentiate that in the document is a style preference, but for example all of our notes to the programmer are in <> tags and reviewers are instructed to ignore them for their purposes.
2. To the extent you can, try and list any intermediate variables or calculations that are needed for future questions.
3. Refer to questions by some identifiable name and not something generic such as Q3, Q7, Q19. Not only does this prevent you from having to change a bunch of references downstream when you decide to move or add a question, but is just generally more meaningful to say something like "Branch over this question if purpose is vacation" then "Branch over this question if Q4.A is XX".
4. Try and include the programmer in the questionnaire design phase. If this is a complicated survey, having the programmer on board as a sounding board for different techniques may open your eyes to something you would have otherwise overlooked.
5. Finally, tell the programmer up front they have the liberty to change flow / etc as it makes sense in a programming context. As long as they are able to develop the final product as the client envisions it, any intermediate changes they make to what they program will come out in the wash.

I wrote a post some time ago about how to use Google spreadsheets + google forms + R for easily collecting and sharing data. It might prove useful to you or others:

http://www.r-statistics.com/2010/03/google-spreadsheets-google-forms-r-easily-collecting-and-importing-data-for-analysis/

If I understand correctly, you just want a way to communicate the logical flow of the survey. Have you thought of Visio or SmartDraw or other flowchart software? You can have sub-flowcharts to represent different control conditions.

A combination of Perl + CGI is generally interesting for small surveys/questionnaires (because I hate PHP + MySQL). A gentle introduction can be found in How to Conduct Behavioral Research over the Internet: A Beginner's Guide to Html and Cgi/Perl.

Now, I think that Ruby and Rails should provide very handy tools for that particular purpose. I can think of surveyor, for example. I'm quite sure there are similar tools in Python.

As for an all-in-one system (no need to program anything, multiple and linked form available, automatic mailing, etc.), there's Lime Survey.

For off-line questionnaires, I would prefer $\LaTeX$ or Docbook.

• Django would be the Rails equivalent in Python; I haven't used but have heard good things about the django-survey module for it: code.google.com/p/django-survey – Matt Parker Nov 11 '10 at 21:23
• @Matt Yes, I was thinking of this kind of stuff. Put it as an answer! – chl Nov 11 '10 at 21:29
• Sorry for any confusion. I'm more interested in knowing how a survey designer would communicate a survey to a programmer for them to create – Joe Phillips Nov 11 '10 at 21:35

For mocking up what you want the survey to look like for a programmer, I would definitely just code it up in HTML.

• HTML is easy in general; for things like this, it will be dead simple. I don't think you'd need to fuss with any CSS to make something useful for your programmer. Conversely...
• You or your programmer can use CSS to drastically change the appearance of the survey without needing to edit the individual elements.
• Version control becomes very easy - just use something like git, SVN, or Fossil that will let you easily distribute the most recent version of the survey and will let you track exactly which changes were made, when, and by whom.
• It's free!
• How it looks visually isn't as important as the content and the rules that should be applied to a question. For instance, if question 1 should skip to question 5 if answers A or B are selected on question 1 – Joe Phillips Nov 11 '10 at 22:20