Design, Usability, and Switches

Today’s post is a parable about an unfortunate designer named Pablo who lives in an imaginary universe where physical (construction) projects are like software projects in our universe.  Pablo is frustrated by helpers who don’t understand the principle of “Design for the User”.  To make things worse, Pablo lives in his universe’s equivalent of India, but all construction work is outsourced to North America, and communication is severely restricted.

Pablo is in charge of construction of a building with a large shared use space. In that space is a bank of electrical switches that control different things – some control lights, some control projection screens, and some cause alarms to sound if the doors are opened.  The people visiting the space try to use the switches, but they often get mixed up about which one to use, in which situation.  The switches look like this:

Pablo is getting complaints about people who accidentally use the wrong switch, and literally alarm others in the room.  They don’t like that.  So he sends a message to the construction team: “Please label the switches.”   His universe is limited to using very primitive mechanical means to communicate so he has to be necessarily terse.  He heads home for the night, knowing that on the other side of the world, people will respond and act on his wishes.

The next morning he arrives, and finds the switches labeled like this:

“Oh no”, he thinks.  “This won’t do.  The switches are labeled, but this is not going to help people use them properly.”  His fears are confirmed, and just like the day before, soon people are coming to him complaining that they don’t know what switch to use.  So he prepares another message to the construction crew, which is still severely limited in bandwidth, but he feels is at least far clearer than the previous instructions:  “Please label the switches again, and this time please be sure to include a description of what the switch does.”  Again he retires for the day, hopeful that tomorrow at least this problems will be solved.

In the morning, he arrives to finds extensions to the labels neatly included on the switches, and they now look like this:

Pablo then pulls out all his hair, moves to Tibet, and becomes a monk.

What went wrong here?

I borrow this design problem from Don Norman who wrote in his book “Design of Everyday Things” about a similar situation with a bank of identical light switches, and how to design a panel where the switches were positioned and oriented more appropriately to indicate the function of each switch.  I am aware of that solution, and perhaps Pablo would go there some day, but that is much more work than simply providing helpful information.  Without the luxury of starting from scratch, there are still helpful things that can be done.  But keep in mind this is just an allegory, not literally a problem we are facing.

The real question is: what went wrong here?  Is Pablo to be blamed for not being clear enough in his instructions?  Should he have detailed the precise wording of each switch label.  That certainly would have addressed this situation, but he would be doing the job of the developers, and might just as well put the labels on himself.  What about the people who made the labels: are they at fault in any way?  The labels as provided imply a deep misunderstanding of the user, and what the user wants and needs. The first label seems to assume that the users do not know that the devices are switches, and so appears to be an attempt to clarify that knowledge gap.  The second set of labels seems to assume that the user does not understand the functioning of the device, and so attempts to clarify that.

Both explanations completely miss the point, because they don’t tell the user how to accomplish their goals. People want to be able to control the right things at the right time.  Pablo works closely with these people, and knows they understand switches and what they do, but critical thing that is missing is the detail about what each switch does differently from the others.

There is a deeper problem than simply a misunderstanding of the user.  In my experience, development teams often feel the need to explain to the user how the thing they are using is functioning.  This is natural because development teams spend a tremendous amount of time understanding precisely how to accomplish things, but this is not what the user needs.  The user needs the right information to accomplish goals.  People don’t care “how” a switch works, but care “what effect it is going to have” because only that is relevant to their goals.

Good software designers know this: you must consider the ultimate user goals, when designing the simplest things.  A light switch, in isolation of the use it is put to, can not be described in terms that are useful when finally mounted to the wall.  It is only when considering the actual purpose that the switch is put to, that you can come up with good descriptions of “what the switch does”.  You must understand what the user knows, and what the user does not know, and then provide information to fill in the gap.

How can this problem be avoided?

Successful agile software teams know that a strong customer representative who knows the user well, is a critical part of the development team.  That customer representative must be a continuous part of the development, present all day long, to assure that the developers have a proper understanding of the end user.  Simply “telling the developers what to do” will not work, because a lack of complete understanding of the needs and goals of the users will lead to many small design mistakes like this.  Instead, there must be a rich interaction so that developers make the right design choices every time.

Advertisements
This entry was posted in Software and tagged , . Bookmark the permalink.

6 Responses to Design, Usability, and Switches

  1. Pingback: Tweets that mention Design, Usability, and Switches | On Collaborative Planning -- Topsy.com

  2. Keith, great post. Truly desribes much of the problem between IT and business. I would just not call it a small mistake, but a complete project failure. Often ‘adding a label’ in terms of an IT project might be a million dollar coding effort. Interestingly enough I just posted about the same thing from a slightly different angle. http://isismjpucher.wordpress.com/2010/11/21/process-goals-rules-patterns-and-templates/

    Lets assume that we are not developing software but designing processes, ok? The switches become a perfect metaphor for decisions or actions to be taken. BPM doesn’t even label the switches and tells the people when to use them. I would very much use your proposal to not simply tell the flowchart designers what to do but to use rich interaction with the business and better with those who judge the outcome. Certainly, that would improve any process design, agreed? The problem here is that the interaction ends mostly after the To-Be design stage. Having a very flexible solution that allows changes to flows, rules, content and presentation quickly after the process has been rolled out and found to be lacking will also be beneficial.

    Lets take that thought further along your lines of accomplishing goals and allowing people to perform the right things at the right time. I would translate both to focus in process design on goals/outcomes and not at how to do it. The manager asks that there is always the right amount of light but that it won’t be on when no one is in the room for efficiency. That ‘going green’ goal is documented above the switches. When people come into the room they see it. The manager also wants to know how much energy is actually needed to see if his goal is fulfilled and fits the purpose. He can set up the goal and meter himself.

    Because it is easier this way the users simply add the labels to the lights themselves. They have a Chinese working there and he adds them in his language too. But suddenly there is this one guy (or maybe girl) who decides to change the five individual switches to a dimmer and adds a motion sensor. All by himself. No engineers, projects and no communications needed.

    The labeling and the change to dimmer/motion sensor are now linked to the ‘going green goal’ and wherever there are switches people now find a note saying: ‘How about going green?’

    Would that not be fabulous?

  3. Rotkapchen says:

    Why was the developer responsible for any of it? That’s your first problem

  4. Rotkapchen says:

    Ok, sorry — jumping to conclusions. I know it ‘said’ designer, but all the behaviors oozed of developer.

  5. kswenson says:

    Rotkapchen, A developer is a designer — there is no distinction. Like a chain being as strong as the weakest link, a piece of software is no better than the worst block of code. How would you imagine it working if developers were NOT responsible for their work?

  6. Rotkapchen says:

    A developer is a designer of code. A developer should never be a designer of interactions. That’s why most software is such a mess — it might run great, but running in the wrong direction is of little benefit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s