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.