Rewriting a form filler flow

Scenario

Screen Shot 2021-06-18 at 6.22.26 AM.png

My passport was lost in the mail. I went to the Department of State website to report it.

 
have passport book yes.png

On the final review page of the form, I was surprised to find that, somewhere along the way, I had indicated that I still had the passport I was reporting lost.

Wasn’t this a form for reporting my passport lost or stolen?

 

What I did and how I felt

your most recent passport.png

I clicked “edit” and was returned to this page. “No,” I clicked again, “I do not have the passport book, it was lost.”

I was brought back to the review page, only to find that the review line hadn’t changed. I tried to edit it again, with the same results.

Frustrated, I was about to email the help contact when I realized that this line of the review indicated my response to the previous question: whether the lost passport was in the form of a book or a card.

 

The problem

The review page was ambiguous. “Have Passport Book: yes” seemed to mean that I still had the passport in my possession. In fact, it meant that a passport book (rather than a card) was lost.

The proximity of the questions made the ambiguity worse. When I clicked the link to edit my response, nothing indicated which question I should be editing.

 

A band-aid solution

revised review page.png
  1. Revise the language on the review page.

  2. Highlight the corresponding question when editing.

 

Going deeper

This was not the only moment of ambiguity I encountered in filling out the form. The ambiguity was symptomatic of a larger problem.

If I were responsible for improving this process, I would begin by closely investigating the form filler flow, identifying as many points of friction as I could. With this deep familiarity, I would then ask questions.

 

Asking questions

First, I would work to understand the Department of State’s goals for this form.

Are there reasons why it is structured the way it is?

  1. Why is it a form filler process, that requires the user to print and mail the form at the end? Can the entire reporting process begin and end online?

  2. What are the various use cases of this form? In what circumstances do people use this form?

  3. Are there adjacent use cases that require a separate form? If so, would it make sense to consider integrating those multiple forms into a single point of contact for the user?

  4. What is done with the information once the form is complete? What internal processes are triggered and what information truly matters for getting things done internally?

  5. Are there any questions that can be removed? Are there any questions that should be added to improve internal processing of the information?

Researching user experiences

Second, I would conduct or commission usability research.

  1. Survey

    We would want to consider where in the flow to ask users to fill out the survey. If we wait until someone has successfully completed the application, we are excluding those who abandoned the process midway.

  2. Testing

    We would enlist users to carry out certain tasks and then ask them follow-up questions when there are moments of friction.

Empathizing

What are the human stories behind these forms?

Asking this question would help us establish voice and tone. What emotional states do people bring with them when they fill out this form? Here are two examples.

One person might have accidentally put their passport in the washing machine. They are slightly annoyed at the inconvenience and wait several months before going online to figure out what to do about getting a new one. They value efficiency.

Another person might have experienced a theft while traveling, losing their passport along with all of their other possessions. They are anxious about identity theft and getting through airports without issues. Reporting the passport lost is one of many things they need to do to pick up the pieces. They value reassurance.

Mapping journeys

Next, I would synthesize the data and map out user journeys.

Onboarding

  1. What information do all of the users need to know at the outset?

  2. Is there some information that is nice to know but not necessary? Is there information that some use cases need to know but not others?

Flow

  1. How can we ask questions in a conversational way that is oriented to the user’s knowledge, while at the same time fulfilling the Department of State’s goals?

  2. How can we represent information to some users on an as-needed basis (in the form of tooltips or targeted error messages, for example), rather than to everyone in every case?

Wrap-up

  1. How can we conclude the flow in a way that ensures users will know what they should do next, and what to expect next?

Accessibility and inclusion

What adjustments can we make so the form filler is accessible to the visually impaired, to those who do not speak English, and to those with a range of educational levels?

Writing!

Armed with these data, structures, and guiding principles, I would draft a new form filler flow.

I would seek feedback from team members and stakeholders, and revise until we had a draft we felt ready to prototype for user testing.

Prototype testing

I would use a range of methods to check our work.

  1. A/B testing

  2. testing task flows

  3. post-test user interviews (to ask about the experience beyond their ability to complete a task)

Iterating

I would repeat the process of writing, revising, and testing as long as resources and time permit…

…without letting perfect be the enemy of great.