The Question Protocol: How to Make Sure Every Form Field Is Necessary

Is That Question Really Necessary?

Your question protocol provides an opportunity to find out which questions you really need. Do not just accept the answer that a particular department needs data. Track down the exact people who actually use the data in their current work. You’ll be amazed how often they admit they don’t need the data any more or don’t need it at the moment, but might need it in the future.

Don’t need it any more? Easy, kill the question.

Don’t need it now, but might in the future? Easy, remove the question for now. Promise that you’ll reinstate the question as soon as they need the answer again.

On Web forms that are on their second or third version or have migrated to the Web from paper forms, it’s really common to find questions that have been left in the form by accident. Some examples:

• fax number—People do still use faxes, quite often. But these days, sending a fax nearly always happens after some other exchange by telephone or email. Many of us also move around a lot, working from home, client sites, or multiple offices. It’s usually more efficient to ask for a fax number that works at the point when you definitely know you’re going to use it than to collect a generic fax number some time in advance.
• postal address—Are you really going to mail something to a person? If so, when: Right now, using the data from this form, or at some future date, when the person’s address might have changed? Will you definitely be using snail mail or would email be more appropriate?
• marketing campaign data—In the past, marketers often asked questions like “Where did you hear about us?” Today, many marketing departments have moved on and now use Web analytics and traffic data to check where a site’s actual traffic has come from. This approach is both more accurate and places less burden on users. But the old marketing questions still live on, collecting data that is no longer useful.

Question Protocol: A Case Study

Sebastian Deterding shared a case study with me of his use of question protocols and also described how he extended the question protocol by adding another idea from our book, providing prefilled data in fields.

First of all, how Sebastian used the question protocol: “I’m currently working for a large German online retailer on patterns, antipatterns, best practices, and methods for designing checkout processes and recommended that we use the question protocol, because, in the past, using a question protocol has helped me in two crucial ways:

1. It was a huge help in terms of getting ammunition to overcome in-house politics. It helped us to defuse people’s vague aversion to change. In cases where someone said, ‘We can’t omit that field because XYZ needs the data,’ by systematically working through the protocol, I was able to get the responsible person in the relevant department to say: ‘Yes, we need that data, because ...’ or, often, ‘No, we stopped using that kind of data three years ago. Why do you still ask that question?’ Using the question protocol helps you jump over department fences and actually find and ask the relevant person, instead of relying on something-that-someone-heard-once. It’s also crucial that you get the relevant person’s views in writing and include an attribution with the person’s name and contact information—phone number or email address. If your product manager is the someone-who-heard-something-once, having in writing that ‘We don’t need this data’—and being able to say, ‘If you don’t believe it, just call XYZ’—is extremely helpful.
2. It helped us put things in perspective—for example, by starting discussions about whether the use of the data we captured when people would fill out our Web form for real would be worth decreasing signups. I can even see how, in principle, one could use this information to make an economic argument. For example, if the only use case for obtaining a customer’s telephone number is making direct advertising calls, each signup using a form has a particular value, each additional phone number you obtain equals only a particular amount of revenue, and omitting this field would increase signups by a given percentage, you can put all of that in a spreadsheet and calculate the net gain or loss from asking users to type in their telephone numbers.

“I also extended the question protocol. In your book, you explain that one should think about whether an answer has to come from a user or whether you can get the answer from data you already hold. I added some questions that became an effective way of igniting the zeal of our developers. I would challenge them by asking: ‘Can you come up with a way to prepopulate this field, so users don’t have to fill it in?’

“Next time I use a question protocol, I’m going to walk it around all the departments that use a form’s data, then I’m going to walk through it with my development team and systematically ask them these questions:

• Can we prepopulate the field from data we definitely already have from a user?
• If not, can we guesstimate the answer from the user’s browser history, using geolocation, or from a cookie, then let the user edit or confirm it?
• If not, can we ease manual entry in some way—for example, by offering a format or some plausible choices?”

Question Protocols Are Time Consuming, but Valuable

I have to admit that question protocols aren’t the quickest user experience tool we have. They take effort, as Sebastian’s story shows. My experience is similar: Finding the right person in each department who can tell you whether they really need the answers to specific questions takes time and persistence. Running a usability study would be quicker, simpler, and give you the users’ view of what they’re willing to tell you.

If your organization is small, a form is short, and you can add or delete fields without having meetings to discuss them, you probably don’t need a question protocol. Do some usability testing instead, and make changes based on what you learn.

But if you find yourself in meetings where everyone is arguing about whether a field is necessary, you’ll learn to love question protocols. They’ll be a bit of extra work in the beginning, but will save you a lot of time overall.