This post forms part of a series on the challenges of paper-based field research.

In the first stage of the field research process, the metrics are usually determined – the question “What data must be collected?” is answered.  Once this has been decided on, the surveys (aka questionnaires or forms – depending on function) are designed.  The goals which survey designers should be cognisant of during this process are:

• Surveys are structured in an unambiguous manner which does not make their responses subject to fieldworker bias or (mis)interpretation.  Factors such as localised terminology, advanced logic and respondent fatigue come into play.
• The collected data is easy (or at the very least possible) to analyse.  Tables are a common favourite amongst designers who are used to deploying surveys on paper because they use very little space – but they can create tremendous challenges when trying to unravel them at a later stage.

In the majority of cases, the design process involves multiple stakeholders (such as principal investigators, consultants, ethics committees, etc) and the design tools used are often run-of-the-mill word processors (such as Microsoft Word or OpenOffice).  Countless versions (and I use the term version rather loosely here) are emailed from one stakeholder to the next with limited regard for change control. 

Without a dedicated survey design tool, asking questions in a consistent fashion and the way in which the logic is described to the fieldworker can vary significantly – even within the same survey.  That’s bad news for data integrity.

If a change has to be made to a survey (and that occurs rather frequently) such as the addition of a new question, or removal of an unwanted one, it often necessitates a thorough check of the entire survey to ensure that skip logic references and numbering still make sense.

Our approach

When developing the survey designer component of Mobile Researcher, we decided to keep the existing conceptual model of a designing a survey on paper.  Designers lay out their surveys section by section and can select from a variety of question types.  We felt that it was a better idea to pass the complexity of survey logic on to the designer rather than leave it to fieldworkers to follow instructions.

Instead of writing out instructions which fieldworkers need to interpret or follow, the survey workflow (logic) is built into the design of the survey itself. This logic is not actually shown to the fieldworker but is evaluated and executed by the mobile application on their phone.  The fieldworker is only ever presented with one question at a time.

Using a consistent approach to survey design improves efficiency and reduces the likelihood of errors being introduced by confused fieldworkers.  A caveat to the approach is that survey designers need to think clearly about how they’d like the survey to flow.  Although the designer is intended to be intuitive to use, there is no substitute for logical thought.