The annotated journal

Decide which questions your form needs

Decide how each form answer will be used, who needs to provide it and when. A practical review of necessary, optional and compulsory questions.

Illustration of a hand tracing a green line from an answer on a form to a highlighted row in a record.

Before adding a question to a form, establish how its answer will be used. Making the answer compulsory needs a further explanation: why this person must provide it at this stage.

That gives you a basis for reviewing a form whose questions have accumulated across several teams. You can examine each request against the work the form supports, including the information someone needs to act on a submission.

I would start this review with the person who uses the answers. A request from a department is worth investigating. It leaves the actual use to be established.

Follow a submission to the person using it

Take a completed form and follow what happens to it. Find out which answers the recipient reads, which they copy elsewhere and which determine the next action. Check what they have to look up or ask for again.

This is a practical application of GOV.UK's guidance on contextual research and observation, published in September 2017. It includes observing service operators such as caseworkers and support staff. Watching someone work can expose details that a description of the process misses, although asking them to explain each step changes the activity you are observing.

A recipient may use information that seems unnecessary when you look only at the form. Equally, a requested answer may never reach the person said to need it. Establish which situation you have before changing the questions.

Keep this review close to the submission. If the problem begins with people never finding the form, you need the wider diagnosis covered in the internal communication service journey.

Record a use for each answer

GOV.UK's guidance on structuring forms, published in 2016 and updated in 2018, recommends a question protocol. This records why information is needed and how it will be used before the team designs the questions.

Caroline Jarrett's 2010 account of the question protocol goes to the person who actually uses the data. It distinguishes that person's use from a general assertion that a department needs it.

For a disputed question, I would record the intended use, the person responsible for that use and the point at which they need the answer. Check whether the information is already available. If it is, find out whether the recipient can use it without asking the respondent to supply it again.

Here is a hypothetical support form. Assume the retailer can find an order using either its reference or the customer's email address. Customers can choose a written response or request a callback. These are facts assumed for the illustration, with no research results attached.

Requested information Stated use Decision to examine
Description of the problem The support team needs to understand the request Keep the question and check that its wording produces a usable description
Order number Helps the team find the relevant order Allow another route when the customer cannot find it
Telephone number Enables a requested callback Ask when the customer chooses that response method
Company size Marketing wants to understand the customer base Establish its separate use before including it in the support request

The company-size question needs more discussion. Marketing research can be legitimate work. The team should be able to explain what decision the answer would inform and why this is an appropriate moment to ask. Making a question optional deals with the respondent's choice; it leaves the question's purpose to be justified.

Decide who needs to answer and when

A question can be useful without being relevant to everyone. In the illustration, a telephone number becomes relevant when someone requests a callback. A person choosing a written reply has a different route through the form.

Another question may become necessary later. A service can need detailed information to carry out work without needing all of it to respond to an initial enquiry. Moving a question changes when the effort occurs. It is worth checking that the later request will still arrive in time for the person who needs the answer.

The GOV.UK question-page pattern allows optional information, recommends marking it as optional and permits uncertainty answers where they are valid. That last distinction matters. Someone who does not know an answer needs a route that represents their situation accurately.

A compulsory order number, for example, would be difficult to justify under the assumptions in the table. The retailer has another way to find the order. If you remove that alternative in the real service, the decision must be reconsidered.

Be precise about what you are counting. GOV.UK's form-structure guidance notes that a question need not correspond to one input field. A date can require several inputs while asking for one piece of information. A target for the smallest possible field count tells you little about whether the required information is justified.

Check the questions and the resulting answers

Removing a question can make a form easier to complete while leaving the receiving team unable to proceed. That is a reason to inspect the resulting work before judging the change.

For the hypothetical support form, I would check whether a respondent can describe the problem, provide an available order identifier and choose a response method. I would also check whether the recipient can locate the order and decide what to do next. Difficulty on either side gives the team something specific to investigate.

This is a proposed application of the methods, rather than a demonstrated improvement to a retailer's service. The guidance supplies no completion or conversion result for your form. If you want to claim that a change improved performance, you need evidence of that change under conditions that support the claim.

Keep the record proportionate. Jarrett explicitly allows that a small organisation with a short, easily changed form may gain more from usability testing than from maintaining a protocol. Several owners disputing the need for questions make the record more useful. A form you can understand and change together may need very little documentation.

For the company-size question in the illustration, a brief record would show that support has no use for the answer. Marketing would still need to establish its purpose and decide whether a separate, optional request is appropriate. Until then, company size would stay outside the required support questions.