Personas help focus your work on the needs of real-ish users. In most places I’ve been, I’ve seen that over time the customer kind of morphs into a gelatinous mass of jumbled memory as contact with the actual end user is replaced by a marketing proxy. It’s a common experience, and there’s ways to reinvigorate your bowl full of jelly into something resembling actual users again.
Last summer I attended David Hussman‘s Agile Product Planning: Building Strong Backlogs session at the Agile It! Experience 2008 in Reston. One thing that stuck with me was his goofy graphics of personas, and their alliterative names. Among many things, he talked about smells that creep into your planning process and how these usually indicated a loss of focus on the user. Smells like refactoring or engineering stories becoming common place instead of rare, and people talking about a “thing to do that takes time” instead of telling stories about how this work will help someone.
He went into lots more detail, talking through the anatomy of a story, how to avoid letting the structure become so rote that it’s not doing its job, making stories testable, and pushing you to question the team if they think stories are hard to tell for a piece of work. The main piece I’ve latched onto lately, in hopes that it can help drive out some of the smell and impact the others, is his way of writing up personas. I’ll describe the finished product first and then come back to how they might be constructed. Near the end I’ve attached the template I made for Apple’s Pages program in iWork ’08.
First, use a color picture and print the persona pages in color. A picture of a real human being does amazingly subtle things to how you view interactions with data. Just ask anyone that uses Apple Mail and sees the contact picture on the email as they read it. It creates an empathic reaction that just can’t be done with text alone. Do it. A few minutes on the Creative Commons search will make it easy.
Next, make sure each persona has a name. David Hussman really advocated using a name that has alliteration as a simple way to remember who’s who. I try to find a name that’s both fun and realistic (search for Chinese baby girl names or Tongan baby boy names if you need some help with modeling a global user base). The name ends up feeling like “William the Conqueror” or “Fredric the Shy” when you’re done because you have a real name and a tiny window into the personality.
Description is key in my book. David’s examples used bullet points. I chose prose instead to get the feel of actually getting to know someone. Think of yourself as the announcer on some reality TV show if you can’t get into the swing of things beyond a couple bullets. Knowing that “Damion the Data Admin” loves to come into work early so he can go skiing every afternoon from November to March may seem useless at first. But when you realize that knowing seemingly innocuous trivia helps you recognize that if you add a feature that requires Damion to physically click OK 4 times over 90 minutes every day at 5pm, he’s gonna not like you or your silly software. Don’t overdo it, but do add enough personality to remember that your software is not the center of this person’s life. They’ll drop it like a rock for chatting with a coworker, attending a kid’s soccer game, or jumping up to salute the boss. Again, this is to provide some low empathic response for the group you’re talking about.
After your little two paragraph bio on your fabled persona, the next item is Values. I’ve found that I like David’s example of bullet points here. It seems natural to call out simple value statements in harmony with the background you’ve developed for this persona. To me, the values often give you ideas on how this persona would make tradeoff decisions, and it can be enlightening as an engineer to experience that from different angles (personas). An example bullet under the Values heading might be something like, “* Visible indications of task progress, since he works in this application infrequently and likes to know his cumulative time here has been well spent.”
Finally, the Key Facts seem to trigger reminders about the general situation of the persona, or about the group this persona represents. “Limited computer access,” or “May be 80,000 Arthurs” are good examples. I try to find stuff that’s either not covered elsewhere, or mentioned but not highlighted. You don’t want people to just read your key facts as a summary instead of actually getting to know the persona, because that’d defeat the purpose.
Feel free to grab my iWork persona template below and hack it up however you’d like. Drop it in your home folder in
Library/Application Support/iWork/Pages/Templates/My Templates/ and it will appear in the My Templates pane of the Template Chooser. Whenever I make a new persona, I change the fill of the box below the picture to a color I pick out of the new photo. Next I go adjust the color of everything in the template to be that color (pick from the box, instead of the photo for consistency). Even the background box behind the Key Facts will work if you just use the same color (it’s opacity is less than 100%).
I’d love to hear about your use or abuse of personas in your planning process, and ways that you’ve made it fun and practical to know your real customers.
Download iWork Pages Template from GitHub project.