Persona 1.01
Written by Anna Leah Berstein Simpson and Ariane Faraldi.
Building personas
Personas by any other name would be characters, right? Not quite. Charged with studying Lene Nielsen’s online textbook on Personas in The Encyclopedia of Human-Computer Interaction, 2nd ed, we encountered a complex topic that initially seemed simple. We’d like to translate some of the central concepts of the text into phrases and ideas that a layperson can understand.
Personas: A How-To Guide
First, Nielsen defines personas according to their native habitat (perspective). Yes, personas are largely fictional characters with traits that make them behave certain ways in certain situations. No, they are not stereotypes. Yes, they dream, work to achieve goals, and encounter obstacles along the way, such as poorly designed web interfaces (sorry for the spoiler). As we’ll see, designers, companies, and other organizations each use personas to help themselves imagine how a user might interact with their products. Nielsen sketches out four perspectives that often characterize personas but does not specify whether these perspectives should function separately or in concert. The first, the goal-oriented perspective, prioritizes a user’s work-goals and interaction with the product, including the user’s emotions, and prioritizes finalizing the persona for actual use. The second, the role-driven perspective seeks to compensate for the emphasis on designers by communicating more empirical data to the overall team. The “role” refers to the envisioned users’ place in the market. If these first persona-perspectives seem dangerously close to stereotypes, fear not, for the engaging-persona perspective seeks to evoke empathy in the designers by presenting the personas as beings with interpersonal relationships. Nielsen notes that it too requires strong empirical data, not merely ethnographic study. Nielsen clearly favors the engaging persona. We, however, support the underdog fiction-based perspective, which often pops up on an ad-hoc basis, in the form of temporary ideation tools that help designers work reflexively. They’re often pastiches of extreme characters drawn from fiction, such as Vernon Dursley or Minerva McGonagall, rather than data-driven, unique personalities. The persona should evolve from a designer’s creative process, to be informed by data and study. Unfortunately, Nielsen does not specify the types of data she imagines will accompany these persona, muddling our grasp of data-driven personas.
Instruction Manual
While personas may seem relatively simple, they’re surprisingly complex. They require “data,” though we’re still unclear on what kind, and force a designer to dedicate substantial energy to devising these characters. Nielsen doesn’t mention one of the prohibitive aspect of personas–the cost! Perhaps she assumes her readers understand that aggregating data, conducting studies, and devoting company time to “making stories” quickly becomes incredibly expensive. As such, it’s imperative that we make efficient and effective use of personas to amortize the investment. Nielsen offers a 10-step plan, englobbing 4 key criteria, to follow when designing and using personas.
The place of scenario and story-telling in the process.
Personas don’t just live in a bubble, though. They’re actually an important vector for bringing storytelling into the design process. Nielsen explains that personas most effectively evoke empathy when they become characters in scenarios. The scenario takes the persona, the complex character with emotions and goals, and essentially imagines how the persona would react when faced with the product at hand. Just like a typical story, a scenario will offer a beginning, middle, and end. Again, just as with the actual construction of the persona, the scenario must brim with realistic details that enliven the otherwise dull narrative (“Bob wants to play solitaire”) to epic proportions (“Depending on whether he’s using Mac or Windows, Bob must overcome the blue screen of death or the spinning wheel of death to vanquish the perilous game of solitaire”). Needless to say, each persona will behave differently in a given scenario, giving further weight to Nielsen’s proposition that design teams create a range of personas. It’s clear that multiple personas and multiple scenarios can only mean good news for the creative writing majors among us.
Conclusion
Before we close, leaving our dear readers thinking we’re just persona Pollyannas, we do have some questions to ask our readers. We’re still confused, for instance, about the actual form that a persona should take. Do they remain encased in a typed document that circulates among the group? Do they resemble baseball or pokemon cards, that people can trade or collect? Can successive teams make as effective use of older personas if they hadn’t participated in their creation? Questions of successful transition and recycling loom large considering the sometimes prohibitive cost of producing these personas in the first place.
For persona novices, we’d like to reiterate that designing personas is usually not a goal in itself but rather part of a greater mission. Ideally, creating and using personas would place UX, including a user’s emotional response to a product, at the forefront of the design process. We’d also like to stress the flexible nature of the personas; they’re supposed to inspire change and reflexion, so don’t wait until the project is finished to start using them! Be sure to leave us a comment telling us how your team has successfully or unsuccessfully used personas in the past.
OpenEdition vous propose de citer ce billet de la manière suivante :
afaraldi (10 février 2015). Persona 1.01. Introduction à l'architecture de l'information. Consulté le 25 janvier 2025 à l’adresse https://doi.org/10.58079/be6a