Put that form online!

We need to get this paper form online, or more commonly we need to get this paper form online fast!

Whenever you hear that sentence it usually leads to one or both or these sentences:

1. Just do it (we need this now!)
2. Use a form builder - it will be faster.

And occasionally:

3. Let’s start an 8 week discovery to understand whether we need that form at all.

Number 1 and number 3 are opposite ends of the same problem. We don't have clear answers to these questions:

1. Why does the form need to be online?
2. How is this better?

Let’s do a discovery

Users don’t need to fill out forms.

This isn’t new information, a form is usually one small piece of a larger service. Sometimes the form's very existence is a result of flaws in that larger service.

A payment query form for example wouldn’t be needed if the service clearly explained why a decision had been made, point 13 in Lou Downe’s 15 principles of good service design.

During discovery we learn about the users of a service and their needs. We get to the root of real problems, instead of papering over cracks by fixing symptoms of those problems.

Keeping the above form example we can design a service that makes sure users get the correct decision, and that they understand that decision instead of re-designing a query from.

Priced out

Discovery projects are expensive.

There is nothing more frustrating than having to walk away from a project, leaving a difficult to fill out form in place.

There will always be departments and services with limited or no funding. No one gains anything if we price ourselves out of doing any work at all in these areas.

In these cases we have to forget about discovery projects and address the problem form as best we can.

Fixing symptoms of larger problems is not ideal, but it is a step in the right direction. We may not be solving a whole problem for users, but we are making one small piece of a service easier to deal with.

To build consistency across a large organisation we need to find ways to work with both services with money and services without money.

Incremental change

Even if there is funding there can still be resistance to looking beyond the problem form.

It’s rare in large organisations to develop services from a blank canvas. Most of the time the business process, technology and policy that underpin the forms people see are already in place.

To completely redesign an existing service requires some degree of business transformation it takes time, money and trust. To build that trust we first have to demonstrate value for money.

Adding value incrementally is a good way to do this.

In the same article Josh Gee talks about some departments keeping their manual support processes and systems in place.

There’s no shame in designing only parts of a service. It takes time to move from designing digital products to end to end service design and then to organisational change.

The diagram below from FutureGov details steps of design maturity in organisations also described as level of ambition an organisation has for changing how it works and what it does.

We can’t treat every service the same way. Sometimes we can eliminate forms through good service design, sometimes we have to design better forms.

Most importantly the service users should never suffer from us clinging on to idealistic service design principles.

Just do it (we need this now!)

Sometimes we need to do things quickly.

So, the todo or not todo a discovery question has been answered for us. But we still need to understand the form before we put it online.

Generally speaking 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 will be easier to find.

Sometimes though online is not better, benefits of paper forms include:

• They can be read from beginning to end allowing users to understand exactly what's expected of them before they begin
• They can be re-visited and/or part completed allowing users to gather information they may not have had to hand (without a complex save and return or password feature)
• They can be filled out in the order of the user's choosing
• They can be edited/checked before submission
• They can be filled out by more than one person

Ask questions

Recreating offline forms in HTML does not work.

Maybe because the forms we are copying were poorly designed in the first place. Maybe because we are changing the way people interact with those forms.

Either way we need to understand the form and the people who use it before we do anything. When designing forms at pace we have to be sure that what we produce provides a better experience than what we already have, for all parties.

The form

• How many transactions are there each year?
• How long will it take users to complete?
• Is the form completed by multiple users?
• How frequently will the form need to be updated?
• Are any elements of the form not catered for by existing design patterns?
• Are there any loops in the form or repeat actions?
• Will the form require a signature or a witness signature?

By analysing the form we can quickly work out whether or not it will work online, is any bespoke design needed? will standard components be enough?

We can also work out the level of risk associated with changing the form at pace and without any upfront research.

Internal process

• What is the current internal process?
• Can we improve this process?
• Will this process still work with a digital form?

If we are designing the form only it will need to work with the existing internal process, whatever that is.

Data

