Published on
There are many reasons to move paper or PDF forms online. When we are asked to do this there is usually an expectation that this will be a quick process. And an assumption that simply copying the paper form into HTML will be sufficient.
Published on
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:
And occasionally:
Number 1 and number 3 are opposite ends of the same problem. We don't have clear answers to these questions:
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.
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.
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.
If I tried to change everything about the way these departments worked right off the bat, they would have resisted every step of the way. Moving just a part of their workflow online made them eager to go completely digital
In the same article Josh Gee talks about some departments keeping their manual support processes and systems in place.
Some departments moved to a more digital process; some literally print out submitted PDFs and put them in the wooden department inbox. Either way, customers can submit online and the system is saving time.
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.
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:
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.
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.
If we are designing the form only it will need to work with the existing internal process, whatever that is.
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.
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?
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.
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.
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.
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.
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.
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.
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.
These are webmentions via the IndieWeb and webmention.io.
+39 
+3
+1
Paul Moran