How piecemeal prioritization leads to frankenforms
When was the last time you found yourself filling out a form and wondered, “Why do they even need this information?”
Have you ever entered a random number or fake number on forms that require a phone number?
In general, the more questions a form has, the more people it will irritate and turn away.
So why do companies require people to enter things like their phone numbers or home address when they’re not necessary to complete the task at hand?
A form with many required questions is often a sign that there are lots of cooks in the kitchen and no one quite knows what’s for dinner.
Here’s an example of just how bad it can get — Sara Wachter-Boettcher, co-author of Design for Real Life, gives an example of what can happen when organizations create forms that fail to consider the user’s experience:
I’m filling out a new-patient form online for my doctor’s office when I see it, sandwiched somewhere between “Do you smoke? and “Has anyone in your family had a stroke?”:
Have you ever been sexually abused or assaulted? Yes/No
No context, no indication how this information will be used. No box to tick for, “Well, yes, actually, but that’s not why I am visiting you and I don’t know you and I have nothing to be ashamed of and I’m not afraid to talk about it but really I’ve done my talking already and mostly I just want my annual exam, not a bunch of prying questions or sympathy or anything, actually, from you." …
At my appointment, the doctor says, “So, you were sexually assaulted.” It’s not a question, but she pauses expectantly.
I consider telling her more, but I don’t. That history is mine. I get to choose when it’s trotted out, and for whom.
“I’m sorry that happened to you,” she says finally, filling the silence with the phrase I, too, learned, back when I was a crisis worker. She moves on with her checkup.
I stare at the ceiling, thinking about that checkbox. So simple, so impossible:
I don’t know why that question existed. I don’t know who asked for that information, where it’s stored, or how they intend to use it. Is it collected for statistical purposes only? Are they trying to identify victims who need help and care? Am I going to be asked about this every time I have the flu or need a prescription refilled?
I think about asking the doctor, but I don’t. Instead, I imagine the what ifs:
What if they’d labeled this section of the form as optional?
What if the question also asked whether I wanted to talk about sexual assault or abuse with my doctor?
What if the form asked if I needed help?
What if it explained why they were collecting this data?
What if it allowed my response to be anonymous?
Most of all, I wonder, what if this is it? What if this awkward interaction is the only reason that question was asked? What purpose was it intended to serve? Was it successful?
Has anyone ever thought about any of this?
Each question has a cost.
Your company’s online forms probably won’t be this invasive, but you don’t have to go this far to wind up driving people away by requiring too much.
Establish a question protocol
To help prevent unnecessary questions from creeping into your form, develop a question protocol. Caroline Jarrett defines a question protocol as:
A tool for finding out which form fields are required and lists:
every question you askwho within your organization uses the answers to each questionwhat they use them forwhether an answer is required or optionalif an answer is required, what happens if a user enters any old thing just to get through the form
To develop a question protocol, you have to define the core business objective for the form.
Is the primary goal to facilitate the transfer of money into company coffers? To generate a lead? To book an appointment?
Write it down. It may seem so obvious that you feel dumb writing it down, but write it down and share it with the employees you captured in your people-inventory all the same.
And then proceed to document everything else for the protocol. The result could be a straightforward document, or it could be something that more resembles a service blueprint. A service blueprint is in some ways the counterpart to a customer journey — it puts the form in the broader context of what the organization needs to support the objective that your form supports.
You’ll use the document or blueprint to try to keep everyone aligned with the original purpose of the form.
See, once you start poking around, you’ll find everyone has different priorities. People in one department will want to gather contact information to meet their objectives, while others may be happy to forego some data collection in the interest of immediate economic benefits. It’s good to identify secondary goals as just that — secondary — early in the process.
Over time, people may try to advance questions relating to secondary goals as being just as valuable as the main objective. They may insist that phone numbers, addresses, and other fields be required to complete the form.
That’s when your blueprints and maps come in handy. You want to try to prevent the form from growing into a Frankenform that requires people to share everything, including a DNA sample, with the organization.
Land a compromise
Here's a trick I’ve found when it comes to gleaning more information from users without burdening the main form with a million questions.
Upon submission, have the form automatically redirect people to a hidden landing page on the website. This thank-you page can include a second form that asks just a couple of questions that are of particular value to the organization — things like:
How did you hear about us?
What made you decide to (donate/schedule/contact us) today?
Can we send you our brochure? (If so, then ask for their address.)
You’d be surprised how many people will “take one minute to answer two questions.” This lets you gather more information related to secondary goals without putting your primary form at risk.
Be stupid obvious
Question protocols and blueprints support an underlying pattern when it comes to creating forms: The things you assume to be dead simple, obvious, and immutable are rarely what they seem.
Time will work against you. Over time, understanding unravels. Teams fall out of alignment as new people come along with different values, technology changes, and people simply forget why they chose one path over another.
Question protocols, journey maps, service blueprints … They’re all just a means to maintain alignment within the organization. Successful design is documented design.
Thanks for reading,