Designing Forms - Minimum viable design

Friday the 30th April was the 3rd cross Government meet-up on forms and the second one I've spoken at. My talk this time was called 'Minimum viable design' and was mostly a list of questions I think we need to answer before we start re-designing legacy forms in bulk.

Form builders and Defra

My first talk was 'Forms, Form builders and Defra' and discussed the 2 separate form builders Defra had developed over the previous 18 months.

The first one was built to speed up the repetitive process of getting around 1500 PDF forms online as part of a new digital service. The Form builder allowed those existing PDF's to be scanned and then converted to HTML replicas.

The second form builder was built to try to reduce the cost of creating digital services and was aimed at parts of Defra that didn’t have the funds to pay for a full delivery team to go through the usual Discovery, Alpha, Beta delivery phases. That form builder had a more traditional drag and drop type interface that could be exported to production code.

Both form builders sooner or later ran into the same problem, these legacy forms still needed to be designed and the tools we had built couldn't help us with this part of the process.

Online isn't always better

There are a lot of benefits to putting paper or PDF forms online, HTML is more inclusive and accessible, there's wider device support and the forms themselves will be easier to find. But simply copying offline forms and putting them online does not work.

That could be because the forms we are copying were poorly designed in the first place. Or it could be because we are changing the way people interact with those forms.

Some of the benefits of paper forms that we can lose when we put them online include:

• they can be read from beginning to end so users know exactly what's expected of them before they start
• they can be re-visited or part completed so users can go and get information they may not have had to hand
• they can be filled out in the order of the user's choosing
• they can be edited or checked before they are sent off
• they can be filled out by more than one person, this was particularly relevant for our first form builder project where users would treat the forms almost like a Google doc editing or updating answers based on input from others

Process over tools

We moved on to do a short piece of work trying to understand the full process involved in getting legacy forms designed, built, and online. As part of that work we identified some key stages.

Upfront consultation

Firstly an upfront discussion with the business area would be needed to understand their current service, the form, and any known issues. This would be carried out by a developer and a designer to understand any technical constraints and any parts of the form that would be particularly difficult to replicate online.

A design phase

Then there would be a design phase with the constraints of time and cost to consider.

A clear sign off point

A clear sign off point from design to front-end build would be needed to keep projects quick and on budget.

We then created some pre-defined products which we thought would help speed up the delivery whilst maintaining quality and standards.

The 3 products were:

• re-design the PDF or paper form, because sometimes online is not better especially if we have budget constraints
• basic HTML form with simple input types, non-sensitive data, and low transaction numbers.
• advanced HTML form with higher numbers of transactions, complex design, and/or sensitive data.

Each one of these products was then mapped out so we could start to understand which parts of the process would benefit most from automation. As well as which would be the most time-consuming and the most costly.

This is where we can start to see exactly where our form builders can help, which for now is in the front-end development space.

I wrote about this process in more detail last year in Put that form online!

The design phase

The part we didn't dig into in any real detail was the design phase. We know the forms need to be designed to work in a new medium. We need to work out how many design, iteration, and test cycles we need to feel confident that we have done this successfully and improved the form for its users.

The task of the form design working group will be to answer this question, focusing specifically on design and how much design is enough.

Before we can answer that question though there are a few other things we need answers to.

Question 1 - should we be doing this?

The first question we need to answer is should we be doing anything in this space at all?

A form is usually just one small piece of a much larger service and sometimes that form's very existence is a result of flaws in that service. For example, at Defra we had a request to redesign a PDF payment query form.

This form wouldn’t be needed if the service clearly explained why a decision had been made in the first place, which is part of Lou Downe’s 15 principles of good service design.

Sometimes however we have to accept that we can't redesign a whole service. If there's limited trust, funding, or time we need to focus on making the existing form easier to use for the people that need to use it.

By doing this we can:

• build trust with areas of an organisation we don’t usually work with
• create more inclusive, accessible interactions for users
• increasing consistency across government
• improve data quality and efficiency for internal processes

Question 2 - How or should we meet the Government service standard?

A scary question to ask but assuming we do carry on with this work what standards should we be held to?

The Government service standard sets the bar for how we design good services in Government, but what if a form is needed in a hurry? Or we need a lot of forms? Or there’s no money?

Do the rules change? Or more importantly Should the rules change?

A few years ago MoJ blogged about how they designed, built, and launched The child funeral fund service whilst meeting the service standard. They did it in just six weeks!

So we know it is possible to meet the standards at pace, we also know that none of the 14 points in the standard are linked explicitly to timeframes. But what about cost? And scale?

Some of the most difficult points to meet within those constraints would be:

• Understand users and their needs. This requires a lot of discovery and research activities which take time and can be costly.
• Solve a whole problem for users. We couldn't do this if the form was just one piece of a larger service

What we really can’t do is design forms that take us backwards, if we are putting forms online there must also be an offline version for people who either don't want to or can’t complete the online version. Both of these formats must be designed with the same amount of care and attention.

We also must comply with The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.

Question 3 - When does a form become a digital service?

If there are to be different rules for forms and for services then we need a clear and consistent definition of both a form and a service. Without this, there's a risk of undermining the work already done by GDS to implement government-wide service standards, and we really don’t want to do that.

Question 4 - Should we use GOV.UK branding?

Should we use GOV.UK branding? Or more specifically if we’re not meeting the service standard are we allowed to use the GOV.UK branding?

If we do then again we risk undoing some of the hard work that’s gone into building trust, and the design standards associated with GOV.UK. If we don't then we start from scratch and lose all of that built-up trust.

We would also be adding extra design time to create branding or page templates for each organisation and arms-length body.

Question 5 - How do we upskill and/or share knowledge so design does not become a bottleneck?

Another of the original problem statements was around the need to design forms at scale, so how can we make sure this is achievable even if we are just 1 person in a team of many? What we don't want is for design itself to become a blocker to re-designing legacy forms.

So how much design do we need?

To try to make this open-ended question feel less overwhelming I’ve started to put together a list of outcomes to help scope the work and to make sure we're adding value.

The most important first step will be to establish a relationship between the form design working group and the GOV.UK Design System community. And equally to establish a relationship between the form design group and GOV.UK service manual.

Then between us to try to agree on an assurance process for form design in Government.

Standards and guidance

Other possible outcomes to work towards would be definitions and standards including:

• a clear and consistent definition of a form and of a service
• form design best practice or form design standards
• a best/quickest/cheapest and most efficient process for designing better forms. This is something we might only get by designing forms repeatedly and learning/iterating as we go

Tools

Finally tools, could we create a centralised place for reusable things like:

• process and guidance around question protocols
• task-based patterns like apply for something, register for something etc
• page templates or other tools to help us to easily and consistently brand forms

Next steps

The next steps for this group are to:

• collect a list of interested people
• review the questions and outcomes mentioned here
• plan how we start achieving them, probably beginning with some online workshops

Share on Bluesky

Share on Twitter