The User Experience (UX) And Cognitive Dissonance Of Forms

Let's take this a different direction. Groupon.com. I wanted to see what all the fuss was about, and the first thing they hit you with is a form. A form that asks for just 1 bit of information, so the cognitive/motor load is not a large one. But what data do they want? Email address.

And that's PERSONAL information. Nowadays, it is common practice for companies to disrespect their consumers and assume that the providing of an email address is a verbal agreement to receiving solicitations and other forms of harassment.

So, even though the form was simple and easy to consume, it barred entry until they had a piece of private information from you (could not find a way around this), so I closed the browser window and simply wouldn't return.

There have been studies which have shown that companies had lost tons of potential business simply because they required so much information from the user before they allowed them to even peruse their store (or worse, let you do all the work and then present you with a massive registration form). In the same swing, when given the option to "checkout as a guest", requiring the most MINIMAL of information, they saw huge spikes in their business from these seemingly obvious changes.

Everyone is different. Some people will readily give up that personal data and not think twice about it. Others, like myself, will not. And this is why user-testing is so important. We can't make assumptions about the behaviors of people; we merely make our best educated guess.

Something that ties the two elements together-the form and the story-is that every piece of information you require should be backed by the story.

This helps immensely with two seemingly opposing issues:

1. The user doesn't want to provide any more information than necessary to get the job done.

This means you should provide good defaults for everything that you can. Don't *require* information that isn't critical to solving a problem. Don't even *ask* for information that is tangential to the current task at hand (or the current sub-task). This helps cut down on the cognitive overhead of a form.

2. The developer wants to make sure they gather all the required information.

Having a good story in place for the purpose of the form helps the developer make sure they gather all the necessary inputs at the right time. This can help group and categorize fields on more complex forms to make a form more understandable. The reason the user is filling out the form should help guide the overall design (content first!) as well as choosing the correct input types.

I don't personally hate designing forms-in fact, I prefer to see it as a high-level design challenge to get the most bang for your buck for the user. Great forms can get out of the way, and allow an end-user to accomplish their goal more quickly, with less frustration, and fewer errors. Which, to me, sounds like UI design in general!

(Spoken from having worked on re-engineering huge, complex forms that required *hundreds* of inputs to dynamically generate health insurance brochures.)

@Aaron,

This was my initial reaction as well.

The article gets close to addressing it: the "why".

It's no only the act of filling out forms that's an obstacle-it's the consequences. I suspect that the issue is mainly emotional (giving over too much info seems "creepy", though the collecting of the information is (on an individual level) trivial and inconsequential).
Then there's the practical consequences: if I give over my personal information, will I get harassed? Is my information secure? What happens when I give this info to x?

Maybe if you can avoid the initial emotion-induced hesitation, your users won't ask why you're collecting their information, but I think it helps to be up-front with your relationship to your customers.

If groupon allowed you to *opt-in* to subscription on that initial visit (but still required your address), would you give it? I can't justify why they would do that (other than info-hoarding), but maybe interesting to consider.
If they said why they wanted it, would you give it? Obviously, then I'd assume they'd do the annoying thing of auto-opt-in and allow you to opt out in a menu.

By the way, I'm almost positive groupon doesn't validate very well.
I tried x@x.com (idk if that's valid or not), and zip 99999 (which is invalid) and got in. If you're going to give up anyway, you might as well fuzz.
Also, 10minutemail.com.

For me, Groupon would have to make more of an effort to ease me into asking for personal data than it's current tactic of making it a "gate" to entry for their site.

As you hinted, if a company can come across and invoke a sense of story and seeing me as an actual person in how they address their request from information (which is all the better made by optional fields that aren't required, or better yet, not even there when not pertinent), it would help to imbue a sense of trust. And trust is vital to doing business and exchanging information.

I think it's kind of an odd strategy that Groupon uses their landing page in this manner. It's akin to a stranger you just met asking you for personal info. "No, you don't get that info; I don't know you well enough." But if a long-time friend whom you trust says "Hey man, I got something for you, what was your email?" chances are, they'll get it immediately.

And yeah, I put in my "stoplooking@me.com" and it took it. 8;)

@Aaron,

If I remember correctly, I think the wall is a holdover from when it started as a subscription service.
(I could be off-base, but from what I remember, you had to sign up to get offers in your email-website came later).

Sometimes, when you give someone a spreadsheet of emails, they get drunk with power and never want to give that up.

If they're not validating emails, there's really no reason to require it.

From what I remember, it used to have less explanatory content (just a large image background) than it does now. It does explain, albeit very briefly, why they want your email ("We'll send you unbeatable deals in *your city*") and it also incentivizes:
"*For new subscribers, $10 will automatically be deducted from the first Groupon Local deal purchase
of $20 or more made from your account within 24 hours. Discount automatically applied at checkout."

But that didn't go far enough for you (or it wasn't very visible), and rightly so-you hadn't seen the value of what they're offering.

I am surprised, given the lack of validation, that there's no option to skip initial signup.
Once someone skips, indicate that you can get deals sent to email (if you find this appealing).

