I fell in love with user personas when I was helping Polaris re-think their website. I had written an RFP and one of the firms I dreamed of us being able to hire sent us two booklets from the A Book Apart series, and one of them included a long section on ethnographic research and user personas.
I had conducted formal research interviews in college, so the approach felt truthful to me. Then I got to part of the chapter on using user personas tactically. The A Book Apart books are great at talking to their audiences: web managers who are more-often-than-not matrix managed, the only technical person in their vertical or entire organization, and always, deeply in need of tactics for generating buy-in for industry best practices. That’s why the book provided scripts and tricks for getting people to follow best practices, people who don’t think about computers and websites and traffic all day. One of those tactics was user personas.
For those who don’t occasionally design websites for fun and profit, user personas look like this:
Update from 2019: The previous image has been taken offline and replaced by this one, from usability.gov
They are specific, representative overviews of 3 – 5 intended and actual audiences for a given product. From those simple bios, any number of uses can come. They can test the intended workflow of a product–the user story–and see how it impacts that user’s life. They can be used to hone tone of a given page to the needs of a specific but fractal persona. They can be hung in a content creator’s office, to remind everyone on the team who they are writing for.
I was having coffee with a friend who runs online content for a major American city and mentioned user personas as a possible tactic for her website redesign work. She said she hadn’t decorated her office yet, and those user personas might be useful. I love that idea–having meetings, with representative constituent personas overlooking and informing the decisions a city worker makes.
That got me thinking about how to make user personas work for policy formulation. I think many legislators hold in their heads generalized user personas for policy-making: the single mom on TANF, the man who’s just left prison, the 4th grader ESL student. There is danger in these kinds of generalities, because they abstract lawmaking from the daily specifics of living in the world.
The single mom on TANF can be called a “welfare queen” or a “working mom” by elected officials, depending on their experiences and goals. The user persona is not specific enough, because I would like to believe if a lawmaker had to talk about Tiffany Jones (who gets TANF and volunteers at her son’s 4th grade classroom during field trips, wants to go back to college but can’t get into a community college class) then only one of those phrases could be honestly be used to describe her.
In the land of web design, outcomes are less dramatic than someone having her access to food restricted. There are other kinds of drama: two executives walk into a room, one website leaves. But whether the customer served by that website is white man in his mid-20s in San Francisco with an iPhone 6 or a 35-year-old Latina in rural Texas with an Android depends on the executives’ goals and experiences, just like laws depend on lawmakers. It may end up that the website designed for the guy in his 20s works just as well for the woman in her 30s–or it may not. The value of being specific with user personas is those executives or lawmakers have to agree before a single word is written, a single wireframe concocted, a single policy proposal typed. They have to agree on who they intend to work for and talk to.
I enjoy imagining that kind of specificity in lawmaking. To paraphrase a friend who’s a programmer for a mid-sized company in the Bay Area: good product design solves the hardest problem first. She says that solving that problem will solve most of the easier problems down the line. That approach is why so many Masters projects for those in Human-Computer Interaction at Carnegie Mellon focusing on serving people with disabilities. A website that works for someone with motor control issues will also work for someone on a shaking bus downtown.
Consider a writing a proposal for a school breakfast program. Imagine designing a policy to serve the user persona of Ameena, a child of a family who recently immigrated as refugees from Afghanistan and who is learning English while catching up in school. That same policy will also help Jimmy, the working class kid living with his aunt while his Mom handles some of her own issues and who’s a bit behind in his reading skills. The school breakfast program would include signs with a mix of words and symbols to describe the food, a system to get feedback from parents on kids’ allergies and religious restrictions, and before it started, communication from the school district to the parents/guardians/whoever the child is staying with in a variety of forms to make sure they know what the kids in their care are eating. It makes sure Ameena’s parents with limited English know what’s happening, and the robust communication system makes sure it’s Jimmy’s aunt, not his Mom who’s out of the picture, that gets the heads-up that she needs to tell them about his peanut allergy. What works for Ameena works for Jimmy in this case.
The fractility of experiences is what allows us to make user personas specific, to leave some identity combinations out when building user personas. This might be hard for lawmakers, since they tend to want to include everyone imaginable in their ideas. 3 to 5 user personas is more than enough for the work. Every faith does not need to be assigned to a specific user case-study, every country does not need a citizen to be included because, in all probability, a Presbyterian will use the website in the same way as an Episcopal and a child of refugees from Afghanistan will probably be as hungry as a child of refugees from Syria.
They might not, which is why testing and feedback and iteration are vital. That is another blog post, though I think I should keep my fantasy of agile lawmaking to myself. Testing happens with laws through user interviews just like it does with good products. If I walked into a meeting with a refugee agency to get their feedback on my proposal for a school breakfast program and heard there were differences in how a child from Afghanistan and a child from Syria need to be served, then I would modify my user persona and then the policy. If it turned out in my user testing that Episcopals really did have different needs from Presbyterians, perhaps for my e-hymnal site, then I would need to re-write my user personas. That is alright, because from lawmaking to website creation, any effort involving serving humans will have to change with time.
Imagine a campaign office with a row of framed user personas behind the candidate’s desk. She sees them during call-time, and when she’s cutting turf.The backs of the frames would have to be easy to pop open, so the stories could be modified when their future constituents’ needs change. She sees them when she’s doing interviews and tweaking her platform. There they would sit, a constant, guiding presence, informed by the lived reality of the people who she seeks to represent.
Inspirational Quote:
“My people are few. They resemble the scattering trees of a storm-swept plain…There was a time when our people covered the land as the waves of a wind-ruffled sea cover its shell-paved floor, but that time long since passed away with the greatness of tribes that are now but a mournful memory.” ― Chief Seattle, The Chief Seattle’s Speech