• What is data used for?
• How sensitive is the data?
• Is there any money transfer involved?
• Where does the data collected currently end up?
• Are there any dependencies or interfaces to other systems?

There are both security and design considerations when handling sensitive data online. There are also impacts on the degree of testing needed and hosting environments.

Standards

• Who needs to approve a lack of discovery?
• How will we deal with continuing support?
• How will we measure success?

Time constraints are not a reason to lower our standards. Any form we design needs to meet inclusive design and accessibility standards.

These things are often the first thing to slip when a project is urgent, we need to find a way to make sure this doesn’t happen. If that can’t be achieved then maybe the paper from is better after all?

Predefined products

In early January we used the above questions to quickly review 3 forms and to provide recommendations to the business area.

The recommendations came from a set of predefined products. By having defined solutions to common problems we can hopefully speed up the delivery whilst maintaining quality and standards.

Do nothing

Some forms will need bespoke design work, research and sensitive data handling. We might also identify that the risk of delivering at pace with little research is too great.

I honestly believe it's better to do nothing than to throw a form online, if we can't be sure that the online version won’t create more barriers than already exist.

Redesign the PDF or paper form

If a form is creating problems for users or for our own internal processes it needs to be redesigned, not just put online.

If a form has multiple users entering data, or is filled out over a period of days an online solution would need to accommodate this. Suddenly we are designing more than a simple one off transaction.

In cases like this the quickest solution could be to redesign the existing PDF, removing complex instructions, using clear language and structuring the document correctly.

Simple HTML form

If a form has only standard input types, low transaction numbers and no sensitive data we can probably design and build it safely and quickly in HTML.

Advanced HTML form

With more complex interactions and sensitive data comes increased risk. These forms can still benefit from being designed in HTML, but there will probably be more steps in the process.

Use a form builder

As well as doing things quickly we also sometimes need to do things in bulk.

When a process is repetitive we tend to use tools to speed things up and/or to remove the burden of monotonous tasks.

Enter Form builders!

There’s never a discussion on form design without form builders being spoken about.

The thing is, it feels as though we jump to form builder solutions before we fully understand where in the process we could benefit most from automation.

If we already have a set of questions and a set of products we need to work out how we can deliver these products efficiently and repetitively without losing quality.

I spent some time mapping out a potential process to get a form re-designed and online, working with each specialism to get a rough idea of what could be achieved on a tight budget and a small time frame.

I ended up with the following project stages:

Upfront consultation - we need to define quickly if we can add any value and if so how. This can be done through an upfront consultation involving design, development and subject matter experts.

Getting commitment to the process from stakeholders upfront should help keep the project on track.

Design & user testing - not the usual continuous iteration, design and research but a set cycle of design and test phases. For a streamlined process we need a clear sign of point where we move from design to development.

How much design and user testing is enough? This is the real question we need to answer, we won’t get this answer until we test the porcess with real forms and real metrics.

Development - once a design is signed off, the form can be built in production markup. Having a clear sign of point on design means there will be no moving goal posts to contend with.

QA & test - the faster we work the more importance is placed on quality assurance including functional testing, browser and device testing, accessibility testing and load testing.

Continuous improvement / support - there’s still a lot of questions around how we measure success, and how we make changes when they are needed.

If we are rolling out digital forms one at a time and have a dedicated team to do this then they could also look after things like small improvements, performance checks and policy updates.

If that’s not the case we could end up with out of date HTML forms, or forms with incorrect guidance. This is another area where paper and PDF forms could be simpler to work with.

This process to date remains untested, but as a theory suggests a form builder could save us a small amount of time during the front end build stage.

To understand where the greatest efficiency and cost savings can be made we need to run through this process several times improving it as we learn.

More cost than benefit?

A form builder requires maintenance, any changes to components need to be added as well as new components or patterns. There's also support and training to think about.

Designing in production code may be beneficial, but could also be restrictive, early designs are often done on paper or in a quick flow tool that can be updated and worked on collaboratively.

If we do move the design process into a form builder tool there would also be the upfront design costs for the tool itself to consider.

Share on Twitter