To every person involved in designing software

Greetings.

As we learn to design software, a recurring problem becomes clear.

The problem is this: To differentiate between valuable and not-valuable. Let me break it down now.

Everyone in product management is screaming at us to make the software easier to use. We are also tasked with it, it seems, cramming a shitload of features into a little bit of time.

Our friends, the penguins, think that we, therefore are employed to write features — and, so, at times, it seems to us.

But note: The users will not log-in to use features. You wouldn't, I wouldn't. No one would or will. The user will only log-in and keep logging-in to get value.

Question: What is value? Value, again, is the quest of the user to overcome those things which prevent him from achieving a specific, acute goal.

So: we, the software authors, must ask ourselves of every feature these three questions.
1. Who wants that?
2. What happens if they don't get it?
3. Why do they want it?

The answers to these questions are Litmus paper. Apply them, and their answer will tell you if the feature adds value or not.

There is not magic fairy dust that will turn a superfluous, useless, redundant or merely hard to use feature valuable once the user downloads the software. You the software author are in charge of making sure every feature is valuable.

If the features confuses or bores you when you design it, rest assured that it will bore the programmers, and will, then bore the user, and we're all going back to the breadline.

Someone has to make the feature valuable. It is not the programmer's job (the programmer's job is to make it work to the design). It is not the project manager's job. His or her job is to make sure it gets built and delivered on time and on budget. It is your job.

Every feature must be valuable. That means: The user must have a simple, straightforward, pressing need which impels him or her to show-up and use the feature.

This need is why they came. It is what the feature is about. Their attempt to get this need met will lead, at the end of the workflow, to success. If this need is complex and requires more than one feature, this need will, then, of necessity, propel the user into the next feature.

All of these workflows, taken together, will, over the course of the session, constitute a completed task.

Any feature, thus, which does not both advance the task and standalone (has value, by itself, on its own merits) is either superfluous, or incorrectly designed.

I close with one though: Look at the feature and ask yourself "Does it add value? Is it essential? Does it help the user complete their tasks?"

Answer truthfully.

If the answer is "no", write it again or throw it out.

It is not your responsibility to know all the answers, but it is your responsibility to know and ask the right questions, over and over, until it becomes second nature.

With apologies to David Mamet (original text)

Bus ride and a usability lesson

A few mornings ago, something interesting happened in my bus ride to work. I boarded as normal, paid my fare and turned to find a seat. And then I stopped dead in my tracks. Completely destabilized by the seating arrangement in the bus. Instead of being layed-out like a normal city bus, that particular bus was layed-out like an inter-city coach. Rows of high-backed upholstered seats with armrests. I found a seat and started looking around.

The difference was not limited to the seats. When examining the rest of the bus, one other notable difference was the absence of the pull-rope to request a stop. Looking carefully, I noticed a strip of yellow-colored plastic right above the row of windows. I wish I had taken a picture of the yellow plastic strip to illustrate my point.

Following the strip all the way to the back, I spotted a sign instructing passengers to touch the strip to request a stop. During this 15 minutes ride to work, 2 people failed to figure-out how to request a stop and had to walk all the way to the front of the bus and request a stop directly to the driver.

In the end, that bus ride was a very interesting usability and design lesson.

Breaking convention: Most transit users are familiar with the pull-rope system. This is a system that has been used in transit buses... probably since there were buses. Breaking the convention forces the user to to learn a new convention and to make an effort to use the system.

Affordance: A yellow rope hung over the windows along the side of the bus screams: "pull me". This is a perfect example of an affordance. You don't need instructions, there's just one obvious way to use the mechanism.
A subtle yellow strip of plastic says: "I'm yellow and smooth and decorative and you'll have to read the sign if you want to figure me out". Actually, the fact that there is a sign at all should be a hint that something is wrong.

Prettier and more comfortable doesn't mean better: That bus was clearly more comfortable than the normal city bus. It was new and less noisy and had comfortable seats. That is all good but that is nothing if it forces you to make an effort to enjoy it. Those 2 people that had to request a stop with the driver surely didn't enjoy the extra comfort of their ride that morning.

This is a clear example of why design has to take into consideration the context of use. This design for the bus was probably perfect for an inter-city coach with long stretches between stops. But it was clearly not taking into account the needs and context of the everyday transit user.

This blog has moved

This blog is now located at http://blog.surprisedpoultry.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://blog.surprisedpoultry.com/feeds/posts/default.