Drupal Forms User Guide

A question protocol is a tool to help you co-design a form with a service. It's a spreadsheet listing all the questions they want to ask, capturing useful information about each one. Filling one in with the service can help you to:

• encourage the service to be clear about what information they need and why
• figure out which elements would be most useful to capture the data
• see where there might be concerns over data governance
• weed out legacy questions that aren't really needed
• balance user need with statutory requirements

You could start by filling in what you know and asking the service to fill in the blanks, or go through them together on a call.

Download a question protocol template

It includes the following columns for each question.

Why do we need this question?

Use this to find out if the question:

• is a legal requirement
• demonstrates eligibility
• identifies the user as an existing customer
• helps to assess need

If it's none of these it's likely to be a legacy question and no longer needed.

What format should it be in?

Use this to find out if the service need the data in a predefined format or as free text. This encourages them to consider how this will affect the data quality and how easy it will be to process.

Who will process this data?

This will help determine who the completed forms should go to, and if they should go to different people depending on the information given. For example, the form owner themselves may not always need to receive them.

If you can minimise the number of people that see the data, this minimises the risk of a data breach. 

When can the data be deleted?

It's helpful to capture this at the beginning, so the service can plan how they want to manage the data we send them. Form submissions are only stored in Drupal for 180 days by default.

Any risk associated with this data being incorrect?

If the user enters the wrong information in a field, this could lead to something like:

• the service not being able to contact them
• inability to make or receive a payment
• their application not being accepted when it should have been
• their personal details being sent to the wrong service

Depending on the type of risk, we may be able to reduce it by:

• adding validation rules
• adding helpful microcopy
• phrasing the question differently

Which users need to answer it?

Questions which only need to be answered by a subset of users can be hidden from others. Identifying these helps you to put them in order and build logic into the form. Once this has been agreed, you can add a rule to the 'Any conditional logic?' column.

Any conditional logic?

Use this to capture any opportunity to hide questions. For example, only show this question if the answer to x is yes. 

In combination with 'Which users need to answer it?' this helps you to put them in order and build logic into the form.