The Dilemma of Good and Bad Examples
By Bernard Rummel, SAP AG, Usability Engineering Center – 10/27/2000
So you want to give one of those usability talks again. You want to demonstrate a principle and use examples to illustrate it. Being a gifted teacher you look for examples on how to do things right, not just where someone screwed up again. You try really hard to find good examples. Do you find any? You're lucky if you do. Even more so if you find an audience that does not scrutinize your exemplary site and start interrogating you on how you could have possibly overlooked those bugs.
Why are there so many bad examples around and so few good ones? Or rather, why do we always end up talking about bad usability, even when we want to focus on positive examples?
Bad stuff sticks out. After years of usability work you are highly trained at spotting problems within seconds. Sometimes it's even entertaining to watch how people screw up over and over again. Ha, don't they ever learn? It's a bit like dealing with real estate salespeople (no offence, folks): you know they're lying; you just have to find the lie. Here, you just know there is a usability problem, you just have to find it.
It must be a kind of an occupational hazard. It's like the old teacher's fallacy: if you react to poor performance, it will necessarily improve because it was bad in the first place. If you react to excellent behavior, it won't help because there's nothing to improve. So you end up only criticizing because this has proved to be effective.
But seriously - excellence is hard to spot. I believe it's rare indeed - probably because good design requires skills no one would admit to not having. Furthermore, good design is easy to destroy - and people are really good at that!
But assume that for once, you do have a good example. The one perfect interface. Simple. Obvious. Powerful. You start showing it around. Did you expect these reactions? "So what?", "I don't like the font", "Looks boring. Can't you spiff it up?"
Let's face it: good interaction design examples look plain at best. Usability problems stand out, so you can't help noticing them. But good interaction design makes things go smoothly. So real quality is nearly invisible. This is truer the more complex your design problem is. Complexity and context is what interaction design is all about. How can you present complexity and context and not bore an audience to death? Can you imagine a crowd going: "Wow! Look how smartly they applied this interaction paradigm in that workflow context, using this metaphor which is wonderful for this user persona under the particular circumstances of using certain applications in parallel which is most likely the case in the circumstances we are prone to find here."?
One of our daily prayers is, "You are not the user." Well, neither is your audience. I think this is the point we have to deal with somehow. You like it. The audience doesn't (yet). Or, more precisely: You think users will like it. The audience might agree. But will they understand why?
The easiest way to go about this is the "it's great because" approach. List all the benefits of the object of your affection and hope the audience believes you.
Markus Latzina from the SAP Usability Engineering Center and I tried a different approach recently with an audience mostly consisting of developers. To start off, we had them quickly build personas. For the first time in their lives, most of the audience experienced the challenge of thinking up "real" people and just knowing what they would like and dislike. This took about 10 minutes. Next, we showed the web sites we wanted to feature and asked the audience how "their" persona would react and what he or she would do. For the first time in our lives we did have "aahs" and "oohs" while talking about entry fields and dropdown list boxes. Even more interesting for us were the "aahs" and "oohs" in unexpected places. We learned the most when the freshly-created personas surfed away from "our" sites to the ones that fulfilled their needs even better.
They showed us good examples we didn't even have to search for.
