Forms vs. People

What do users dislike most about the Web? It’s almost certainly filling out forms. And by a crazy coincidence, what do Web developers find the most challenging aspect of their work? Forms must certainly rank high on the list.

Forms are that locus in the interface where the differences between humans and computers come to a head and must be reconciled. The website needs to acquire data from user. But the human mind doesn’t have data, but rather, facts, feelings, opinions, preferences, questions, and a host of other kinds of information which are anything but data. Data is what you end up with when the required information has been captured successfully.

Using an MVC paradigm, form challenges can be outlined thus:

Challenges for the model

1. Data must be logically arranged for quick retrieval and meaningful reports.
2. Data must meet business logic requirements.
3. Data must be ‘clean’, accurate, and ready for storage or manipulation.

Challenges for the controller

1. Data must be cleaned to prevent against possible attacks.
2. Data must be of the correct type, i.e, strings, dates, integers, etc.
3. Data must collected in such a way that it can be parsed, combined, and stored easily.

Challenges for the user interface

1. Forms for gathering data must be easy to understand and easy to use, for all potential users, including those with disabilities, slow connections, and all supported platforms and browsers.
2. Forms must be long enough to capture the required information, but not so long that the user tires and quits without submitting information.
3. Forms must anticipate what cannot possibly be known with certainty: How to best prompt the user to share the necessary information so the site can convert it to data.

As a UI developer, I have the most experience with the last three issues. The last one is by far the point which businesses are most likely to get wrong, and yet assume they’re actually doing it right. It’s where users can fall through the cracks.

Prompting the user

“Prompting the user” for this information comes with a slew of difficulties.

Quite naturally, the UX/UI team (and by this I mean all persons involve with creating the UX/UI — graphic designers, product planners, and developers) might assume the user is just like them, and design the form so that it would prompt them to enter the correct information.

A graphic designer’s first instinct is naturally to design a form that looks good. Product wants a form that will funnel desired information into business data, and UI developers want a form that will be simple to build and reasonably future-proof. Note that no one’s first thought has been about how the user will understand and interact with the form.

If this doesn’t sound like a recipe for disaster, it should. The times and ways in which this approach does not work can be extremely costly, and difficult to detect, although they can easily be avoided.

The way to avoid this is:

1. Know your users
2. Test the form
3. Ask for feedback
4. Think of who might fall between the cracks

Numbers 1-3 above are well-known, though not always well-practiced. However, the fourth point seems to me rarely thought of. An assumption is that if the form is working, it’s working for everyone, as long as online tests and focus groups (you do have focus groups, right?) show no complaints.

But it’s precisely the fourth point that might have the most bang for the development buck. Think about who might be falling through the cracks.

Case 1:

Clouding the issue

Take, for example, this screenshot I took years ago from a survey form on the Borders website. The first page had no problem, but the second page presented me with this train wreck:

In case you’re wondering where’s the horrible usability issue, the problem is that the form is asking me to make what I found to be an impossible choice. I’m a book lover, and I was buying books from many different sources: Amazon, Borders, B & N, and my local independent store as well.

My specific recommendations would depend on which friend (or colleague) this was, and their own priorities regarding the particular item they’d be interested in, e.g. cost, convenience, immediacy.

The key problem here is that subtle, but needless complexity comes into the question. Borders probably wanted to ask me something like “Would you recommend Borders to a friend? If not, which of these options would be your first choice?” And if put that simply, the answer would have been a simple “yes” to Borders.

But instead, the fuzziness of the question caused me to overthink the possibilities. I ended up abandoning the form, writing a blog post about it, and within months, Borders was no more. (I’m not saying this was cause-and-effect, but hey.)

Case 2:

Pigeonholing users

A fact about forms and the transmutation of information into data is that unlike a name or telephone number, many kinds of user information can be vague, difficult to describe, and changeable. A prime case in point is the religion question, which appears on many social media sites. On American web forms it’s usually presented something like this:

Select Your Religion

(Radio buttons)

Protestant
Catholic
Jewish
Muslim
No religion
Other

There are more ways a customer could fall through the cracks with these choices than I care to think about. Hindus and Buddhists might resent being relegated to “Other.” Ditto for Eastern Orthodox Christians and Mormons. Furthermore, anyone who’s a member of multiple religions, or is questioning their religion, or prefers to say nothing about their religion, might well abandon the form if they cannot skip the question.

A better solution might be something like this:

Describe Your Religious Views

(Check all that apply)

Protestant
Catholic
Other Christian
Jewish
Muslim
Hindu
Buddhist
Spiritual, not religious
No religion
Something not listed above
Unsure
Prefer not to say

With only a few more choices and the presentation of checkboxes instead of radio buttons, the user can express a very wide variety of religious affiliation. Note also that changing “Other” to “Something not listed above” takes us away from the possible perception that minority religions are not worth distinguishing, to the understandable fact that the website cannot list all possibilities.

Case 3:

Erroneous validation

Forms can also cause users to fall through the cracks when developers assume limitations on form data without checking to see if those limitations are valid.

Is your website likely to be used in Indonesia? Better not make both “First Name” and “Last Name” fields required; Millions of Indonesians just have a single name.

Are you going to have East Asian users? Try using “Family Name” and “Given Name,” because in China, Taiwan, Korea, and Japan, the family name usually is first. “Family Name” ensures that the surname goes into the correct field.

Do you require at least two letters for a name? You just invalidated U Thant, former Secretary-General of the United Nations. And Kenny G and Mr. T won’t fare any better with your form.

Email validation occasionally shows the assumptions of the coder rather than the actual requirements of a valid email address. For example, when I signed up for service with my current ISP, I was informed via an error message that I needed to enter a valid email address instead of the one I had been using for over ten years to receive tens of thousands of messages! Apparently the coders for this national(!) ISP were under the impression that a username had to be at least three characters long. Mine was simply two characters followed by my domain name. I ended up using a different email address, but not before writing a complaint to the company, and a public blog post excoriating the form for its erroneous error message. Developers, please don’t trust a regex validation without consulting the actual specifications.

A Better Web

We can make the Web a little bit better for everyone, by making forms better. The key is for everyone who influences the design and workings of the form, including product designers, graphic designers, and web developers to ask and research, “who might fall through the cracks?”