But their stupidity persisted. They did things that
    were so wacky they boggled my mind (like putting a
    credit card number in with spaces between each
    number)...

Not allowing spaces in a credit card field is a pet peeve of mine. It's a trivial problem to solve in code, and almost nobody does it. Whether it's a space every 4 numbers (the most logical to me) or a space between each number, it really shouldn't matter.

There are spaces in the number on the card itself. Entering the number with spaces makes it easy to check if you've made a mistake in only a few glances, instead of painstakingly going number-by-number and losing your position a few times.

It shouldn't be the user's fault.

I just enter the 16 digits without much trouble.

Then I get to the expiration date and the first column is a drop list of Jan, Feb, Mar... wat?

Now my brain has to convert 07 to Jul instead of just picking 07. Why?!

Are developers trying to make users angry?

Then I get to the CVC code. I have to turn the card, there are two numbers, printed such that they look unimportant. Which one should I pick?

Banks are making users angry really.

Phone numbers and dashes/parens is another peeve. Not because I really care, per se, but it really does make so many sites difficult to use.

There are exactly two correct ways of handling a phone number.

* A text input field (which you will store as the user entered)

* What will eventually be coerced in to a series of just numbers in a string.

I was going to comment the same thing, and this is a good reminder

Never make the user do what code can do, unless you have a good reason for it

And no, making them take the spaces manually (or spaces/dashes/parenthesis in a phone number) is not a good reason

I just looked up a flight on Delta's site. I entered the flight number, or what most people would consider the flight number. "DL133" Delta darius it was an invalid number. Turns out they just wanted "123" how hard would it have been for them to strip the leading "DL"? Apparently to hard

They probably have a ticket for it in JIRA, at the bottom of the backlog with other things that make people's life easier, because POs want insert_annoying_features_here instead.

Of course there is the occasional website that requires the spaces to be inserted.

Bonkers.

I think sometimes users think developers are trying to make them angry.

"It's not that the users were trying to make me angry; it's that they were ignorant of how to make the app do what they want."

Actually, I think the ignorance is on the developers part.

Users don't care about what some developers may perceive as a sexy UI. Honestly, most don't really even want to "learn" the UI. They just want to get stuff done without having to think about it.

We as developers need to get better about developing software that doesn't require a manual. That doesn't require a user to learn how to use something that in their minds should really be so easy.

Example: don't force a particular credit card entry format such as multiple entry fields, doesn't allow spaces or requires use of dashes, etc. Same thing with date formats. Make your software smart enough to handle as many use cases as possible. If they do something incorrectly, make the UI guide them through the error in an easy to understand way.

We as developers are used to reading through complicated documentation, tutorials, etc. That doesn't mean we should subject our customers to that same pain. Unless your software is at the Salesforce scale, the aim should be to develop it in a way that doesn't require a manual or require your users to dig through a bunch of tutorial pages just to get started.

>Users don't care about what some developers may perceive as a sexy UI. Honestly, most don't really even want to "learn" the UI. They just want to get stuff done without having to think about it.

Very much this. Users aren't stupid, they just don't give a shit. They use dozens, maybe hundreds of user interfaces per day and your UI has no right to be a difficult POS.

I'll leave this here: "It doesn’t matter if users can use your site. It matters if they want to" ― Jacob Nielsen, 2001

I look at this a little differently. If a user is able to make a mistake, I've failed (this is too broad, but you get the idea).

If you take an honest look at your application, and step away from it, it's usually easy to see how they misinterpreted something, etc. I think empathy is an important skill in developing software. It's not right to expect someone to change how they think about a task, because you've written the software to work in that way.

Good software and UX is hard. Modeling problems in a way a computer and a user can understand is hard. Browsing http://ux.stackexchange.com/ and reading some of "The Design of Everyday Things" opened my eyes to how bad things are - and how much better they can be.

Also, if you haven't you should watch some talks by Bret Victor or Alan Kay.

Totally agreed about the not letting mistakes be an option.

I was building an admin ui to configure basically a fancy slideshow for employee performance metrics (gamification). We originally had planned a few days work to put proper validation and error messages in, but then flipped the task around and made it so that every field had a sensible default, and no mistaken values were possible to be filled in (e.g. number fields with automatic limits, date pickers instead of free text).

It turned out to be much less work and the user never sees an annoying "hey you've not filled in this field in the way one of our devs wanted you to".

> empathy is an important skill

This. I get what the author of the article is experiencing and respect his process and conclusions (I empathize), but the one thing that bugs me is:

>> Hanlon's Razor: "Never attribute to malice that which is adequately explained by ignorance."

... which can be taken to mean users are, if not evil, just stupid. I sense a lack of empathy here.

Could it be that your application just sucks? Maybe it's good or great, but from the details of the article it clearly seems like it was full of UI oversights and has potential for improvement.

>> The issue was that I live and breath code, and they don't.

This statement is telling, because code is absolutely irrelevant to the user and their experience. It would have been better if he claimed to breath UX not code, because his issues are with user experience, not code. This says more about his pride and his ego when it comes to his code, both which will only cause drama, which he admits to.

>> So we all (including me) need to calm down.

Yup.

> users saying something doesn't work, only for us to point out something simple that they forgot to do, or the instructions they totally didn't read, and then the error magically goes away

If that's how your software works, you're doing it wrong. It means there was little to no design planning. The error should tell the user/developer what to do to avoid the error thus avoiding an angry email in the first place.

Are you saying users read error messages? People come to me for help when things break, and ~60% of the time I save them by reading the error message and doing what it says.

Are your error messages readable and obviously relevant?

