At our onsite all-day Museum Informatics class on the campus of the University of Illinois, Urbana-Champaign, we were introduced to the concept of personas in the design process.  It was quite mind-altering and made a tremendous amount of sense – how critical it was to design an application towards imagined (identifying kinds of people who might use it) personas rather than what seems to happen most in the technological field (and boy, have I seen this!) – designing it for yourself.

Meg Hourihan in “Taking the ‘You’ Out of User: My Experience Using Personas,” identifies this issue.  It is literally taking the ‘you’ out of the user – a sort of unconscious (sometimes not!) narcissism that if I design this for myself, I’ve designed it for all users.  Hourihan discusses how her startup company Pyra (anecdote: same company that developed “Blogger” software that bought by Google) were developing a project management tool and “assumed we were developing our product for PEOPLE JUST LIKE US, so we could make assumptions based on our wants and extrapolate those desires.

It wasn’t until Hourihan discovered the work of the originator of personas for software development – Alan Cooper’s “The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity” that the fallacies of these assumptions were tested and came tumbling down.  When her team actually developed the personas during pre-beta development, they found out – WHAT?  – “Not only were the personas not all like us – our personas wouldn’t even be able to use the system were were building for them!”

Hourihan wonderfully elaborated on mistakes and boy, are these good:

  • Mistake 1: We chose flashy technology over accessibility.
  • Mistake 2: We assumed users would be more impressed by a robust interfact that couldn’t use than by a less elegant application that they could use.
  • Mistake 3: We thought we were the primary persona.

Developers and designers, listen up.  These 3 “mistakes” or should I say “critical observations” should be part of your daily mantra when designing and designing for personas.

Alan Cooper in his online journal on “The Origin of Personas” discusses how he actually play-acted his personas:  “…I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program.  I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms.  Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkable effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.”

When I was put in charge of re-designing Microsoft Money in 1995, I had no idea that the play-acting I was doing for my personas was actually a formalized protocol.  When we selected users for the usability testing, we attempted to gather persons that covered the gamut of who we were targeting this product for – from young to old, from inexperienced to savvy, from someone storing their banking stuff in shoeboxes (me too!) to those who were diligent about their budgets.  We also had them run through several scenarios to see how they liked the software.

I was struck by these users and how distinctive they were.  I particularly was effected by a grandmother who told me so much about how well the interface was working – no computer experience, wrote checks by hand, and she got it and loved it right away.  I also took away from that usability test getting into these types of personas and while I was designing, think, “What would Grandma (not mine!) think, want, do or what would College Student do, etc.”  I had no idea that I was designing for personas, but have to say it was highly successful.

Part of this is that you respect the personas.  I think there is evidence of creating a bad persona or putting down a persona and I can’t think of any better example than Microsoft Bob.  Some or actually many of you have maybe never heard of Microsoft Bob (and those of you who do, I can hear your screaming).

Kim Goodwin from Cooper (Alan Cooper’s company) calls this “Taking Personas Too Far:”  I recently heard about a Web design agency building “persona living rooms” that are furnished and decorated according to the personas’ tastes and filled with magazines the personas read.”  Microsoft Bob was a major bomb (perhaps the biggest bomb in Microsoft software history) that took a persona too far, too literally, and was based on a denigrated image of a persona.  Voted 7th in PC World Magazine’s top 25 worst products of all time, Microsoft Bob was designed as a “user-friendly” Windows interface and applications for the average Joe (or average Bob) who was computer-naive or intimidated.

And this is where Microsoft looked down upon the user – the average Bob – the idea of this hapless, perhaps dumb and confused person – who needs 16+ horrible animal and animated object guides to help them in an interface that is within a room.  That was Microsoft’s greatest sin on Microsoft Bob – disrespecting the targeted user, dumbing him down from a sense of technological and academic superiority.

Research was not based on fact and real-world but on high-paid Stanford academic professors and researchers telling them this is how new users behave and what they want.  NOT!  Alan Cooper speaks of this when he describes true persona development, calling it counter-logical:  “I suspect that this is why they originated in practice rather than in the laboratory or in academia.”  With all its high-paid tomfoolery, Microsoft Bob was an insult to all users everywhere.  Even the name “Bob” was insulting to “Bobs” everywhere, as if they were dullards. (Microsoft paid Nike-famous ad agency Weiden & Kennedy to come up with that name.)

Here’s nicely written bit about Microsoft Bob called “The Bob Chronicles,” irreverently and accurately calling it “The amazing true story of the software that DIDN’T change the world.”

Lesson learned (we hope!).