Stop here

In the morning today, I noticed that one of the signs at a fairly busy red light on the drive to the park’n’ride had been changed from “Stop here on red” to “Stop here on red to activate sensor.” I’m sure most people have seen both versions of this sign, but today I was running late, and I noticed that my reaction to the revised wording was different than to the original.

My initial reaction to “Stop here on red” is that it is a forceful command, with no indication of either what the consequences to me will be if I do not (although crashing into another vehicle is certainly one fairly obvious consequence), or the benefit to me if I do stop there. I think my tendency is to ignore, or even question the authority of the sign.

On the other hand, my reaction to “Stop here on red to activate sensor” was that I wanted to stop right here because I perceived that doing so may cause the light to turn green a little more quickly, and so I might not miss the bus.

It may seem like a fairly trivial moment in the day, but I’ve found that drawing on all the little day-to-day experiences like this one helps me to think about, design, and implement a better user experience.

Why people hate computers

The other night we stopped at Lowe’s on our way home to return the one unused box of tile from our bathroom remodel. That’s one box containing twelve tiles. One box, twelve tiles. The new employee working the returns counter started entering information into the returns software on the computer (Having new employees work the return counter because no one else wants to is a bad idea, imho, but that’s another post altogether).

She asked us the standard questions, “Why are you returning the tiles?”, “Phone number?”, etc. She scanned the barcode on the box, and then looked thoroughly confused as the software asked her a question she didn’t understand. “How many units??”, she mumbled. She asked several other employees about it, and after several who didn’t know whether she should enter one or twelve (one box, twelve tiles), they settled on twelve.

Unfortunately, that turned out to be the wrong answer. I learned later that because their inventory system stores the tiles as units by box, the correct answer was one.

Thinking she had entered the right answer, the employee continued through the software to a point where it informed her that she was about to accept a return of twelve boxes of tile.

Oops, but no big deal. She would just need to change the return quantity, or in the worst case, cancel the return and start over, right? Wrong. When she tried changing the quantity to one, the software created a new return item of one box of tile while also keeping the existing twelve boxes. Now the system thought we were returning thirteen boxes of tile.

After several employees came by and stared at the screen, and several calls to managers, who also tried changing the quantity to one (after a while, the system thought we were returning more boxes that we originally bought!), the conclusion was that someone needed to MIS. M … I … S, cue ”Theme from Mission Impossible” (with apologies to Lalo Schifrin).

At this point I thought, ok, she’ll make a quick call on the store phone, and an MIS geek (I can say “geek” because I am one), will swoop in, hit the magic keystroke, and all will be well again.

“What’s the number for MIS?”

“1-800-…”

Uh oh.

It turned out that “calling MIS” meant calling some central Lowes MIS division, probably located inside a concrete bunker, deep inside a mountain somewhere (there’s that theme song again).

She picked up the phone and called. After explaining the problem several times, and being transferred to the “right” person each time, she reached someone who was able to help. Apparently the tech support person on the other end had to use some administrative interface to the massive returns system to delete the return record.

About an hour, and several tons of frustration (ours, and the employees’) later, we had successfully returned our box of tile.

In my experience, the biggest reason people hate computers is because of poor alignment of the computer and software with the natural flow of their jobs and lives. Instead of being designed to function in a way that flows with and augments their lives, most software forces people to change the way they already do things. Worse yet, when the software doesn’t behave intuitively and the user makes a “mistake”, there is no easy or obvious way to correct the mistake or get help, either from the system itself or from a human deep inside a mountain somewhere..

Sticky barcode tea, now with paper bits

I like loose tea, and a while back, I bought a Bodum stainless, single-cup tea infuser to keep at my desk at work (I don’t quite qualify as a tea snob, though). When I decided to make my first cup of tea with it, I opened the crinkly plastic packaging and removed the strainer and lid to find that stuck onto the bottom of the strainer, covering nearly all of the holes, was a product barcode tag.

Surely, I thought, given Bodum’s emphasis on functional design, this would be one of those vinyl tags with the nice post-it-note-like adhesive that just peels right off. I might have to run it under some warm water to get rid of the last little bit of residue, but then I’d be ready for a nice cup of tea.

Unfortunately, it turned out to be the paper variety with the unnecessarily strong adhesive. The ones that come off in bits the size of grains of rice and leave their sticky backing firmly attached to the product.

I prefer milk and honey in my tea, rather than ink, paper, and glue, so hopefully soaking the thing for a while will get rid of the tag remnants.

In general, I like Bodum products. My experience has been that they typically do what they say they will, and have nice design aesthetics. While I don’t know for sure that the tag was put there by Bodum (I bought it on Amazon), it seems like it was since it had a bright red Bodum logo on it. I do know, however, that the tag turned a potentially nice product into a very frustrating initial experience.

Design and Engineering

A few weeks ago, a colleague pointed me to this article, which led to several other sites, including this one. This colleague and I have discussed the issue of the role of graphic and interaction design in software before, and we tend to agree that there’s a lot of embarassingly unusable software out there. However, I feel very strongly that putting the blame solely on programmers misses many of the more important aspects of the problem. It’s an easy cop out to point at the people who wrote the code and say it’s their fault.

To understand where I’m coming from, consider this question: Who created the specification for the visual and interaction aspects of the software to which those developers wrote the code?

One possible answer is that there was no specification for visuals or interactions—not even a napkin drawing. If there was no specification, then it's extremely likely that no one has really thought about it, and by no one I am including the domain experts, customer liaisons and reps, managers (both technical and non-technical), and developers. If no one has thought about it, it seems a bit ridiculous to expect a beautiful, elegant, and highly usable interface to emerge out of sheer hacking or luck. Unfortunately, in my experience, that seems to be an acceptable expectation in industry.

Yet another possible (and typical, in my experience) answer is that the developers themselves created a specification, either in some document or set of drawings (paper or electronic), or in an ad-hoc way, possibly even on the fly as code was being written. One big problem with this is that developers are not trained in design. They are trained in algorithms, data structures, network protocols, etc. In advanced programs, that training can extend to object modeling, software architectures, and even software project management and the business skills necessary for running a software company. Their training may even include the dreaded GUI programming course(s). In my experience, however, it is extremely rare for any areas of the typical computer science or software engineering curriculum to include interaction design concepts such as mental models, metaphors, and affordances, or visual design concepts such as layout, typography, color theory, etc.

The fact is that, most developers simply are not trained in these areas. However, in my opinion, that is the not the problem. The problem, I believe, is that the general expectation of most executives, managers, and developers themselves, is that all developers can do these design activities effectively. To put it simply, developers are expected to do something they were never trained to do.

Developers are very good at solving problems that involve logic and complex algorithms to process and transform data, but they are typically not good at creating, for example, a color palette that evokes a certain emotional response, or a text and widget layout that leads the user effortlessly through filling out an online form, yet we consistently expect that developers take on the role of design experts. Would it be reasonable to expect a graphic designer to write a program that solves the Towers of Hanoi? Or to create an XML parser? Or better yet, to create efficient and elegant implementations of those things? Or how about a well-defined system architecture for an inventory system to track millions of items across multiple geographically distributed warehouses and distribution centers in near real time? These are not reasonable expectations because designers are not trained to do these things, and typically do not have industry experience doing them.

I think the revival of design in Web 2.0, along with several higher profile companies who have focused on design has started to change the expectations a bit and to educate people on the benefits of good design. Unfortunately, I think it will be a while before the benefits of good design percolate up to the point that expectations really start to change on a large scale.