Being Rude About Alan Cooper

Alan Cooper: feted genius, father of Visual Basic and giant of user-centred design. Jonathan Baker-Bates: pitiful, microscopic nobody. But at least I’ve designed a few websites…

I assume Alan Cooper hasn’t designed any significant web sites because Cooper Interaction Design only lists one in its case studies, and that is HP Shopping. Cooper (or more likely his acolytes) identified a needs-based persona and presumably designed for that and not any others, as per the methodology handed down by the great man. HP then ditched that design for a solidly features-based Endeca boilerplate a couple of years later. Oddly, the only thing Cooper says about the project in terms of results is that most users would have recommend the site to others. The lack of any reference to sales, or even traffic, speaks volumes to me about Cooper and their work for HP.

What is this savage attack in aid of? Nothing really. I’m reading The Inmates again. I’ve sort of read this before, but I find it hard to concentrate. The reason I’m reading it this time (the 2nd edition) is partially because I’ve had another crisis of confidence about personas, but mainly because I said I needed a wisdom refresher, which I do quite regulary.

On one level, personas are a great idea: they allow the various disciplines across a project to sing from the same songsheet. They allow you to design the system to suit a specific audience. They attenuate scope creep, settle arguments and bring clarity by having the development team focus on users of the system and their goals, not mere features and tasks. These users can be based on an amalgam of real people – researched and quantified, or unreal: theorised and reverse-engineered from other data.

All this is well known and documented, and I agree with it. But I have a problem, and that problem relates to how the web is fundamentally different from the world of traditional software design. Reading Inmates (and About Face come to think of it), makes me think that Cooper has a blind spot when it comes to the web.

To illustrate why, take Kim Goodwin, Director of Design at Cooper Interaction Design, explaining the party line with a précis from the great leader’s book on the subject of the divergence between marketing profiles and usage personas:

“Many product managers and executives are surprised when there isn’t a direct correlation between market segments and personas. The people who bring in the most revenue may not be the best design target. If you were designing an in-flight entertainment system, a frequent business traveler—every airline’s most valued customer—would be a tempting design target. A business traveler would actually make a poor design target, though, because he would be too familiar with flying and with using computers and other gadgets. If you design for the business traveler, the retired bricklayer going to see his grandchildren won’t be able to use the system. If you design for the bricklayer, the business traveler will also be happy.”

The example she (or, er, he?) gives is the fabled in-flight entertainment system used as an object lesson in persona-led design, which Cooper describes in some length in his book. And what of it? Surely it’s a system like any other, no? No. It’s a system with a captive audience. On the web, all your users are a couple of clicks or a Google away from other people’s sites. That’s a fundamentally important concept. In designing a commercial web site (assuming it has any sort of competition), the primary job of the design is to stop them going elsewhere or closing their browser. If users don’t like their call centre management UI, SAP order management screen or (cough) spreadsheet program, then they’re out of luck. Using anything else isn’t an option.

Next, consider the somewhat smug (and dare I say unsupported) statement “If you design for the bricklayer, the business traveler will also be happy.” That may be so in this particular case, because everything the bricklayer can do or is interested in, the frequent traveller would be able to encompass as well. To make an equivalent statement for a web site, you’d have to say something like: “If you design for the retired bricklayer, the gadget freak will think the site is boring and leave, never to come back. If you design for the gadget freak, the retired bricklayer will learn to love the Google Earth and folksonomy grooviness.”

So at least one problem with Cooper’s persona-led approach here is that it’s too inflexible. There is no way that I would be able to get away with the above approach in any commercial online context. Let’s look further at how the delicate underbelly of persona development gets cruelly lacerated by the rocky outcrops of web design for business:

In the design process for fruit4u.com, a site on which you can buy high quality fruit at bargain prices, a persona called Sue is constructed from a two-week user test and some thinking around marketing data. This is because (predictably) the people who buy the most fruit are technophobic middle-aged women keeping a household together. However, while Sue can see the advantages of buying on line, she would probably never consider doing so because she likes the social elopement of shopping. Moreover, Sue is in charge of purchasing fruit for her household because her husband and two teenage daughters would rather stick pins in their eyes. That leaves Bob the single divorcee living alone and working in sales, and Susan the flighty secretary. Bob hardly ever buys fruit at all but might do the odd purchase of a bag of organic apples, or a case of grapefruit from time to time. Susan’s buying pattern is similar, but she likes the high-margin exotica. She’ll love the “inspire me” feature on the new site, and might well spend over a ton on some Mongolian star fruit and paw-paw presentation packs once in a while.

Now, you could say “If you design for Sue, Bob and Susan will also be happy” and that may work. What Cooper says you must not say is “Let’s design for the lot of them” because that dilutes the direction and removes any advantages bestowed by the use of personas in the first place. The business, however, wants all of them because it knows they are all customers of varying value. So what’s a poor designer to do?

In reality, what happens at this point is a disconnect between the persona development and their ongoing use in the design. Having established the personas as a useful source of direction and a good excuse to find some time to study the form and conduct some research into an area they know little about (like buying fruit), the designers simply use their best judgement. The site is then covertly designed to appeal to as many people as possible, despite the presence of smiling faces and imaginative naming of personas in the discovery phase. In most cases this means they design for about three out of perhaps five or six personas they know about, and that all of these overlap so much as not to support much sustained analysis. The other approach is to explicitly segment the website on the home page – one “door” for each persona. For a bunch of reasons I won’t go into here – that approach is rubbish.

In my opinion, the designers that best pull off the trick of catering for multiple personas do so through the use of good interaction design based on their professional experience. Apple and 37 Signals come to mind here, and I have no doubt Cooper is good at this too. Perhaps supremely so – if anyone working for Fujitsu Softek or Sony Trans Com could verify that, I’d like to hear from them. But in any case, whether this design is informed by personas or not is usually never articulated. It stands to reason that providing clear signposting, navigation, information design and affordance will suit most people most of the time, even if the actual function might not.

So, the use of personas in web development projects continues to be confused. Glance at any discussion of them on IA mailing lists and the sheer lack of consensus is plain to see. To be fair though, this isn’t Cooper’s fault. He was after all writing at a time when the web was young, and I have the advantage of hindsight. It happened with the Polar Bear Book and many others, and it would be pointless me lambasting Rosenfeld and Morville because everyone knows things have moved on since then. What’s different about personas though is that there’s still some pretence going on in some quarters that the Cooper method applies just as well to the web. It doesn’t.

So what’s my prescription? I don’t know for sure, but something along the lines of my technique of declaring a project artefact deprecated (just as I like to do with site maps) is in order. The trick being to make the declaration at a time that’s beneficial for the project lifecycle. But I need to think on this a bit more… still blogging.