Forms are perhaps the most infamous aspect of web development. No one enjoys developing them and, apparently, no one enjoys using them. But here's my cognitive dissonance - almost no Form has ever stood between me and something that I wanted. Maybe I can vaguely remember a form or two that was so complicated or so broken that I couldn't complete it; but, in the overwhelming majority of cases, a form was just a necessary means to an end. So, why is my personal user experience (UX) so different from the web-development folklore? Maybe it's because we over-simplify the way that we consider forms in the context of user experience.
| || || |
| || |
| || || |
In the book, "Man's Search for Meaning," Viktor Frankl states:
Those who have a "why" to live, can bear with almost any "how".
With complete sincerity, I think the same can be said about web forms. If you give your users a "why," they will do almost any "how" - they will complete the form. So the way I see it, the problem is not really the form - the problem is the backstory. Has your application painted a picture compelling enough to provide a sufficient "Why?" If you can solve that problem, I suspect the forms will become much less of an issue.
Of course, we don't always have the time to build a strong emotional bond with our users before presenting them with a form. In such cases, where we can't provide a compelling "why", we have to require a less arduous "how." The level of effort required by the user has to be in proportion with their will to move forward.
In all cases, forms should be as simple as possible. If you can remove or defer complexity, you should. If you can add or remove elements that provide clarity, you should. But, before viewing forms as nothing but a necessary "evil," consider the fact that they are typically critical in getting things done. And, if you can sell your users on the task at hand, they too will want to get things done.
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.)
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 firstname.lastname@example.org (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.
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 "email@example.com" and it took it. 8;)
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/
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.
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.
I've had very similar situations with Quora. It used to be that I would do a Google search for something and Quora would come up in the result. I'd click and the very first thing I would see was a __requirement__ to login using Facebook and the like. I couldn't read the page without it.
So, my reaction has always been to close the page and go to the next result in the Google result set.
This is such a strange gesture. I found your page by searching, which means that your pages are clearly visible on the internet without being logged-in. And yet, when I get there, you want me to login. And that's before you have even validated to me that it's worth logging in? No thanks.
I recently checked back (via Google search) and it looks like the finally removed the requirement to login. They still present you with the login form; but now, you can just close it out and read the page.
Thinking about Design / UX from and engineering standpoint is a huge struggle. It's something that I've been working on for years at work, but have only just started to try to write about it. Sometimes, things make sense; but other times, they seem so illogical that I cannot even begin to fathom why people want a certain feature or UI or whatever.
Up next on my list of books to read is, "The Inmates Are Running the Asylum", which I'm told speaks to this kind of problem. Learning to design for emotion rather than exclusively for logic. I just started reading Don Norman's "The Design of Everyday Things." So far so good :)
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!
One of my biggest points of frustration is that I think that software should have constraints that help people learn how to do things better, rather than giving them enough flexibility to make their lives harder.
A great example of this, in InVision (where I work), is the ability to rename files after they are uploaded. On the back-end, we store two different values per file:
When you upload a file, the "name" is automatically generated to be more user-friendly. So, imagine you uploaded a file with the filename, "client_login.jpg". We would auto-generate the name, "Client Login", as a more user-friendly option.
Now, here's the problem. Looking at the data, about half of the designers put zero thought into the way they name their files. So, they end up with files that have nonsensical names like, "version_1_reverted_20131205.jpg". Of course, when the upload that to our system, it auto-generates the "name", "Version 1 Reverted 20131205". Then, a user goes to rename the name to be something "user friendly" like, "Homepage Version 1".
At this point, we have (in the database):
* Filename: "version_1_reverted_20131205.jpg"
* Name: "Homepage Version 1"
At this point, I want to explode with how horrible of a feature this is. I am 1000% convinced this was a horrible horrible horrible idea to add to the software because it does two things:
1. It complicates the user's life in the long-run because now the files they have on their computer contain different names than in the system which means they have to have a larger, more complex mental model... and they have to actively maintain that mental model over time.
2. It fails to help the user develop better strategies over the long-term.
See, when we let the user rename the files online, we *think* we're adding value; but actually, we're adding nothing but the illusion of a value-add. If we had kept that feature out of the software, the benefit would have been that over time -- I assume -- people would realize that if they thought about their filename a little bit, it would actually make their lives a whole lot easier and their mental models a whole lot more simple. And, over time, we'd help the user develop better, more productive behavior.
Of course, a lot of people would read what I just wrote and think, "That's why you're the engineer and NOT the designer!"
I think flexibility is good. I think giving people enough rope to hang themselves is NOT good. And, I think having the mind of an engineer can maybe help me discern that a bit more? Or maybe a bit less? :D
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.
One of the things that always blows my mind is how good users can be about working around the limitations in a piece of software. I can't tell you how many times there has been a bug in software, and the user finds a way to move around it. When I was doing consulting, this happened a lot of times:
ME: Why didn't you tell me there was a bug there?
CLIENT: I was going to, but then I figured out how to get around it. If I take the text and then email it to myself, I can have my mail client export it as a PDF. Then, I can open that on my computer and have my Word Processor convert it to a .doc file. Then, I can upload the .doc file to your system. No problem!
These are the kind of conversations that leave you thinking, A) your client is kind of crazy :D ... and B) how in the heck did they figure that out!
Users have a fairly impressive way of finding solutions to their problems within a constrained space. This is why I think that leaving some constraints in the system can help the user change their behavior. The difference is, I'm not actively trying to change their behavior - I'm just providing constraints.
That said, I also find that people choose weird behavior because there is different problem that is not being addressed. For example, we've had some users that upload a new file with a unique filename every time because they think they cannot upload the same file twice. That's a totally different usability problem :)