Adaptive Path Blog

For the longest time, I was skeptical of the value of personas in the user-centered design process. They felt too narrow, too constricted, too idiosyncratic for me to design for.

That’s changed of late. User research is primarily about empathy — getting designers and developers to have empathy for their users, and be able to deliver products and services that really appreciate the users’ needs and goals. And personas are perhaps the best tool in the user-centered design toolbox for communicating empathy — they feel like real people with real concerns, and when crafted well, can transfer insights realized through research to other members of the project team.

Because, for me, personas are all about empathy, I get riled up when I see persona deliverables that diminish the reader’s capacity for empathy. And perhaps the most pernicious element that I keep seeing cropping up in personas is the “user type.”

Here’s a persona chart developed for Kivio, a diagramming tool similar to Visio. (I found it here.) There are many qualities I appreciate about this chart, such as just enough information to understand who these folks are (more detail if you click the link), specific characteristics about how they would engage with this product, good images to help us believe in these as individuals. All of these are great at creating empathy for them, and helping designers better understand how to serve them.

But there’s one thing that keeps them at arm’s length: “The researcher,” “The Sysadmin,” “The OSS Developer,” “The CS Student.” It is common practice for personas to be given these kinds of user type labels but that practice diminishes our ability to empathize.

It might seem like a small thing, but the moment these folks are typed they become members of a class, and their identities are now of being in those groups — and you start referring to that persona as “the Sysadmin” and not “Donald.” It doesn’t take much to go from typing to stereotyping–”Sysadmins want these kinds of features”–and once that happens, empathy is lost.

THIS is our baby.

Originally uploaded by b-may.

Hank Mason, newborn son of AP COO Bryan Mason and Maggie Mason, Mighty Girl and sometime AP Copywriter. Born today! Mazeltov to all!

Last year the Smithsonian produced a wonderful traveling show: Doodles, Drafts & Designs: Industrial Drawings from the Smithsonian. The exhibition was based on drawings produced by ‘engineers, inventors and designers’ and explored the different ways those drawings are used. Many of these drawings are now available in an online exhibit.

Aside from my immediate interest in the content, the exhibition called to mind recurring discussions we have internally or with clients about documentation. Often disagreements about the type, nature or amount of documentation required can be traced to confusion or differing assumptions about the specific function of the documentation in question. Complicating matters further, documentation can often explicitly be used to serve multiple functions. If you’re just exploring potential solutions, a transitory whiteboard sketch is sufficient. In contrast, when passing a ‘final’ design to a development group your team may never get to interact with, documentation needs to be more substantial. Wireframes in particular seem susceptible to this type of confusion or disagreement as they can be used to fill so many different roles: exploration, documentation of process, documentation of the solution, guidelines for development, demonstration, persuasion, explanation or contract mandated deliverable.

It can be helpful to remember that often the goal is not documentation but communication, and that communication may or may not require documentation as an actual artifact. It can be even more helpful, when documentation truly is required, to step back and determine what exactly it is that you are trying to accomplish.

For nearly a year, I’ve been pleased to tinker with and present multiple times the great set of slides that my co-worker Ryan Freitas created: Beyond Wireframes (418k pdf). It’s a look at three different experiments we’ve tried (and are trying) at Adaptive Path to document applications, especially web applications built in Flash or Ajax. Because this is a pdf version, the low-fi animations don’t work, so I’ll refer you to Brandon’s post about using keynote as a prototyping tool that is shown in the presentation. Thanks, too, to Bill Scott for the Frame-by-Frame example.