Online questionnaire functions

In this section:

Login to answer questionnaire

  • Ensure the login process is as simple as possible. Minimise the number of steps needed to complete the login process.
  • Provide clear procedural instructions on the welcome page to ensure respondents can understand and complete the log-in process.
  • Avoid using characters in login identifiers which are hard for respondents to distinguish (for example 0 and O).

Automated functions

  • Use automated calculations using answers from a question or previous questions to assist with the responding process.
  • Use automatic routing to route respondents to relevant questions based on their answers to previous questions.
  • If possible, include a function which will allow respondents to undo the automation if necessary. It should be clear to respondents what has triggered the automation.
  • In long surveys or where there may be multiple people working on the same response, consider an option for respondents to go directly to sections. This is useful when more than one respondent will answer the survey.
  • If possible and appropriate, include a 'resume' function, where respondents can save their answers to a partially completed questionnaire and return to it at a later date.


  • Automatically insert information from respondents' previous answers within the current survey when appropriate, but restrict the use of inserts to those that are essential to the question.
  • Check the logic of inserts carefully as they can impact on how a question reads on screen. For example, when an insert is used, words could be omitted from a question because of non-response to a linked question.

Edits and checks

  • Edits can be useful to obtain consistent formats (for example, dates and plausible values).
  • Minimise the total number of edits to avoid respondent frustration.
  • Use automated functions instead of applying edits to questions.
  • In a page-by-page design, display error messages immediately (before a respondent can move to the next question) so respondents are able to keep their focus on answering that particular question.
  • Where edits must be delayed (for example in a scrolling design), error messages need to be made noticeable within the page by using red text close to the question.
  • Error messages should provide specific information about the error and the action the respondent must take to correct it. Generic messages should only be used for system errors.

Text format for error messages

  • If warning or error messages are to appear in a pop-up box, the text should be black. If the warning or error messages are to appear within the page (for example, if a respondent did not answer a question), the message should appear in red text to ensure respondents notice it.
  • Error message font should be the same size and style as font used for questions and response options (Arial Maori, 12pt).

Help text

  • Detailed background information or lengthy definitions and instructions should be presented separately to questions.
  • Respondents should access this non-essential information through hyperlinks or hover-over functions. Use hyperlinks for longer, detailed information and use hover-over functions for short notes.
  • When writing help text, avoid large blocks of dense text.

Bilingual or multilingual questions

  • If more than one language will be used to complete a questionnaire, consider whether an alternative language is best displayed through a fully translated page or a hover over function.
  • If it is likely for respondents to be bilingual, consider using a hover-over function with respondents' dominant language so they can check their understanding (for example, of one question).
  • If it is likely that respondents are very proficient in the alternative language, consider accessing a translation by clicking to a fully translated questionnaire.
  • It may also be possible to translate to the alternative language on a question-by-question basis. However, ensure this is not too much burden for the respondent to go between questions or languages otherwise they may be less likely to use the translations.

Summary screens

  • Consider using a summary screen before respondents submit their questionnaire to feed-back to respondents the key information they have provided.
  • If edits and checks have been used to validate respondents answers, a summary screen may not be necessary.

Progress indicators

  • Evaluate the need for a progress indicator. Progress indicators may not be necessary in a scrolling design, as the scroll bar helps to denote respondents' progress through the questionnaire. They also may not be necessary in short questionnaires.
  • When programming a progress indicator, determine the best way it can be programmed. Examples of this are whether it is measured on the amount of questions left or the time left to complete the questionnaire, whether it is shown continuously throughout the questionnaire or at certain points, and, whether it is displayed as a graphic or text.
  • Progress indicators may encourage people to respond more completely as they can see their progress through questionnaires.

Send us your feedback

This guidance is a work in progress, so please email us your feedback on how useful you found it, what was missing, how it could be improved.

Navigate this guidance