Offline services and paper forms

I wrote up some notes for someone to recap the advice I would give myself if I was doing the paper forms for the service again. Here they are.

Things to do or think about

Review current or similar services

Review the current service’s offline route. Or, if none, find the most similar service with current offline processes.

Think things with similar needs to:

prove address
prove name
financial history (bursaries?)

Talk to the service owners about issues. System side and user side. Talk to the contact centre and what themes they get (back that up with data as well).

Remember that you’re not just prototyping the form. But the process. So, letters, emails and call scripts. Before, during and after submission.

Get permission to go through filled-in forms. Review in a team submissions and note things that work well and don’t work.

Use:

sticky notes
pens

And write down notes, collect and analyse like you would a user lab.

Collecting observations and notes. Make sure to make extra notes where people have crossed things out and filled in their own answers as well as mistakes and misunderstandings.

People in this session:

researchers
designers
service owner
product owner

And anyone else you can get in the room. It is a rewarding but slow process. Be sure to draft in lots of assistance and help.

Feedback findings to contact centre team and those involved currently for things to implement or solve quickly.

Review your questions

Start from the beginning. You have your user needs and outcome they want to achieve. Ask what you need to get from them to help them achieve their goal.

Conduct a thorough question review

Keep these questions and answers in a spreadsheet. Yep. A spreadsheet.

Be sure to use their language not yours.

Remember that offline services can’t give instant validation. Clear instructions are key. But also remember that users can’t be redirected to the correct parts of a service as clearly either.

Make prototypes early and often

Typically you should aim to prototype:

paper form/s (you may need more than one)
page paper form will live on (standalone or on the service)
guidance document if needed (people don’t read these so keep it light)
call script
introduction letters or emails
letters or emails informing the user of an error
letters or emails confirming receipt of submission
letters or emails confirming success

Unlike a digital service, it is extremely easy to rapidly prototype paper forms and make them live.

Unless you are great at things like Adobe InDesign, rapidly prototype with Microsoft Word.

Share liberally.

Placement will go funny often but the key is being able to create lots of versions quickly that you can put in front of people.

We got to version 21 before we were happy enough to publish one.

Remember that you’re not just prototyping the form. But the process. So, letters, emails and call scripts. Before, during and after submission need designing too.

Get testing your process

Paper is cheap. Get testing questions and assumptions often. Test by:

doing quick crits inside your organisation
getting call handlers and contact centre staff to fill it in
doing pop-ups with similar users (Keep pop-up lightweight)
in labs where you can explore the whole journey end to end
in context. Home, office or similar
getting call handlers in the lab with you and simulating any phone conversations or emails
sending out early prototypes through the post to people on research panels (after they have agreed to do that, obviously!)

And be sure to test with people:

with access needs
on the go or working away from a home address
with non-nuclear family structures
with two addresses, no address or a difficult one (canal boat)

Get reviews from the wider organisation and experts and helpful friends around the design community.

As well as how well the form will help the user get what they want, ask:

how will they find the offline service
what conditions they would use it
how they will find the documents they need
where they would send the form
what standard of post
when and how they expect to hear back
how they would print the form or related documents off (if needed)

Key design principles

Design for context

Remember your user is not able to know they’re filling in things right. Keep instructions clear.

Don’t try to ask two things in one question.

Keep addresses, emails and phone numbers clear. Expect pages to go lost or not to be read correctly.

Know that users won’t have clear cut relationships and situations.

People divorce. Never get married in the first place. Move address. Keep old addresses in certain systems. Work far away from their “home” address. Live on a boat.

People also don’t print stuff out that often either. Find out how people will do that.

Consistent not uniform

Your offline service should try to match your online service in name and solving the same need.

Don’t have a different name for the service, but do:

change questions if they make more sense offline
provide additional information you may not on a screen

You don’t need to match any online service completely. Deviate where it makes sense.