Users Don't Fail; Designers Do

It's really easy to feel like a failure as a user: maybe we can't find a piece of information on a website; maybe we can't figure out how to enter some data; maybe we can't open a door.

Whenever you feel like a failure as a user, remember that you didn't fail, the designer did.

And this holds true when we are the developers: Our users don't fail; we do.

I've come across a few things that have made me think about this lately, and I'll talk about those in a bit. First, I need to tell a story about how I felt like a failure as a user.

Jeremy Gets Trapped on a Balcony
Several years ago, I was attending a convention at a local convention center. As often happens while working in tech, some issues came up at work. As I was walking along the hallway on the 2nd floor of the convention center, I got a phone call. So I answered the phone and headed outside to the balcony to take the call.

I was only out there a couple of minutes. But I ran into a problem when I tried to get back into the convention center. I grabbed the door handle, and the door didn't move. Crap, locked.

I grabbed the other door handle and tried it. Locked. Maybe I wasn't supposed to go out that door.

So I tapped on the glass to get the attention of someone inside. And I motioned for them to come open the door for me.

He looked at me, and while motioning with his arms, he said a single word: "Push".

Thinking About Affordances
So what makes me think about one of the not proudest moments of my life? I'll blame it on listening to a recent episode of .NET Rocks! UX Thoughts with Danielle Cooley.

I had the opportunity to meet Danielle (@dgcooley and http://dgcooley.com/) at the Nebraska.Code() event last month. User Experience (UX) is a topic that I've been interested in for a long time (you can see some of the books I've read on my website), so I was happy to have a chance to talk to someone who specializes in UX research and how humans behave. We had a good conversation at one of the evening get-togethers and shared experiences.

And I was reminded of my "failure" while listening to .NET Rocks!, first because she mentioned how users don't fail, designers do (and "designer" is whoever is doing the design -- probably a developer in a lot of cases). I was also reminded of a book that was *not* mentioned in the episode but is one of my favorite design books: The Design of Everyday Things by Donald A. Norman (Amazon link).

Norman mentions the idea of "affordances". He deals primarily with things in the physical world, and affordances are those clues that tell a person how something is supposed to be used. This can be the materials, the shape, the position of buttons or handles, or any other aspects of how an object presents itself to a potential user.

I really enjoyed reading this book, and it makes me look at things in the world in a different way. (I have the 2002 edition; I didn't realize there is a 2013 expanded edition, so I guess I need to pick that up.)

And if you're curious about the item on the cover of the book, this is based on the "Coffeepot for Masochists" designed by Jacques Carelman.

Norman's book contains a section about affordances on doors in popular architecture and how they can often fail the people who have to use them. And that's what leads back to my "failure" to use a door properly.

Analyzing the Failure
As you can imagine, as soon as I heard the word "Push", I was rather embarrassed. A simple push on the door freed me from my trap. And I could feel my cheeks start to burn.

Soon after, the analysis began: How did I get myself into that situation? And how do I prevent it from happening again? There were several contributing factors.

1. I was distracted when I went out the door.
I was on the phone and payed no attention to which way the door swung as I went outside. I was concerned with who I was talking to and trying to get out of the crowd of people.

2. Public building doors normally open out.
When we go into a public building, we're used to pulling a door open to get inside. Why? We can thank the fire codes for this. In event of a fire, the way out of the building must be as free from obstacle as possible. This means that doors swing out so that we can easily get out of the building in an emergency.

But this door swung in. Why? Because this was a balcony with no other exit. So in an emergency, the way "out" was to go into the building. So that's why this door opened "in" even though I was outside.

3. The designer went for aesthetics over functionality.
The door handle was a vertical bar. Let's see what Norman has to say about this:

From The Design of Everyday Things by Donald A. Norman

So, I wasn't far off here. The door handle looked like the one on the right (vertical bar that curved into the door). To make things even worse, the handle on the other side of the door was exactly the same vertical bar.

The designer had decided to go with what looks nice rather than what is easy to use. (And I'm sure it looks really great in pictures.)

Result: I was doing what humans normally do.
That's not something to feel bad about. I'm not the one who failed in this situation; the designer did.

Failing as a Designer
As a user, I should not feel like a failure; it is the designer who failed me.

As a developer, I need to take this same attitude toward my users. If my users can't figure out how to do a particular task, they have not failed. In that situation, I am the one who failed (as designer of the software).

There was one particular application where I failed as a designer. At the time, I knew I was failing as a designer. But there were ROI decisions to be made.

Let's get into some details. I worked on a calendaring application for a theme park. Every scheduled event went into this calendaring system: this included maintenance items (such as painting and repaving), publicity items (such as press events for a new ride), operational items (such as operating hours), and entertainment items (particularly shows and parades) -- and it even included special events like weddings.

The data entry screen that we had to enter these items worked for 95% of our users, and it worked pretty well. But it was very awkward for 1 user: the person from the entertainment area who entered the shows and parades.

I always wanted to write a special data entry screen just for this one person. She was constantly entering events -- there was *a lot* of entertainment at this location. We did have some templates to make it easier to duplicate items, but it never got to where it should have been to make entering these types of events easy.

So, in this case, I failed as a designer.

Mitigating Failure
The one good thing about this is that I was aware of the failure. Because of this, I spent extra time with this one user to make sure that she was as comfortable as possible with the awkward process. And whenever she ran into issues, I made sure to resolve them as quickly as possible.

I know that this extra effort payed off. The result was a good relationship with this user (and the department in general). In fact, when that person left the position and a new person came in, I found out that she spoke very highly of me to the new person. And I made sure to stop by their office to introduce myself and let the new person know that I was available to answer any questions.

Face-to-face conversations really help build relationships. I've been able to build trust with the people who use my software even when the software was not ideal.

Wrap Up
We have a big responsibility as developers: usually we are also the designers who decide how users interact with our software. And if our users end up "failing" when trying to use our software, it is not the user who has failed. It is we who have failed our users.

Think about the time that a piece of software (or a door handle) has frustrated you. Did you feel like a failure? Remember this when you're designing your own software. We want our users to be successful. And in doing so, we need to make sure that *we* don't fail them.

Happy Coding!