What I Have Against Contextual Design and Personas

Last night Boriss wrote a great post about the benefits of the contextual design process. Aspects of the contextual design process like the inquiry, work modeling and environment design are all incredibly important skills for a UX designer to have. However, I couldn’t disagree more with the premise that this process should have been applied by Lead Ubuntu designer Ivanka Majic in the design of the window manager.

Limitations of Contextual Design

Contextual design makes a lot of sense when you are considering a product for a rather specific use case. For instance, an application that helps doctors track the medical history of their patients throughout the day, or data visualizations for an investment banker. In these situations there is a lot to discover about the users, their tasks, their underlying goals, their environment, the situations where they fail, the situations where the succeed, etc. Basically, there is loads of context, and potentially a lot of context that hasn’t previously been considered in the horrible interface they might currently have.

So contextual design is really the most effective when designing to a specific audience. And this is also it’s limitation: applying it in situations where there is no specific audience is simply going through the motions and structure of a formal design process for no reason. Who are Ubuntu’s users? Humans. What do they do with their window manager, they want to manage windows.

Limitations of Personas

A similar design process is the use of Personas (not the lightweight Firefox theme, but the notion of creating a small set of hypothetical users who embody the attributes of the users you are designing for). Personas are an effective way to make sure that your product isn’t just connecting with users, but with the right kind of users. For instance, if you consider a game console there is really a pretty wide range of users who it could appeal to, from hard core gamers in their 20s shouting obscenities into their headsets to middle aged women doing Yoga on a balance board. The Xbox 360′s design appears to be very directly influenced by the three specific personas that they targeting: Striker the hard core gamer, BeatBuilder the technology trendsetter, and Velocity Girl, the casual gamer and creator of virtual user generated content. And even though they never really delivered on their persona of Velocity Girl, the vision of having that type of user was nonetheless inspired (in a wanting to implement Snow Crash kind of way). Personas help you focus your product on a specific vision when there are an infinite set of possibilities.

Designing a Better Doorknob

But let’s say we are creating the type of thing that nearly everyone on the planet might end up using at some point, like a window manager, or a Web browser, or a doorknob. Understanding the context is pretty trivial, and building personas for the door knob only really makes sense if the interactive design firm is charging by the hour (kidding).

But does this mean that we must fall into the trap of what Aza criticizes as “wishy-wasy design speak” that makes us look like we are pulling the Science of interaction design out of our collective behinds? Not at all. In fact, you can launch an entire career as a top tier usability pundit simply by quantifying how to build a better doorknob.

Designing Better Window Controls

So if getting context about users through the inquiry process and building personas doesn’t help, what aspects of interactive design should we consider when creating window controls? Off the top of my head two come to mind:

Self Describing Visual Language: the controls should visually represent what they are going to do, without the user having access to any external information like a manual, a helpful friend or memory of having used them before. This is an aspect where the the street light metaphor being used by Apple fails. The first time you look at them you realize that they are communicating using only color (and at one point a fourth control was telling the user “Purple!”). If the user ever waits for a tooltip to fall back to literal language your glyph has failed.

The new Ubuntu controls say more to the user than OS X, but they don’t fare particularly well in being self describing either, visually they seem to communicate that one control will move the window upwards, and another control will move the window downwards, sort of like a scroll bar. They don’t communicate that the window will be transformed.  The visual communication used in Windows is considerably more literal, choices include “big box” and “small thing at bottom.”

All
Natural Mapping: in general controls should be placed in a position relative to the effect that they will have. For instance, on a lot of stove tops if you have four burners you will also have four dials in the exact same configuration. If controls don’t have a natural mapping and the user falls back to point one (visual language) looking for pictograms of which dial relates to which burner, the natural mapping has failed. Ever turn on the wrong light switch, perhaps every time you try to turn on the correct one? Odds are it doesn’t have a natural mapping to the lights in the room.

For window controls you could make an argument that as the window maximizes it’s corners stretch outward, so the most natural mapping for the maximize control is on the outermost edge (regardless of side). I think the reason we don’t see any of the three designs going for this is that close is simply used so much more that it is worthwhile to give it more prominent visual placement when looking in from the side of the window (even if it violates what would be a better natural mapping).

So there is still plenty that the field of interaction design can offer to the design of simple everyday interactions, even if the context is “using the thing” and the persona is “a person living on planet earth.”

3 comments

  1. Alex, thanks for the marvelous post about the buttons. Another aspect of interactive design comes to mind as being useful for the buttons is TEST it with users.

    User testing isn’t hard, but it does take effort. That’s why I created http://www.betterubuntu.org. I hope to bring the community into user testing for Ubuntu by giving simple howto’s, and conducting lots of user tests with some random users myself.

    Obviously, these tests might be better for things like the installer than windows controls, but it would still be nice run some tests with both button layouts and see what happens.

  2. Interesting how you use stove tops as an example for natural mapping. I find stove tops to be a prominent example of how *not* to design a UI: The only thing they have going for them is that there is the same number of them as there are burners — but they are almost never arranged in a way that maps to the order of the burners. Without looking at the pictograms, there’s no way to know which knob goes with which burner.

  3. Re; Natural Mapping – Nice article. Skype site designers need to read that every morning.
    I was once hired to deliver a 90′s Bentley and was impressed that the console-mounted power seat controls were omnidirectional, miniature seat models without labels. What could be more natural?