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?
Open vs Closed
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 and radio buttons, 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.)
Asking Good Questions
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:
- Using the wrong metric to measure customer service;
- Or, trying to ask two different things at once.
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.
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:
- Know your audience
The language you use should fit your audience. If your form is for the general public, remember that not everyone has the same literacy level. Use plain language – short sentences and everyday words.
What if the general public isn’t your audience? Reading through postings in the Atlassian Community, I notice that many participants are highly technical, but may not be native English speakers. Writing for this audience, I might choose a longer, more formal word that has a latin root (thus recognizable to speakers of other latin-based languages) over a shorter, more common word. It’s all about who you’re creating the form for.
- Provide context
Organizing your questions into logical sections will help provide context for the user. Depending on what you’re asking, that may or may not be enough context. Remember that the user doesn’t know what you know.
Field level help text is a great opportunity to provide more context. Including an example can help the user understand what kind of response you’re looking for.
If you’re asking a question that can seem intrusive, tell the user why you’re asking and how the data will be used.
Finally, if you’re asking for information the user may not know how to find, help them out. For example, tell them where to find a version number for their software or a serial number for their hardware. You can put this information directly in your field help text, or use your help text to point to another page with detailed instructions.
- Use neutral words
If you’re truly trying to get the user’s opinion, then strive for neutral wording. The words you choose can influence the answer, so avoid phrases that indicate what you think the correct answer should be. And if you’re wondering what leading questions look like, grab a political survey put out by a political party.
You’ll also want to avoid using absolutes – words like all, always, never, etc. Including an absolute means you will find the exceptions that prove the rules. You can improve your questions by simply deleting those words.
Getting Text Fields Right
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 are also 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.).
You can also create your own text field types using ProForma’s Regex feature. Regex allows you to 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:
- Account numbers
- Phone numbers
- IP addresses
- Currency amounts
- References to ISO standards
- Serial numbers
Note that you’ll want to tell your users what patterns the field accepts. Use field level help (the Description property in ProForma) to provide instructions and examples.
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.
Other articles in this series:
- Why Form Design in Jira Matters – How you design your forms will impact the quality of data you receive, and much more!
- Layout and Flow: Creating User-Friendly Forms in Jira – Form layout affects completion rates and user frustration. We’ll discuss the right way to do it.
- Writing Good Form Questions in Jira: Part 1 – How do you choose the right words, field types and validation levels? This article will dig into the nitty gritty of creating good form questions.
- Writing Good Form Questions in Jira: Part 2 – Choice questions are great for collecting structured data. We’ll look at the options for choice questions and discuss ways to influence, or mitigated influence on the user.
- Things to think about when converting forms in Jira – Bringing a process into Jira for the first time? Don’t just copy forms straight across. This is a chance to make improvements.
- Efficient Jira Screens and Jira Service Desk Request Forms – Jira screens and JSD request forms aren’t the same. Here’s how you can make each one work for its audience.
- Tips for Creating good forms/screens in Jira – Learn how you can leverage Jira features like tabs, workflow transitions and icons to create better forms and screens.
- Form Design Best Practices: What you can and can’t do in Jira – Now that we know what good form design means, we’ll hone in on which practices can be applied to Jira and Jira Service Desk
- Use cases – We’ll also include a series of use cases illustrating how using forms expands what you can do in Jira.
- Form audit – Finally, we’ll take a bad form and transform it to an awesome, user-friendly, data collecting machine.