Really, they have nothing to lose by not collecting emails BESIDES THE AUTO-OPT-IN that happens.
Which, as we know, is a dick move. http://darkpatterns.org/misdirection/

Exactly.

One thing that has always killed me are Age Gateways. Not gateways in and of themselves, but the ones that require 3 fields to be filled out: Month, Day and Year.

This could be simply changed to "How old are you?" in tandem with a single field for age. Again, there's no actual verification of data; you're putting people on the honor system; and if there's a requirement of an age gate, then at least make the interface as simple as possible.

I've never thought about that one, but it's a good point.

For things that I know don't need my actual DOB I just put 1/1/(something greater than 1920).
Dropdowns are better-just open, scroll, click. Wherever it lands, that's how old I am.

Maybe they don't bother me because I almost never bother to put the correct thing.

@davidknauer

Me neither. If I want something and can get by giving false info, I will, and I've no qualms about it.

It's entertaining to me to see the Designer in Ben (who is definitely of a Developer mindset) begin to peek into the realm of UI/UX. I've always found the duplicitous nature of Designer/Developer as a neat thing to discuss.

Obviously, there are people mired in the belief that one is better than the other, but no one will ever convince me of that. Developers are logical, they seem to organize flow into segregated structure and seek to impose order. Designers are creative, they look to the tangential relationship that elements have with one another and seek to convey cohesion.

An app that does amazing things, but has a God-awful UI is of little use to anyone. And an app that looks gorgeous, but doesn't do anything more than that also serves no purpose. People who live in the world of black OR white, this OR that, don't seem to understand that an app that has the best of both worlds (Design AND Development) will always be better than an app with OR.

As such, we've established guidelines in both worlds to give us a starting point to move forward from, and with the rapidly changing nature of the web, both designer and developer need to work together in order to harness the amazing capabilities that each brings to the table.

@Ben,

I'd love to hear about those things that you find perplexing from a UI standpoint. You're undoubtedly a well-established developer, and getting to hear from that type of perspective can provide many people with their opportunity to chime in and provide a unique perspective.

You sound as if you're making good strides into the field and that you have a natural curiosity as to the human side of the web application. That's great because you know the programmatic side like the back of your hand, and as you further your understanding of the human interaction side (and the psychology behind it), you'll find yourself not only agreeing with more ideas from the Design side of the house, but even making suggestions that are well-founded and would improve the feature set.

Either way, it's always good to hear when a team of designers and developers value each other for what they're bringing to the table. Comprehension doesn't *require* respect, but the more of the former you have, the more you can appreciate the latter!

@Ben,

It depends what the software's being used for.

If your use case was something like a microblogging platform, where files are unlikely to be used again (or saved locally at all), your current rename function makes sense-it won't matter what it's called, since it's unlikely the same file will have multiple iterations.

In your case now, I agree with you (*see below, where I ramble). If you're going to iterate on a file, it will cause confusion if that file is called two different things in the same location (and this problem is compounded when the file's in two different locations).

I, personally, would prefer to have the file name/date visible (and perhaps version number, if you've got version control). A notes field (à la Confluence) can serve to describe the file or name it-but shown in addition to, and not instead of, the file name.
For file sharing/version control, I cannot see a use case where this function has a net advantage. Perhaps some people would better understand that "green_bg_01012014" is the masthead if it can be named "Masthead", but the same file can be referenced by file name (and thumbnails help-I haven't logged in to check out what features are available). Assuming someone has a longer memory than a fish (maybe that's giving my hypothetical dummy too much credit), he'd only have to learn the file name once. This is also assuming that the file is not being addressed by name in more context (e.g. a conversation about the masthead referencing "green_bg..." This, however, assumes that there aren't a ton of files posted with perhaps only a few referenced, and also makes generous assumptions about project scope and timeline.
Basically, it would be best to examine the ideal use case and interview/test for features like this. It's a relatively simple seeming feature, unless you start to think about different use cases from different points of view.

As far as changing peoples' habits-that is a grand aspiration, but I'm far too cynical to believe that something so simple would change anything. Stuff like that needs to happen within the culture, usually someone getting pissed enough and supported by a manager to put in place some guidelines. It's a difficult gear to get turning.
The above paragraph has some caveats: the larger the institution, the more likely it is that each person has different naming conventions; naming conventions could be tightly controlled by one manager (or one group) and not another; (this one's an assumption) people who have been at a company longer are less likely to adapt to a new convention; and, as I have observed: people are inherently stubborn-which I would cautiously say is a carryover of our basic survival instincts-you find something that works, you continue doing that (this is far easier, survival wise, than going through the learning process every day (which is my personal goal and my wish for all designers/creatives of any type-but it is not)).

You can rely more on people hacking the requirements to fit their needs than conforming.

Started getting distracted at the end.

It is my goal and wish for designers/creatives (and everyone else) to go through the learning process every day (even when following patterns, being critical and noticing new things even in old experiences) but I don't believe that is the case with most people-for the reasons above.