*This is the third article in our series on Form Design. Previous articles covered Why Form Design Matters and Form Layout and Flow.
Questions, and the input fields that collect their answers, are the heart of every form. Getting your questions right will mean getting your data right. Well-designed questions also minimize frustration for the user. You'll need to decide what field types to use, what context to provide, how to word your question and how much validation to include. Think about why you're including each question. What data are you hoping to get? Then consider the user's point of view. How should you create the question in order to make it easy for them to respond with the data you're looking for?
Questions come in two general varieties, open and closed. Open questions (text fields) let the user type in what they want to tell you. Closed questions (check boxes, combo boxes, pickers, radio buttons, and select lists) let the user choose an answer from options you provide.
They each have their advantages. Closed questions are good for users because they are easier to interpret and quick to fill out. They’re good for you because data comes into your database in nice categories, with consistent formatting. Data from closed questions is easy to aggregate and report on.
Open questions are more work for the user. They have to interpret what you're asking, decide what they want to say, and then type it in. However, open questions ensure that the user has a chance to say what they want to say. The user may be looking for an opportunity to tell you something you didn’t think to ask. While open questions don’t make for tidy reports, they allow users to provide information which can lead to disruption, innovation and continuous improvement. If your forms use purely closed questions, you may force the user and a service agent to comment back and forth in order to get important details.
Finding the right balance of open and closed questions will depend on the purpose of your form. Consider including at least one open question on your form. This could be an overview question up front – like the Description field in Jira – or an optional “Comments” field at the end. You can also mitigate the restrictiveness of closed questions by including an “Other” option. (We’ll dive deeper into closed questions in the next article.)
Teachers are fond of saying that there's no such thing as a stupid question. I beg to differ. Stupid questions are questions that don't ask what you want to know, or questions that try to ask too many things at once.
Whenever I call my credit card company I immediately get a follow-up email that asks:
The first part of the question indicates that they want to know if I'm happy with the customer service I received, but the second part of the question asks something completely different. The question is either:
Personally, I would never choose or recommend a credit card based solely on customer service. Other factors - interest rates, cash back and annual fees play a big role. Since I'm middle-aged my friends and family members have already found credit cards that work for them. Giving an honest answer to the question might reflect badly on a perfectly competent agent who took my call. The result is that, unless I received really bad service, I don't answer the question.
Resist the temptation to use double-barreled questions as a strategy for keeping your forms short. Yes, you want to be brief. That’s why you’re only asking questions you really need the answers to. But if you lump two questions into one, you won’t know which part the user is answering. The agent and the user will have to exchange comments back and forth to clarify, and you’ll end up taking up more of the user’s time than you would have if you’d just included two questions in the first place.
Language
How you word your questions matters. Choosing unambiguous wording will mean reduced frustration for your users, and fewer errors in the data you receive. When writing form questions:
Rachel Wright provides examples on her Custom Workflow Documentation form.
While text fields collect responses to “open” questions, that doesn’t mean that you don’t have any control of the data you receive. Using appropriate field types, formatting and validation will ensure you get data you can use, while still allowing users the flexibility they need.
Field Size and Type
Text fields are not one size fits all. When choosing the size of your text fields (two options in Jira, three options in ProForma) remember that the size of the field should be proportional to the amount of text you want the user to input.
Text fields also come in many varieties. Along with various sizes (single line, multiple line/paragraph), there may also be number fields, email fields, url fields, etc. These fields have been formatted and validated behind the scenes to ensure that the user can only enter certain kinds of information. Using the correct field type means better data that can be used for other functions later (perform calculations with number questions, export a spreadsheet of email addresses to make a contact list, etc.).
Pattern Matching
Forms app may also allow you to create your own text field types using . Regex lets you create text patterns that the user’s input must match. These can be simple or complex expressions, and are a great way for collecting properly formatted data. Regex patterns are often used for collecting:
Note that you’ll want to tell your users what patterns the field accepts. Use field level help to provide instructions and examples.
Validation
Finally, deploying validation rules – such as word/character limits and value limits for number fields – not only ensures clean data, it allows teams to build their business rules into their forms. As above, you can save time and frustration for your users by letting them know, either in the question itself or in the help text, what the limitations are.
Following the advice above will help make your text questions easier for your users to understand and respond to. However, chances are good that most of the fields on your forms will be choice questions, so we'll look into the best practices for creating choice questions in the next article.
Jennifer Choban
1 comment