-
Notifications
You must be signed in to change notification settings - Fork 2
Best practices for developing interviews
Use one file until it becomes necessary to separate into multiple interview files.
Reasons to separate:
- Multiple authors working at same time
- Question set will be re-used in a different interview
Use a mandatory code block at the top of the interview which lists the variables in the order that you want them to be gathered. No other questions should be made mandatory. Avoid using the need statement if at all possible (sometimes it seems its necessary to trigger seeking variables for sending an email).
Each question in the interview file should have an id tag. Use id tags for mandatory code blocks as well. id can include spaces, should be descriptive. It will be used for tracking in Google Analytics as well as debugging.
A "welcome" splash screen is a good best practice while developing an interview (it will help with performance of the playground variable list). It's also a useful orientation for most interviews, except very short ones aimed at advocates who don't need orientation to the tool.
Your users are likely to skip through content to find the key information they need. Use question/subquestion specifiers consistently to guide users to important information. Typically the question field will be a heading, and the subquestion will have explanatory text. Keep this text as short as is clear and readable.
Users will skip your explanation text whenever they can. Make sure the fields have unambiguous labels so they can be answered by most people without reading the question or subquestion text.
Forms often have compound questions (e.g., "Are you over 50 or a veteran?"). There's no excuse to do this in Docassemble. You can easily use a small code block to combine multiple questions into one. It's much easier for users to answer one question at a time.
Group fields about the same basic topic (i.e., a user's first and last name) on the same screen. Don't go crazy. Avoid adding more fields than can easily be read without scrolling on a standard desktop screen. Probably 3-8 is ideal. There are valid reasons for exceptions.
Group multiple screens so they follow in a logical sequence. E.g., follow-up a question about the user's name with the name of their spouse on the next screen.
- If you have a small number of valid responses, use radio buttons as opposed to a drop-down menu. Radio buttons are easier to select on a smartphone, and have the advantage of displaying all options at once which helps the use select the best answer. Dropdowns are appropriate when there is a limited but large set of valid responses (maybe > 8).
- If you have a small set of likely responses, either use a combobox or use radio buttons with "other" rather than a free text field. Not all users will understand comboboxes, so pay attention in user testing.