HOWTO: Ask Questions that Get Good Answers - Web Forms

I love designing with words. I like to think about all of the possible answers to a question so that I can preempt with better answers, thereby saving users time and money. This article is a study in the hows and whys of question-asking in web forms.  One phrase that struck me was, "It was a huge help in terms of getting ammunition to overcome in-house politics." Read on:

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

By Caroline Jarrett June 7, 2010

“A question protocol is a tool for finding out which form fields are required….”

One of the nicest things about being an author is that, from time to time, people write to say they enjoyed our book, Forms that Work: Designing Web Forms for Usability. Of course, I write back and ask what they like about it. And surprisingly often, the reply is “question protocols.”

What Is a Question Protocol?

A question protocol is a tool for finding out which form fields are required and lists

• every question you ask
• who within your organization uses the answers to each question
• what they use them for
• whether an answer is required or optional
• if an answer is required, what happens if a user enters any old thing just to get through the form

The question protocol is different from the form itself, because it’s about how you use the answers.

Each Question Has a Cost

“A question protocol can help to create a discussion about the true business value of each question a Web form asks.”

Why would you want to do all of this work? Because each question in a Web form has a cost. There is a cost to the organization that publishes the form, which must process and store the answers.

From the user experience point of view, we’re also interested in these hidden costs:

• If there are too many questions in the form, you’ll lose users. Fewer conversions, lost sales, greater use of non electronic channels—all are hidden costs.
• You’ll also lose users if there are questions in the form that users consider impertinent or irrelevant—or, even worse, you’ll get made-up data. If you find that your users have names like John Doe or Mickey Mouse and live on Anystreet, in Anywhere, you’ve collected a lot of rubbish that costs a lot to clean up.
• Plus, there is the further hidden cost of loss of goodwill. Even if users struggle through to the end of a form and answer honestly, if it’s more work than they expected, they’ll resent it.

A question protocol can help to create a discussion about the true business value of each question a Web form asks. If you know exactly what decision your organization will make based on the data a Web form collects, you can quantify the value of that decision and weigh it against the cost of collecting the data.

Is That Question Really Necessary?

“Your question protocol provides an opportunity to find out which questions you really need.”

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 … extended the question protocol by adding another idea…, providing prefilled data in fields.”

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

“Finding the right person in each department who can tell you whether they really need the answers to specific questions takes time and persistence.”

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.

reposted from http://www.uxmatters.com/mt/archives/2010/06/the-question-protocol-how-to-mak...
Buy Forms that Work: Designing Web Forms for Usability

"The humble form: it may seem boring, but most of your website's value passes through forms. Follow Jarrett & Gaffney's guidelines, and you'll probably double your online profits." - Jakob Nielsen, Principal, Nielsen Norman Group

Posted via email from PrePosterous...or Not