Use plain, clear, and concise instruction text.
Eliminate any unnecessary or redundant introductory text, such as duplicate form titles, wordy descriptions, and information that’s provided elsewhere in the form. Use plain language; avoid overly technical language and jargon.
Before
Sites Software Exception Request
Request for Sites Software Exception
Sites Software Exception Request
Software licenses and your role at the University of Michigan, determine what software you can access on a Sites workstation. There are circumstances where an individual of an excluded role does have a legitimate reason for using a software title that is not in conflict with the intent of the licensing terms. You can use this form to request we make an exception. Sites staff review and approved exceptions on a case by case basis.
Exceptions are valid for a single academic year. After the end of summer term, and before the start of fall term, the exceptions will expire.
After
Sites Software Exception Request
Use this form to request an exception if your role doesn’t automatically provide you access to software you need. The software you have access to depends on (1) your role at U-M and (2) the license terms of the software.
Software exceptions are valid until the start of the next fall term.
Use plain, clear, and concise help text.
Often, lengthy help text is compensating for unclear form labels, lacking validation rules, or special service exceptions.
In addition to paring down words, consider:
- Providing a clearer form label
- Placing restrictions/validation checks on the form field
- Moving instructions elsewhere (e.g., beginning or end of form)
Avoid using placeholder text.
Using placeholder text (usually appears as light grey text within an input field) often hurts usability more than it helps. If a piece of information is essential to completing the form correctly, this should be placed in a label or help text.
Place content where it is most relevant and useful.
Instructions related to a particular field (e.g., date format) should be placed in that field’s label.
“Deal breakers” (things the user must have done or must know in order to complete the request) should be communicated in the form instructions, so the user doesn’t waste time with the form if they cannot submit it.
“Next steps” (things the user must do or know after submission) should be communicated at the end of the form or after submission, so as not to interfere with the user’s completion of the form.
Allow for flexible input format or specify format clearly.
If possible, allow for flexible entry of data. For example, a user could enter the phone number with or without hyphens and it would automatically be formatted correctly.
If the form input requires the user enter data in a particular format, this should be specified in the item label or description.
Before
Estimated Date
After
Estimated Date (YYYY-MM-DD)
Avoid taking the user out of the form.
Avoid taking the user out of the form (e.g., to MCommunity) to complete a form-related task. When possible, include tasks or information needed to make a decision within the form (e.g., a look-up field) or provide an accessible modal.