I would argue that developers should aim for 0 error messages ever. If your software requires an action to be performed before moving on, then redirect them to the action, highlight the point of interest, and give a little alert at the top that tells them what to do. When you have a scary error message, users get scared.

In this case I'm talking about software I didn't develop. Also, developers are not immune to this. Very often it is a compiler or runtime error that tells you where the issue is and sometimes even how to fix it. Person/developer sees a red message and panics before attempting to resolve.

I don't think I've ever felt that users are intentionally trying to annoy me, it's more that it feels like they're not trying hard enough. The sense that the application is not impossible to use, lots of their peers have apparently been able to use it with no problem, and that they need to meet me halfway. A kind of unspoken contract where I try and make it as easy as possible for the user, and the user puts in the effort to read the directions rather than just immediately clicking through.

This is not to say that it's their fault or that I am not always working on improving my own work to better take into account human nature as part of interface design. Merely that the post focuses on "intentionally piss off" as the prime motivator, and I'd be a surprised if most developers attributed it to that.

If the user has difficulties, it's usually your fault not the user's. Now that doesn't necessarily mean you can realistically do anything about it (time, budget, lack of UX people, etc)...

Meh. This is just as problematic of a way of looking at it, honestly.

If the user is having a hard time getting something done. It is probably a difficult problem for them. The job of the developer is to work with the user to make it easier. If you are lucky, you can make it easy. But, incremental improvements are huge.

Learning a graphical software interface is wasted lifetime, it's like having to learn a new spoken language everytime you want to talk to someone. If however you are married to that person, it might be ok to waste some time to learn that persons interface. Like a photographer that needs to learn how to talk to Photoshop so it can make the pictures prettier.

However most software resembles more the person that you randomly ask for directions in the city. Nobody wants to learn a new language just to exchange 2 sentences.

But building interfaces that require no learning at all is as hard as writing a program without any bugs or undefined behaviour. In practise it might be even harder since talking to the machine gives more predictable precise results, compared to talking to a human.

Most interfaces are therefore quite bad, because development time would go through the roof if any imaginable erratic user behaviour would be taken care of totally invisible. The bigger and more complex the program, the messier it's interface will be.

So yes, users might be trying to make developers angry by pointing out their lazyness.

> They weren't trying to make me angry, they were trying to learn.

Yeah, these are the easy ones.

The hard ones are the "why should i think what to do? I have my job, just make this thing work!" kind that doesn't try or want to learn anything at all.

Honest question. What's wrong with that in many cases? I want to buy a widget. I don't want to try harder or learn the peculiarities of your website.

I think that comment may be in relation to tool software such as a CAD program as opposed to service software.

In tool software it is often impossible to always know what the operator is looking to achieve as it is often novel. Service software is quite the opposite where there are likely a few well defined goals the software is attempting to help the customer achieve.

Fair enough. Past a certain level of complexity some learning curve is unavoidable.

I guess it was a bit out of the wrong context. I did a lot of fixing/building computers back in the school days, and that left a bad impression - a lot of people don't care to learn even the simplest things, or stop to think for 5 seconds.

A good guideline for writing user-facing software:

When you get asked a question once, it might be just a question.

When you get asked the same question by two different users, treat it as a bug report and see if you can fix the interface to make that question not arise.

Its disappointing to me how little empathy there is in this profession for the people that use the things we make.

tl;dr with just this quote

So we all (including me) need to calm down. Users are not trying to piss us off, they're just trying to learn.

and it seems trivial to add too that they're just trying to get things done, one in a huge pile of never ending obligations and difficulties to plain old living in the world.

Harrumph.

He has the razor pointing the wrong way. His users weren't trying to learn, they were trying to teach. In almost all enterprisey CRUD applications, the steel-toes on the floor know more about the domain than the developers.

Listen to them.

Sounds like the author is blaming user ignorance when in fact it's bad UI.

Hmm, not quite sure I agree; as with communication, I believe that the responsibility lies with the sender for the receiver to comprehend what you are saying.

Someone does not understand you? Then you are not explaining it well enough.

Someone can't figure out how to use your software? Then you did not create it in a way people can comprehend what they need to do.

Is a button you are not supposed to press (before you've completed some other action) enabled, it's your fault the user can click it.

Same goes for repeated clicks, allowing/not handling bad input, etc.

I was frustrated enough with one user that I made RTFM part of his password. Some time later his son logged onto his laptop and asked, "Dad, do you know what RTFM really means?"

The abuse of passwords here on both sides makes my skin crawl.

>> The issue was that I live and breath code, and they don't.

Eh, dunno. Maybe try not to breathe so much code? I mean, that already sounds like you're overdoing it somehow.

I actually have a very different feeling when I watch users struggle with my app. I feel slightly ashamed and very grateful. Most of the time I realise I've made too many assumptions about the UI, and i start getting ideas on how to maybe fix the problem so that other users don't encounter it.

I've watched developers who regularly work with UI get tripped up by all sorts of design paradigms. Everyone interacts with things differently, regardless of their background.

Many of the commenters here are missing the satire. This essay is about a self centered dev learning user empathy, not a defense of hard to use software

THis guys not even right

I think the post is overly optimistic. No, they're not "trying to learn." They're just not willing or able to do the simplest of tasks.

These kinds of users should not be accommodated or even responded to. Good UI/UIX should not cater to the lowest common denominator.

"These kinds of users should not be accommodated or even responded to"

Please let me know the software you have developed so I can develop something better and make those users you refuse to respond to happy. Especially if they are paying customers.

This mentality is what results in failure and leaves paths WIDE open for your competitors.

The whole point of UI design is to cater to the lowest common denominator.