Moving paper surveys online – automating the process of publishing surveys

I’m Sarah Brooks, I’m a Product Manager for Business Electronic Questionnaire (eQ) and Author, and my role is to work with a range of stakeholders to move paper surveys online. We have around 80 business surveys that have previously been dispatched and completed by paper and sent back by post. We’re digitising this process, creating electronic questionnaires so that respondents can complete and submit their surveys online. But what benefits does eQ offer it’s users?

eQ is fully accessible and inclusive. This means that people who use assistive technologies such as screen readers and voice activation software, as well as those with other diverse needs, can use eQ with ease.

Preview of an eQ online survey which has been designed to be fully accessible and is used for data collection.

Every feature and question pattern within eQ is specifically designed and researched to ensure it meets user needs. This involves conducting research with different types of people with varying digital abilities.

We provide validation errors for respondents, which means fewer calls from the survey team to query data. This saves time and resources for the ONS, as well as reducing the burden for our users.

Preview example of an error message that is displayed to uses before they can move on to the next question in the survey.

Some other benefits of using eQ include:

  • it’s more sustainable long term as there will be reduced paper costs
  • reduced burden for respondents who previously returned surveys by post
  • quicker returns
  • it’s fully responsive and can be completed on multiple devices such as phone, tablet and desktop
  • because of the fast pace of evolving technology, people expect to be able to return online, therefore there are also reputational benefits

Creating electronic questionnaires

The vision within our team is for anyone to be able to build, publish and maintain a questionnaire, regardless of technical ability. Moving a survey online has previously been a task completed by a developer.

We have an application at the ONS called Author. Author is a tool that allows people to create an eQ with no programming experience. This is a user-centric product because similarly to eQ, each feature is designed and usability tested with users.

Preview of the Author application, a tool that allows users to create their own online surveys. Includes exmaple questions, descriptions, things to include and exclude, and labels.

Automating the process of publishing a survey

Each time we make a survey live, the development team follows a series of steps, which are time consuming and expensive. We want to automate the process of publishing a survey to free up time within the team to allow them to focus on building features and capability.

The first step was for us to understand the business processes of onboarding a survey.

We ran a series of workshops with various internal teams to understand what happens at each point of the publishing process. We then created a first version of the “to be” process for publishing, where the majority of the sign-off process would be done offline.

What work was involved?

Providing in-app validation

There are certain fields which must be completed before the survey can be viewed. We built in-app validation, which tells users when they’ve made a mistake. This stops them creating broken surveys.

A preview of built-in app validation, which shows the user what fields must be completed before the survey can be viewed. Label is highlighted as an error as the field has been left blank.


We’ve introduced view and edit permissions so that users can only make changes to questionnaires they have access to. They can now add editors to questionnaires so that more than one person can work on them collaboratively.

Sign-off process

Non-developers can publish surveys. They can also republish and make changes to live surveys. We have built an approval process so that the eQ team can check the questionnaire meets best practice standards before publishing the questionnaire into our survey register. As reviewers, we can choose to either accept or reject the proposed survey.

History and versioning

We provide updates to our history page when a survey is published, republished, approved or rejected. We also tell the user what version the questionnaire is. For example, if it’s been republished once, it will become Version 2.


Users can make comments to colleagues when working collaboratively. They can also reply to comments and start threads.

Question codes

We need to connect our answers for when we process the data using unique IDs called QCodes. Previously this has been a time-consuming task by our developers, but users can now add the codes themselves.

Survey theme

We have specific logos and branding for each survey we publish. The content might be the same for multiple themes, for example, a Great Britain and Northern Ireland version. The user only has to create and maintain one questionnaire, but it will now publish with multiple themes.

Updates to the homepage

Once submitted for approval, the homepage updates to tell the user the status of their questionnaire.

Next steps

We are working with other product teams in the service to fully automate this process.

We want to introduce more complex features such as email alerts, a notification centre, permission groups, and to allow users to create a more complex sign-off process.