We continue our Year of Documentation, in which OIT Design documents how we implement the university brand, highlight recommendations from OIT’s Accessibility Coordinator, and describe general best practices based on our own experiences.
For today’s entry, here are some recommendations on building better forms, focusing on user experience. Much of this is drawn from the phenomenal Design for Real Life by Eric Meyer and Sara Wachter-Boettcher. It’s a good read, and something I expect to be referencing frequently.
Reminder: PCI Compliance
Merchant Services in the University Controller’s Office is responsible for any and all processing of credit card information and cardholder data. In general, you should not be building any web forms that collect cardholder data or process financial transactions. Any such payment gateways must be built in consultation with Merchant Services. They will work with you to ensure that your payment gateway is PCI compliant, or they will guide you to an approved solution.
Note that web hosting services provided by OIT (AFS, cPanel hosting, and Hosted WordPress) are not PCI compliant. Payment gateways cannot be hosted using these services.
Accessible Input Labels
All input fields on a form must be labelled with label elements, which are explicitly tied to the corresponding input field using “for” and “id” attributes. Some code examples given in the IT Accessibility Handbook are reproduced here using the university Bootstrap flavor and minimal additional styling:
Better Forms Through Better Form-Writing
Meyer and Wachter-Boettcher explain:
When we ask users to share information, we’re asking for their trust. But it’s hard to trust a site when you’re not sure about the intentions of the people behind it. Why do they need your data? How will they use it? What will happen once you provide it?
Although NC State is a trusted institution, we shouldn’t assume that all users—especially students—trust us unconditionally. Getting accurate information from users is often vital to university business processes, but asking for more information than you need or without explaining why you need it can be alienating to users.
This is particularly true of information that is personally identifying (eg. name, address, age, race, even their college/major) or sensitive (eg. gender identity, sexual orientation, family history).
There are legitimate and important reasons why university websites may ask for any and all of that information. But how you ask for that information may impact whether and how users respond.
We should be aware of how our requests for information may be read by users, and we should consider our intentions as we request information. Why are you asking for this information, and should you? Meyer and Wachter-Boettcher recommend a four-part protocol for evaluating whether or not to include a form field:
- Who within your organization uses the answers?
- What do they use them for?
- Is an answer required or optional?
- If an answer is required, what happens if a user enters false information just to get through the form?
- If these questions do not have clear and defensible answers, do not include the field.
Value Your Users’ Time
The primary purpose of your form should be to collect information from your users, and barriers that would hinder your users completing the form should be removed whenever possible. Those barriers may include input fields intended to make your business process easier at the expense of your users’ time.
In particular, consider users’ mobile experience, where tabbing between fields isn’t an option. How many times does your user have to stop to tap a new input field?
For example, suppose an IT support process requires a user’s Unity ID and generates an email notifying the user that the process is complete. The form might ask for the following user information:
Note that the support process described doesn’t require the user’s first and last names—fields that may be included out of habit rather than necessity. If IT staff does need to contact the user by name for some edge cases, having that user’s name available in the form submission is convenient, but the user’s name can also be found easily in the campus directory. Similarly, users’ default email addresses are of the form email@example.com, meaning the Unity ID and Email forms are redundant. Four fields included in the form for the convenience of IT staff can be reduced to one field for the convenience of the user.
- Value your users’ time by streamlining their experience whenever possible. Remove redundant form fields and ask for the minimal amount of information needed to complete desired business processes.
Question Your Assumptions
A field input that appears to be simple may not be for some subset of your users, and may be sensitive in unexpected ways. Meyer and Wachter-Boettcher point to gender as an example of this: some users may not identify within a male-female binary identity for a variety of possible reasons. Although the designer of the form probably thought it was a simple demographic question, a radio-button choice between “male” and “female” could be very difficult to answer for these users.
When faced with an unanswerable question like that, some users may abandon the form altogether while others may feel forced to provide a response that does not actually reflect their identity or experience. Both of these outcomes are undesirable both for the user and for NC State. The user may feel alienated, discouraged, or distrustful of that campus unit. The campus unit, meanwhile, is now failing to serve a segment of the university community that sought out its services.
These assumptions may be based on our own business processes, and accepting responses that don’t conform to those expectations may inconvenience us. But once again, we should not be prioritizing our convenience over good user experiences.
- Whenever possible, ask open-ended questions or include an “Other” or custom response option.
- Carefully review the fields you include and question what possible responses might be excluded.
Disclose Context and Consequences
If asking for sensitive and personal information is required for your business process, include additional description text that explains to users why you are asking for this information and what you plan to do with it. For example:
Similarly, when users do not submit responses to required fields, error or validation messages should be used as an opportunity to reiterate that message, eg. “This field is required. Any information submitted will be anonymized and used for statistical reporting only.”
This kind of disclosure communicates to users that NC State units and their websites are worthy of their trust—that we’re not trying to trick anyone, and we’re not going to misuse your data or deliberately put you at risk.
Context Keeps NC State Safe
In addition to improving the user experience, building trust can benefit the university’s efforts to maintain a secure network.
Student, faculty, and staff accounts are frequently targeted for phishing attacks. These attacks often send users to a non-NC State web page that copies the university’s visual style. Victims, unaware that they have been directed to a malicious web page, enter their account credentials and potentially more personal information believing it to be necessary for legitimate university business.
The techniques described by Meyer and Wachter-Boettcher provide one way to help protect users from this kind of attack. As users learn to trust forms that disclose the reasons why personal information is requested, forms that ask for personal information without a plausible explanation become more suspicious.
Providing context can also be a way to explain to users how NC State is keeping their information safe, and how to spot a malicious form. This can be accomplished through simple reminders, such as this recommended reminder for forms that require users to enter their Unity ID:
- Explain to users why you’re asking for personal information and how you’re keeping their information safe.
- Include an anti-phishing message with every form field that asks for a user’s Unity ID.