Bring Your Personas to Life!

by:   |  Posted on
“So you’ve got your persona set all neatly defined and documented. Now what? How can you ensure the persona isn’t ‘just another deliverable?’”

Most user-centered design (UCD) companies create personas (profiles of representative users) to guide their designs. To do UCD, you need to get the “U” in focus right from the start. So you’ve got your persona set all neatly defined and documented. Now what? How can you ensure the persona isn’t “just another deliverable?”

It’s in The Method
You may have heard of ’”method acting,” and how Robert DeNiro spent several months on the streets of Manhattan in a cab to prepare for his role in the movie Taxi Driver. He did this to understand the life of a taxi driver, so for movie-goers, the character felt realistic. He didn’t get advice from the drivers on how to act the role, he simply observed and eventually “became” a taxi driver, enabling him to empathize and see the world from their unique perspective.

Method acting is a technique in which actors try to replicate the emotional conditions under which a character operates, in an effort to create a life-like, realistic performance. “The Method” typically refers to the practice of actors drawing on their own emotions, memories, and experiences to influence their portrayals of characters.

Your persona is your “character sketch.” For software development projects, it may include information about the persona’s demographics, attitude, goals, environment, and how he or she will interact with your software in the context of the day. More advanced personas will also include detailed descriptions of activities or scenarios—these become the scripts for your persona to follow.

I figure the typical persona profile has just enough ingredients for our own version of “The Method.”

“The Method” was popularized by Lee Strasberg at The Actors Studio and the Group Theatre in New York City in the 1940s and 1950s. It was derived from the Stanislavski System, after Konstantin Stanislavski, who pioneered similar ideas in his quest for “theatrical truth.”

Strasberg’s students included quite a few of America’s most famous actors of the 20th century, including Paul Newman, Al Pacino, and James Dean.

Method acting combines a careful consideration of the psychological motives of the character and some sort of personal identification with and possibly the reproduction of the character’s emotional state in a realistic way. The best way to gain this understanding is to spend time with the people you’ve identified in the user requirement brainstorm. At the very least try to imagine being that person, then being that person in the act of using the software or system you’re designing.

Those trained by Strasberg often tried to experience all sensations as the character would and often used personal experience on stage to identify with the emotional life of the character and portray it.

Stella Adler, an acting coach whose fame was cemented by the success of her students Marlon Brando and Robert DeNiro, broke with Strasberg and developed another form of Method acting. Her technique is founded in the idea that one must not use memories from their own past to conjure up emotion, but rather use circumstances from their imagination. She also emphasized, like Sanford Meisner, the all-importance of “action” within the theater. She often preached “we are what we do, not what we say.”

Sound familiar? Those of us working in the user experience field often comment, “it’s what users do, not what they say.”

Putting The Method to practice
The following are some of my techniques for method acting with personas. This can be done with a team of one (you), or a team of many, depending on how many personas you have and how many people are on your project team:

* Your project team is your troupe of actors.

* In larger teams, your lead designer becomes the director, and the other project team members are the actors.

* The primary persona is the character sketch for your lead actor (if you have more than one primary persona you’ll need several leading—or possibly “supporting”—actors). Because I work in small teams of 2-5 people, the director and lead actor role are usually given to the lead designer (the person who’ll call the shots for the design of your software, website, intranet, or device).

* Assign roles for the secondary personas to other members of your team—those not so involved in the core design process. You can call on these people as you need them to do a “reality check” on your designs.

* It’s the responsibility of the actors to “become” the personas. They should read the persona profile as a starting point and if possible meet with and observe users represented by the persona to get inside the head of their assigned persona.

* At your design meetings, the actors consider how decisions will affect their particular character. Questions for the persona can be directed straight to the actor. This process can become fun and enable better teamwork, depending on how enthusiastically your actors embrace The Method.

* You can expect both good and bad actors, but The Method gives the personas life, rather than keeping them locked away on paper. A bad actor is still better than a hole in your plot. (In software design, a hole in your plot is when the user experience breaks because a personas requirements have been overlooked.)

* Over time, your actors should get to know their persona profiles so well that acting becomes second nature. That means they become a user advocate—not as an outsider, but an insider.

Method acting is just one technique to better enable user-centered design and is not intended to replace observational usability testing, but it can (and should) work in unison. For each observational user test, your actors will gain even more insights to the real world and can refine their method.

You can’t beat real customers for creating an authentic user experience, but then again, actors do a pretty good job most of the time!

This article borrows some material from Wikipedia, Method acting.

Customer Storytelling at the Heart of Business Success

by:   |  Posted on
“Personas and scenarios tell honest stories that are sculpted from diverse and comprehensive sets of data.”Executive Summary

As most of us know by now, customer personas and scenarios are vehicles for helping an organization continuously keep their customers in their line of sight. Traditional segmentation identifies and categorizes a current or potential audience based upon common characteristics, including demographics, attitudes, behavior, transactions, frequency of interaction, spend, and more. They are discovered by “doing the math,” which may include data aggregation, cluster analysis, factor analysis, and other statistical methods applied to large sample sets. And then segments are given catchy names like Savvy Skeptics, Active Balancers, Indulgent Nutritionist, or Trade-Uppers. When done right, segments are statistically derived from the analysis and synthesis of quantitative data and are a solid foundation for customer understanding.

We create personas to build upon that platform by bringing the individuals within those segments to life. These are prototypical, but fundamentally real, stories of the multidimensional lives of specific customers. Of course they can also be about employees, partners, competitive customers, the press, and others, but for simplicity and consistency, let’s call them customers. These are specific customers with names and faces, but they also have an underlying implicit business agenda-that is they may be “the most profitable customer three years from now” or “the customer that we want to align with our brand,” or “the customer that shops for a product online and then purchases it in the store.” Their stories include topics such as demographics and psychographics, but also include mindsets, motivations, perceptions, personal quotes, actions, desires, measurable attributes and more. Their stories are crafted from real-world business intelligence, the sources of which may range from online surveys to channel-specific transactional data to descriptions given by in-store sales associates.

This report discusses how the Arc Worldwide’s Experience Planning group uses storytelling and multidimensional customer-based stories to provide relevance, direction, and resonance in today’s business planning landscape.

We feel, as do many of our professional peers, that they are a vital tool to provide guidance to and inform decision-making within an organization. Quite often, they are equally useful as a long-term, internal organizational tool. In our design and development culture and process, they are more than just a step in the product, application, or service development process. We have seen them deeply effect the planning of numerous organizations including those involved in product development, service development and delivery, marketing, communications, and customer service, to name a few. The decisions that customer personas and scenarios inform may include new product and service pursuits, details of product and service strategy, marketing strategies, customer relationship management frameworks, media placement and more. Personas and scenarios tell honest stories that are sculpted from diverse and comprehensive sets of data. These stories place the customer and their wants, needs, emotions, and behaviors at the center of a roadmap that charts current and future businesses success.

Within our personas and scenarios, the people and their stories are not arbitrary. They are stories of the lives of our client’s current and potential customers, and they serve as comprehensive guides to how our clients should interact with those customers, in the moment or over a lifetime, to profit their business. Three years ago, personas and scenarios were “a process step” in our iterative, user-centered development process, whereas today they are the platform upon which many of our insights are communicated, and our solutions are modeled. Over the past few years, they have risen in importance and become a primary tool for communicating data analysis, strategic business frameworks, new product and service concepts, and cross-channel brand experiences. We gauge this positive change by the frequency by which they are requested by internal team members and our clients, as well their prolific use by both.

The customer at the center
The best product and application design strategies are created when a team first gains direct understanding of the people who will use the end product-those people that will actually interact with applications, products, and environments to achieve desired goals-and then shapes strategies and solutions around those individuals (or groups or companies). An understanding of the customer is at the heart of every good business. That understanding should inform the company’s product and service development, its marketing strategy, its sales strategy, its mergers and acquisitions, its positioning within the marketplace, and even its organizational structure.

All business decisions impact customers. Customers have real lives, real challenges, and real desires. Businesses have day-to-day and long-term goals of revenue generation, profit margin, market penetration, market, and brand value. We use customer observation, empathy, measurement, and ultimately understanding and predictability to spark new ideas and provide comfort and/or reassurance with strategic and tactical business decisions. The ROI of business decisions ought to be a reflection of satisfying both business and customer desires in mutually beneficial ways. Customer-centric discussions, strategy and results continue to increase their prevalence in the boardrooms. Personas are a clear, comprehensive, human way to tell those stories.

Most importantly, identify who your customers are
Segmentation may identify who your customers are, but companies must also work to prioritize those segments. Through the combination of quantitative and qualitative methods that explore attitudes, behaviors, expectations, and trends, we are able to recognize patterns in people’s thoughts, feelings, and actions. From those patterns, we are able to identify their potential value to the company, their spending trends over time, and their potential to connect with a brand messages for many years. Our experience has been that, by adding these dimensions or attributes to the personas and scenarios, they can be used to inform change within various parts of a business including product planning, budget allocation, marketing strategy, customer support and more. Some examples of these attributes could include a brand campaign with media messaging strategy or a planned change in the company’s enterprise-wide development platform.

Brands must stay flexible in their ability to shape their meaning and offering to appeal to the right customers at the right time. This requires brands to have a conceptual breadth and dynamic nature such that they can configure themselves according to a customer’s needs as that customer interacts with diverse channels or touch-points. Industries such as retail, financial services, automotive, consumer packaged goods, and travel and leisure are continuously testing new brand messages and launching new brands to better fit with changing customers, market shifts, and social and cultural trends.

An evolution of personas and scenarios
The use of personas and scenarios is shifting to reflect the diversity of customers’ lives within the greater context of today’s business landscape. This human-centered process of planning and informing decision-making is being embraced by companies large and small. Every week we read articles about the way personas are used within an organization and their impact, from retail chains redesigning stores to reflect customer behaviors, to hotel chains designing services for different types of travelers, to financial service offerings that are simultaneously tailored to your lifestyle and specific life stage. On the surface, these are customer stories that illustrate mindsets, emotions, needs, tasks, and channel usage. They are communicated through narrative stories, task flows, charts of data, imagery, functional lists, and often personal quotes and resonant anecdotes. Below the surface, they are the stories of a company-how that company wants to be perceived, the experiences they want to enable, who they want to serve, and what constitutes their success. Brands, product and service offerings, customer service and cross-channel experiences demand to be crafted through a lens of whimsy, insight, pressures, perception, and unwavering consumer expectations.

Personas and scenarios can effectively tell stories of change over time. They can tell stories of what brand experiences customers have today, what we would like their experiences to be tomorrow, and “hey, what if?” These scenarios are not guarantees, but well-informed predictions of the future business-customer interaction and relationships.

Beginning a few years ago and continuing into the future, the use of personas and scenarios within our Experience Planning group and global marketing solutions company will continue to broaden in dimension, usefulness, and most importantly, business impact. The storytelling techniques that we use to communicate and predict the thoughts, emotions, and behaviors of customers as they experience and interact with a company are useful in a breadth of business contexts. The following is a list of shifts or evolutions that we have experienced in our application of personas and scenarios to the business landscape. They continue to grow in complexity, vision, and usefulness in various business contexts.

Past use Current and future use
Product-focused > Business-focused
User task-oriented > Customer lifecycle-oriented
Software development tool > Strategy development tool
Tactical > Strategic
Use case tool > Business case tool
Single-channel > Multi-channel
Individual > Interconnected and community-based
New product concept > New categories of products
Anecdotal success > Success through measured business impact
Associated with a product > Associated with multiple divisions of a company
Customer-focused > Customer service-focused
Application-focused > Message, channel, frequency and media-focused
Static, one-time artifact > Living, dynamically shifting stories

The storytelling of business change

Product-focused > Business-focused
In the past, personas and scenarios have been used by single product, application or platform groups. Today, beyond product development groups, they have found their way into marketing, customer service, human resources, information technology, and sales. Many of our clients use them to introduce new employees to “their customers.” From poster-sized wall hangings to coffee mugs, these stories solidify an organization’s focus on the right customers. Part of the persona development process includes the design and development of an implementation and usage plan as well as a measurement and validation schema. We often refer to them as “living stories” that change and evolve in response to the dynamics of the business, the marketplace patterns of behavior.

User task-oriented > Customer lifecycle-oriented
Personas and scenarios are often used to illustrate or test a set of tasks that a user will attempt to accomplish using a system or product. They illustrate a user’s key interactions over time, showing how the relationship between a customer and a brand evolve over time via different and evolving interactive experiences and an ongoing brand dialogue. They illustrate the stories of a single individual (or family) and the life stages and evolution that they will experience.

Software development tool > Strategy development tool
Personas and scenarios are commonly used as a software development tool to describe the user-system interactive application design. They serve this purpose sufficiently, but also encompass a framework to tell strategic product, audience, market, and business strategy stories, telling the stories of individuals and how their lives will change over a few years. In parallel, they tell the stories of how the company, its products, services and philosophy might also evolve over those same few years. For instance, our strategic personas often paint a picture of how a brand will shift in public perception and/or marketing position over time.

Tactical > Strategic
Personas can exist at feature levels, product levels, division levels, company levels, market levels, and cultural levels. They can tell stories of new business models, new paradigms of service and of cultural shifts. They can be used to depict a “day-in-the-life” of this year, next year, and five years from now. They can tell multiple stories that span a customer’s lifetime relationship with a company. They bring to life product opportunities that are realized in the cracks of market shifts and emerging cultural changes.

Use case tool > Business case tool
Traditional use cases, most used within software development, are detailed stories of user-system interactions and responses. We can apply these same principles to defining and communicating business cases. Scenarios tell stories of what happens when a specific button is pushed or when a valuable customer calls Customer Service. They tell stories of how an interface is used to find a local store and they tell stories about what happens when that customer walks into a retail store.

Single channel > Multi-channel
Most often, personas are applied to software or website interactions. Fewer, but still many, tell stories of interactions with kiosks, portals, mobile apps, IVRs and customer support personnel. We often tell stories that incorporate brand experiences with many channels, each with the intent to move the customer closer to a transaction. The principles and techniques that are used to tell the stories of multiple interactive channels can be equally effective when applied to retail environment design and direct marketing strategies.

Individual > Interconnected and community-based
Personas are still most often about a single individual. From customer observation, we recognize that purchase decisions often involve more than one individual, including a spouse, a friend, a family member, or a “significant influencer,” as we like to say (like a grandmother, clergy, or a coach). These relationships are critical to how customers perceive, react, and experience a brand. Beyond co-decision-makers and influencers are the issues of a customer community. The use and the role of consumer-generated content and brand evangelists (extreme advocates) must be clearly defined and meticulously planned. Online forums, blogs, owner’s clubs, and streaming interviews are just a few of the data sources that emerge on the web and via traditional publishing every few seconds. You should become aware of these sources, understand their impact and anticipate how customers will use them to inform their behaviors. Make those interactions part of your personas and scenarios.

New product concept > New categories of products
As a new product concept is brought to life, the development team often realizes that potential variations or expansions to the idea exist that can be applied to other products or industries. For example, as we designed a service look-up tool for the web, we realized that this was a platform and interactive tool that could be applied to many related place-based services. Scenarios tell stories of variations on or a deviation of an existing business model, or something entirely new. They tell stories of uncertainties that are grounded in the behavior and emotions of individuals, shifts in markets, and changing cultural values. Most business landscapes are mature, so you should push on them a bit with stories of unique, but obvious, variations that stem from user understanding. We often find it useful to include characteristics or behaviors in a persona that are disruptive or anomalies to the norm.

Anecdotal success > Success through measured business impact
Throughout the years, we have not seen much focus on the definition of how a feature or product is going to be proven successful. In most cases, we have prioritized a segment, and we know its value. All businesses have success measures which might include customer acquisition, revenue generation, share of wallet, brand perception, transaction through a channel, reduced operating costs, customer satisfaction, or something else. Sure, the personal stories of individuals resonate, but the stories of actual, predicted and measurable ROI are what let business executives sleep soundly at night. You should clearly define the measurable business attributes and goals that exist within the story of each persona. Design a continuous measurement, iteration, and validation strategy that is both tactical and strategic.

Associated with a product > Associated with multiple divisions of a company
Often, our persona actors are introduced to a company and they become part of the internal fabric of product and service planning. Customers don’t care if they’re interacting with a specific division of a company; what they do care about is the ease of interaction and quality of service and overall experience. Tell fact-based stories of how customers should effortlessly cross department and divisional boundaries. You’ll know you’ve done this well when someone recognizes and identifies by name a persona actor that you created for another division within the company two years ago.

Customer-focused > Customer service-focused
Personas are usually about a current or potential customer. We have found them to be a useful tool to model the dialogue and interactions of a customer and various Customer Service Representatives (CSRs). “A caller has requested to speak to an operator through the IVR via this path. This is their issue and, in most cases, the answer can found in one of these sections of the site.” What tools does the CSR use to resolve the customer’s issue? How should a CSR gently encourage and lead a caller to solely use the web next time? We typically spend one to two days at a Customer Service Center extracting a wealth of customer knowledge that exists, as well as directly listening to the dialogue of customer calls. Customer Service Centers are often the arms that embrace many current and future customers and carry them through the purchase, service, or ownership experience. The one-to-one customer relationships that are formed by a concierge or personal assistant are often the most impactful point of influencing customer perception and behavior. These individuals and their numerous daily interactions are the hub of customer empathy and understanding within a company. They deserve the same consideration and level of planning and strategy as any other marketing or sales channel.

Application-focused > Message, channel, frequency and media-focused
Arc Worldwide is part of a larger holding company and network of advertising agencies, channel marketers, and media planners. Agency Planners have traditionally provided the data and strategy that informs message development. Agency Creatives have crafted the messages and visual work used to present those messages to the public. Media Planners and Buyers create the strategies of when and where those messages should be delivered. Our personas and scenarios often complement, guide, and bring to life the work that these different groups do. The allocation of marketing and advertising budgets is quickly shifting from a past of majority allocation to mass media, to a future of majority allocation to one-to-one, multi-channel interactions. Personas can be used to show the predictive effects of more intelligent messaging, media, and channel experiences.

Static, one-time artifact > Living, dynamically shifting stories
Traditionally, personas have been created for one-time use, to inform the application design of a single product. They are created once and then used a few reports and presentations. On occasion, an internal set of personas is updated as financial quarters or even years pass, but this is the exception. We encounter many companies that have already “gone down the persona development path,” sometimes more than once, and didn’t realize any value from that activity. Our experience has been that personas are most useful and valuable when an organization declares that satisfying their needs and tasks is an operational imperative.

Imagine a future framework in which customer personas and scenarios are dynamically generated from live data. These stories can be accessed via an online portal by various internal and external marketing, sales, and product development teams. This online tool is a sophisticated information repository with an underlying construct of three layers-a data layer, a rules layer, and a presentation layer. Many companies have access to rich volumes of data from sales, marketing, and customer data sources. The data layer comprises feeds from various sources including survey data, transaction data, loyalty data, value measurements and more. The rules layer organizes the data itself and the data in relation to other data sources. The data comes to life in the presentation layer as it is converted into visual stories in the form of frameworks, diagrams, matrices, multi-dimensional personas, and experience models. These are rich and relevant stories about your target audience and the issues of their lives that may affect your business. Because of the dynamic nature of the data, these personas are living stories that change daily.

We aggregate this real-time data within this portal and bring it to life as visualizations of customers, channel usage, advertising and marketing effectiveness, and sales. From these snapshots come real-time planning insights and opportunities. The purpose of this portal is to provide an at-a-glance status of the profile of your audience and the various channels with which they interact with your brand. This portal uses various techniques of information visualization to demonstrate the effectiveness of these channels in accomplishing specific business and marketing goals. Aggregate views of current public opinion and press coverage add an additional dimension to the story. Also built into this tool is an application for scheduling and executing research studies with various representative customer groups. Tools and information are uniquely combined and delivered to you via a custom dashboard.

What better way to drive business strategies, including messaging, product and services offered, innovation explorations, media design, interactive dialogues, store design and much more? Our belief is that through the proper use of advanced technologies, every large brand could have a dynamic customer, market, and cultural reporting platform at the heart of its business decision-making engine.

Personas and scenarios applied
Over the past two years, the Arc Worldwide Experience Planning group has written dozens of personas and scenarios that span numerous verticals and diverse business models, goals, and strategies. Together with talented visual and information designers, we create compositions that juxtapose user, business, organization, marketplace, and product details in a way that clearly communicates connections, actionable insights, and opportunities.

Some of the industries and related business problems to which these methods have been applied include:

  • Defining long-term ebusiness strategy based on how the company-patient relationship will evolve with each disease state (in the context of budget approval for multiple large-scale projects over a three-year period).
  • Validating and bringing market data-driven segments to life (to demonstrate future reliance on and interaction with the financial service company’s emerging global intranet).
  • Architect multi-channel user experiences and define effective customer purchase processes for a range of high revenue-generating products (to optimize category specific, multi-channel shopping processes).
  • Planning and launching a new home entertainment product category, product, service, and brand; (telling stories of the customer relationship continuum from initial consideration, through service purchase, the out-of-box experience, installation, usage and customer service).
  • Understanding how regional travelers plan trips and what channels and mediums they use to plan. (also clearly defined were the goals, considerations, and the types of information that are critical to their success and peace of mind).
  • Increase brand awareness and penetration of a consumer package good in specific European markets (provide a framework to generate new ideas to increase product loyalty).
  • Understand the interconnections and relationships between a union and its members.
  • Tell stories of regional and local difference and opportunities around military recruiting (tied to emotions, values, behaviors, and the effectiveness of various messaging and media).

Whatever the industry, we craft user personas and scenarios to communicate clear, digestible plans and strategies that are embraced as useful and engaging throughout organizations. As mentioned, in many cases we introduce organizations to their customers for the first time. And in other cases, the introductions are broader, including a strategy for shifting market position or measuring business success.

Conclusion and recommendations
Amazon, Home Depot, Delta Airlines, Sears, Discover, Morgan Stanley, Microsoft, Toyota and many others have integrated customer personas and scenarios into their strategic planning process. They provide flexibility, adaptability and a real-world usefulness that many business strategy and forecasting techniques do not. Whether your client’s target audience is students, sales associates, doctors, online shoppers, future soldiers, insurance agents, financial advisors, or business partners, we recommend that you use personas and scenarios to capture their essence, apply it to business issues, and tell stories of future business success.

Arc Worldwide Experience Planners ensure that Arc’s products and services are informed and inspired by the attitudes and behaviors of customers while appropriate and innovative in supporting business objectives. With a holistic and relentless focus on creating engaging customer experiences that meet business needs, Experience Planners are highly skilled in activities frequently associated with behavioral market research, business process analysis, usability engineering, information architecture, and interaction design. Employing an iterative, user-centered development approach, Experience Planners create the blueprint for products and services that are at least relevant and efficient, at most delightful, loyalty-inciting, and life-altering. They invent and improve experiences across interactive media and real-world spaces: from in-store kiosks to websites; from personalization infrastructures to interactive games and mobile UIs. Experience Planning is part of Arc’s larger global Insights & Analytics group.

Parrish Hanna is VP, Director of Experience Planning at Arc Worldwide. Previously, Parrish served as President of HannaHodge, a groundbreaking user experience firm that he co-founded in 1998. For over a decade, he has spent the better part of each week planning better experiences for humans and refining the process to do so. He considers himself fortunate to have worked with brilliant people toward making the products of enlightened companies like Cadillac, Ford, Vanguard, Disney, Samsung, IBM, Sears, Intel, and Xerox easy and pleasurable to use. Parrish has a B.A. in Industrial Design, an M.A. in Human-Computer Interaction, and a handful of patents and industry awards. He’s a regular publisher and speaker on issues related to experience design.

Making Personas More Powerful: Details to Drive Strategic and Tactical Design

by:   |  Posted on

“Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs.”

How can something that feels so right be so wrong? Personas ought to be one of the defining techniques in user-focused design. Lots of professionals create them, yet too often the personas end up being too vague to guide a product’s focus. They often lack the detail to be useful in guiding low-level design trade-offs. And, as typically done, personas have been too narrowly focused. They often aren’t helpful in identifying the information a user needs or creates. Nor do they have much to say about the sensory and emotional aspects of user experience–the sorts of factors that cause consumers to lust after products like Apple’s iPod.

As a result, personas have unfortunately become more of a check-off item than a useful tool, and many personas get put on the shelf once they are written. So how did we get here?

Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs. Cooper’s company most often dealt with enterprise clients who hadn’t yet bought into the value of user experience. As a consultant, he had a strong need to persuade internal development teams to pay attention to users, so, not surprisingly, he emphasized both the narrative and empathy-building aspects of personas.

Cooper’s goals for personas were to:

  • Allow the development team to live and breathe the user’s world.
  • Allow the team to filter out personal quirks and focus on motivations and behaviors typical of a broad range of users, while still relating to users as individuals.

These are good goals, but incomplete. Compounding the problem was that Cooper’s seminal The Inmates Are Running the Asylum talked at length about why personas were important, but didn’t provide many details about how create them. So people improvised, often with unsatisfying results.

My own frustrations with personas came as I tried to apply them to a different context. While Cooper mostly worked with enterprise clients, with developers and managers who were reluctant to consider users, I’ve usually had a hand in building the sites I design, even as an outside developer and consultant. Likewise, Cooper’s clients typically were developing internal applications where efficiency was main goal, so it’s not surprising that his approach was task-focused. But as I’ve argued previously, other types of projects are predominantly information-oriented and immersion-oriented–or some mix among the three.

Much of my own work has been on consumer-facing websites and interactive products where functionality was only part of the focus. When I was developing movie promotion sites, the studios obviously hoped the websites would “put butts in seats.” But people don’t visit movie promotion sites to find out where the film is playing. Nor–if they live outside Hollywood–to find out the name of the second assistant camera operator. People go to movie promotion websites to get a taste of the film.

The design challenges simply weren’t the same as Cooper’s. I needed a tool not just for creating empathy and filtering out quirks, but one that could:

  • Guide strategic decisions about a product’s focus,
  • Enable better tactical-level design decisions, and
  • Help make inevitable design trade-offs.

In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear. Good editors constantly pose questions to the writer to force them to reach that clarity. My toolkit is built on the efforts of others from a wide variety of fields, from HCI to branding to filmmaking. To help develop more “three-dimensional” personas, the toolkit contains more than a dozen pages of questions about:

  • Biographic, geographic, demographic, psychographic background information
  • The business’ relationship to the persona
  • The persona’s relationship to product and business
  • The persona’s specific goals, needs and attitudes
  • The persona’s specific knowledge and proficiencies
  • The context of usage
  • Interaction, information, sensory, emotional aspects of the user experience
  • Accessibility issues
  • Relationships among personas

It also includes techniques for using personas to prioritize user interface components, as well as useful definitions for providing a common language to describe this prioritization.

“In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear.”

My focus was on a tool for design rather than a tool for persuasion, so the questions– and resulting answers–are far too detailed for those outside the design team. But they’re necessary to enable a designer to not only make better tactical level decisions, but also to think more strategically about the product’s focus and help drive the product’s definition. The toolkit covers a wide variety of situations, so you should use the questions that are most appropriate to the context of your project. Similarly, not all the questions need to be–or should be–answered at once. The toolkit is designed to be used iteratively with questions being filled in over time as they become relevant to the design issues at hand. (However, it’s still a good idea at the start of the project, or at least at the start of each project phase, to identify the questions you think you’ll want to answer, so that you can begin gathering the necessary information.)

Let’s quickly review some of the basics of persona creation. When building personas, the first challenge is finding the information to build them. Obviously, it’s preferable to talk to and observe the users themselves, but that’s not always possible. In my opinion, any information is generally better than no information, and there are inevitably other sources of information. You can talk to user surrogates, such as domain experts, trainers, or immediate supervisors. There are “informants” who know about the users, such as people in the marketing, sales or customer support departments. For example, I once designed an extranet for a company’s board of directors. I couldn’t get access to the board, but their support staff was able to tell me all I needed about the directors’ behavior and computer skills. There are other indirect sources as well, such as manuals (especially those with notes written in them), site logs, customer feedback forms, surveys, etc. But one indirect source to be wary of is “ersatz” users–most commonly upper-level executives who think they understand their customers far more than they typically do.

After gathering information, I prioritize personas into the following types:

  • Focal–These are the primary users who are the product’s target.
  • Secondary–They also use the product and we’ll satisfy them when we can. But their needs can be sacrificed to meet the needs of focal users.
  • Unimportant–Infrequent, unauthorized, or otherwise low-priority users.
  • Affected–They don’t use the product but are affected by it. For example, one member of the family may do the research when buying a car, but the others–who are usually involved in the decision–will be affected by that person’s work.
  • Exclusionary–We’re not designing for them. Period.
  • Stakeholders–I’ve often found it useful to create mini-personas that represent their interests and involvement. These can range from advertisers to senior management to industry influencers to regulatory agencies. Stakeholders may–or may not–be something you want to put into writing. But stakeholder personas are often useful to formally create because they provide a good way of ensuring stakeholder issues get discussed openly. If you’re including a feature solely because it will get press coverage, it’s better to acknowledge this in the design process than to pretend that it’s there to satisfy a user need.

You probably want no more than a dozen personas, with at least one focal persona. But if there are more than three focal personas, you’re trying to do too much, and you need to subdivide the product or interface–for example, separating the “user’s” user interface from the “administrator’s” user interface. This is probably familiar ground. But I mention it because it’s critical to get team consensus on the relative priority of each persona in order to later prioritize specific design decisions.

What is your persona’s background?
At the broadest level, persona development starts with the biographic background, including:

  • Geographic profile. Where do your personas live and work? What’s it like there? Why can this matter? It’s worth noting that some of the earliest non-U.S. internet adopters were the Scandinavian countries, Australia, and New Zealand. While geography may not be destiny, I suspect the rapid adoption was in part due to the long dark winters of the former and the geographical isolation of the latter.
  • Demographic profile, such as age, gender, family size, income, occupation, education, etc., information that’s available from the marketing team. It’s frequently less useful for understanding the behavioral aspects of your persona, but can useful in rounding out a persona’s character. Politically, it’s a good way to get Marketing to buy in.
  • Psychographics, which include social class, lifestyle traits and motivations, personality characteristics and attitudes. These can be important in understanding the proper tone and voice to give a product. For example, the PRIZM system developed by Claritas–based on the idea that people with similar tastes tend to live in the same neighborhoods–is eerily accurate in describing people’s likely interests based on their ZIP code (You can try it yourself here.) I’ve also found it to be a useful tool for adding in non-essential details that make personas feel more realistic.

What’s the relationship between persona, product and business?
Some of the key strategic questions are around the persona’s relationship with–and value to–the business.

  • Is the persona a customer, an employee, a partner? A company will likely want to communicate different messages for its external sites than its intranet. An extranet may display different content for a preferred vendor than for other vendors. Similarly, a website might restrict certain information to only paying customers, while leaving other content available to all users.
  • Conversely, what sort of relationship does your persona have with your product or business? Are they a heavy user or a non-user? If you’re trying to acquire customers from a competing product, then you need to understand the people who aren’t using your product. What’s your persona’s attitude toward your product, your brand and your company? What kind of relationship would your persona like to have–but doesn’t have now? Enterprise applications are often like arranged marriages–employees use them not out of love, but because they’ve been told to do so. Linux users have an undying “hate affair” with all things Microsoft, and Tivo users will tell you that it changed their lives. Where’s the relationship headed? If you’re MTV, you’d best recognize that your brand relationship is a passing fling; in a few years, today’s viewers will be wearing Dockers and watching VH-1. In contrast, you’d have to pry their Macs out of the cold, dead hands of many users with a lifelong commitment to Apple.
  • What’s the persona’s value to the business? More zealous advocates of user-centered design seem to think any user is valuable, but that simply isn’t true. The 80/20 rule was discovered by an economist’s extensive analysis of businesses that discovered 20 percent of customers did account to 80 percent of revenues. It can be useful to think about what percentage of overall users (or overall revenue) a persona represents. It may not the critical factor in a persona’s priority, but if nothing else prepares you to answer questions from the business side of the project.

Wave rolling ladder
What’s the context around the product’s usage?
Focusing on the product being offered, what are the specific goals, needs and attitudes surrounding the context in which your personas will use the product? Crown Equipment Corporation realized that even warehouse workers want to be “cool,” which was the inspiration for the stylish exterior of its Wave rolling ladder replacement. The product has been a hit. Not only did it create significant jumps in efficiency because it allows one person to do the job of two, but companies using it saw big increases in job satisfaction and morale.

After thinking about what your personas are trying to accomplish, then look at what specific knowledge and proficiencies your personas have related to achieving that goal. A safe rule of thumb is that most users never pass the “advanced beginner” stage of expertise–nor do they really want to. This question also applies to more fundamental issues than computer skills. For example, there’s a company that provided computer-based HR training (sexual harassment policies, etc.) to hotel maids. Not all the maids spoke English, nor were all of them literate in their native languages. Needless to say, their language skills had a significant affect on the design.

It’s useful to get specific about the context in which the persona is using your product. For example:

  • When and where do users perform a task? With whom?
  • What’s the surrounding environment? Global navigation positioning systems for sailing are used at any hour of the day or night, in any weather condition.
  • Are there device constraints? For example, designing for a mobile phone.
  • Are there confidentiality needs? Accuracy needs? Audit needs?
  • What are the operational and/or safety risks? Designing a hospital billing system has big risks–but far smaller than designing the hospital’s pill-dispensing system.
  • Is there assistance and training available? Many of us work on websites where training is impractical, but in designing an air traffic control system it may be preferable to prioritize other concerns over learnability, since the users will be formally trained in its use.
  • Are there legal and/or regulatory restrictions? If you’ve ever worked in financial services or other regulatory industries, you know how much these issues can affect the design.

What does the interaction look like?
Now that we’ve looked at the context around your persona’s usage of the product, let’s take a close look at the interaction with the product itself. How frequently does the interaction take place? Is it on a regular basis? Is it continuous or interrupted? Is it so intense that it requires the persona’s full attention, or is one of several interactions that your persona is doing at once? How quickly must the persona act? How complex and how predictable is the action? Who’s driving the interaction–your personas or outside factors? If you’re designing an air traffic control system, the interactions are highly complex, but generally predictable. The controllers are the ones driving the interaction with the pilots, but it involves continuous high-intensity focus with split-second reactions for hours on end. That’s a little different than the interaction with your average website. Admittedly, these questions overlap with task analysis, but answering them for each persona can help identify important similarities and/or differences in behavior among your personas.

What information is involved?
Many interactions also involve information–something that traditional task analysis can overlook in its focus on actions. So the next step is to look specifically at the characteristics of the information that your persona needs and/or manipulates as part of the interaction with the product. For example, at one extreme are call centers, where the operators are listening and talking with customers, while simultaneously reading and typing on their computer screens. If you were designing the call center’s software, you’d want to think about the volume and complexity of the information being used, how it flows to and from the operators, and what level of detail is needed at what times.

What makes the user experience memorable?
While interaction and informational aspects of user experience can be analyzed logically, the sensory and immersive characteristics of a user experience are inherently more subjective–but no less important. Products can survive in the marketplace initially despite being crude, ugly or dangerous if they provide enough value. But over time, as competitors match quality, style becomes the differentiator. (Or price–but only one product can ever be the lowest-priced.) What’s the mood or feeling, style or genre that’s appealing to your persona? What’s appealing? What’s pleasurable? What’s memorable?

Geek Squad ad
Geek Squad–a boutique high-end computer-support company–is the master of the memorable experience. Does its black-and-white “Geekmobiles” and Men In Black-meets-computer nerd schtick affect the actual technical troubleshooting skills of its services? Nope. Does it make an impression? You bet. So much so that the company amassed a celebrity client list and was subsequently acquired by Best Buy, who is now launching the service in all its stores.

The Geek Squad experience was no accident. It was consciously created to overcome people’s adverse reactions to arrogant tech support workers. Not surprisingly, brand researchers have paid much attention to the emotional aspects of an experience. One researcher argues that aspects of five major personality characteristics:

  • Sincerity
  • Excitement
  • Competence
  • Sophistication
  • Ruggedness

account for roughly 90 percent of brand differentiation. Regardless of whether the list is as specifically effective as claimed, it is worth thinking about what personality your product conveys and whether it’s something that’s attractive to your personas.

Likewise, what is your personas’ perceived experience of using your product? Does the product convey:

  • Sense of adventure?
  • Feeling of independence?
  • Sense of security?
  • Sensuality?
  • Confidence?
  • Power?

Strengths in many of these areas are what prompt Harley-Davidson’s customers to literally brand themselves with tattoos and jackets–and what kept the company afloat during the 1970s when the motorcycles themselves suffered severe quality problems.

With this level of detail in your personas, it becomes far easier to prioritize them. The toolkit provides three approaches for doing so.

This approach seems to pose numerous questions–and it does. As I mentioned previously, you only need to answer the ones that are most relevant, and not all at once. But it’s the details that will make your personas powerful.

George Olsen is senior interaction designer for Yahoo! Search. He has done award-winning work for a variety of companies, from dotcom start-ups to Hollywood studios to Fortune 500 companies.

Extending a Technique: Group Personas

by:   |  Posted on

Spock: “The needs of the many outweigh the needs of the few.”

Kirk: “Or the one.”

–Star Trek II: Wrath of Khan

I recently had the pleasure of teaching a workshop on applying user-centered design methods to personal technology design in a European amusement park.

The workshop started out typically. We interviewed company management, mapped out the goals of the company, the context in which the project was being done and collected information about how people currently behaved in the park. We then identified several classes of users, created personas for them, and started creating scenarios using these personas.

Initially, the workshop progressed about as it would if we were going to be designing a piece of desktop software or a website, but the minute we started developing personas and scenarios, the unique nature of the park started to become clear. We first sketched out some personas, and that went fine. But once we began working with scenarios for a while, trying to create believable situations for these characters to behave in, we noticed something: all of our scenarios consisted of groups of personas interacting with the environment or with other groups of personas. That’s when we realized that individuals mostly don’t act alone in amusement parks. People rarely go alone and they don’t make decisions alone. Needs and desires are negotiated in a group, not expressed individually. People really fully embrace the experience only when they’re experiencing it with others. In this environment, individual personas and scenarios for them matter less than what happens to groups of people.

So we decided to see if we could make group personas. At first, there was some apprehension–what if the groups are so varied as to be impossible to characterize? But as soon as we started making them, only several different kinds of personas made sense and it became a straightforward extension of Alan Cooper’s original persona technique. Here’s how we did it.

Individual descriptions
We had started by describing individual personas, so we had the building blocks of groups, and we used those personas as the basis of our subsequent work. Those personas were based on several visitor categories that we defined based on the park’s operators’ knowledge of their audience–the statistics they had and their personal experience with the park:

  • Teenagers
  • Young adults
  • Pre-teens
  • Young parents
  • Grandparents

We decided to leave the profiles broad, rather than going into detailed persona building, and described each group along some criteria appropriate to the problems the park was trying to solve. Young parents, for example were described thus:

  • Age: 25-35
  • Children: 2
  • Budget: $75-100 per day (in the park, not including tickets) per parent
  • Technology: cell phone (6-24 months old), digital camera, video camera, computer at home, internet connectivity in the office
  • Desires: have fun with kids, let kids run around in safe place
  • Needs: to have fun, too; place to change diapers; place to sit down; to buy food/drink

Of course, this only scratches the surface of how young parents in an amusement park can be described–we could have defined different criteria based on gender, culture (this park has sizable populations of visitors from as far as Poland), etc.–but time was limited and it was enough to get us started creating group personas.

Rough outlines
Before fleshing out the group personas, we decided to make some rough outlines of the clusters of people one might find in the park. Based on what we had heard from the park staff and additional interviews we conducted with a couple of friends-of-friends who had visited the park as tourists, we came up with four different groups to focus on, and tried to give them distinctive names:

  • The Teen Posse
  • Young Parents, Young Kids
  • The Extended Family
  • College-age Friends

We also defined some axes along which we could define the group. Again, we chose to pick out those qualities that we felt would be valuable in answering the park’s questions, rather than trying to describe every detail. Thus, the “Young Parents, Young Kids” general description looked like this:

  • Number of people in group: 5
  • People in group: 2 adults, 2 kids ages 3-10, grandparent
  • Time spent in park per day: 6 hours
  • Number of days visiting park: 2
  • Season: August

The level of detail at this stage needed to emphasize the group as a whole and make it different from the other groups, without burdening it (and ourselves) with descriptions that didn’t affect the end experience. We didn’t describe the individual members of the group, and included as few constraining specifics as possible. Such details and idiosyncrasies would come in the persona, which we did next.

Iterative persona creation
We developed each persona in several passes, both to refine the persona until it had sufficient believability and because this was the first time any of us had developed group personas, so we naturally ended up over-describing certain aspects and under-describing others. The process was roughly as follows:

  • a rough sketch, where we quickly outlined the persona, determining its composition and adding some defining details
  • a detail brainstorm, where we added as many details as we could, even if they were silly, contradictory or redundant
  • editing, where we cut out everything we thought was irrelevant to addressing the project focus, and clarified overlapping ideas
  • preliminary scenario writing, during which we “exercised” the personas by walking them through some examples in which they interacted with the park and some of the design ideas on the table
  • tuning, where we adjusted the personas based on what we had learned from the scenarios

After a couple of days of doing this for 2-3 hours per group persona, we had four fleshed-out group personas and some scenarios that we felt were typical examples of groups who visited the park and how they would behave. These we used to examine the problems the park was experiencing and our proposed solutions.

Example: The Ancona Family, a secondary persona
Note: this persona is significantly modified from what we developed in the workshop.

Back story
Luisa and Giorgio, a couple in their mid-30s, have decided that the family needs a vacation. It’s mid-August and they’re spending time with Luisa’s parents, Maria and Carlo, at their home outside of Rome. Mauricio and Laura, their children, are getting bored and cranky and clearly need a break from hanging out at the grandparents’ house. Giorgio suggests they spend a weekend at an amusement park with water rides before they go to Rimini for the traditional week on the beach. Maria, Luisa’s mother, will come along. She’s always willing to help out with the kids.

Luisa and Giorgio are in their mid-30s. They live in Rome. They’ve been married for five years. Giorgio is a mechanical engineer and Luisa is a full-time parent and also works part-time at her parents’ grocery store.

Mauricio and Laura are their 7- and 4-year-old children.

Maria is Luisa’s mother. She is in her late 50s. She lives outside of Rome with her husband, Carlo. They own a small grocery store, where Maria manages, in addition to being a full-time homemaker.

Technology use
The park was interested in developing wearable or portable technology for people to use as they’re being entertained, so we included a range of technologies in our description, rather than just focusing on computer and software experience, as we would have if this was a piece of software or a website.

Luisa and Giorgio have mobile phones. They’re very comfortable sending text messages, and typically send 3-5 to each other per day. Luisa sometimes uses hers to play video games and she texts one of her friends almost every day. Luisa’s phone is newer than Giorgio’s and has a camera.

They have a two-year-old computer at home, which Giorgio and Luisa use to send email (they have a dialup internet account) and which the kids use to play video games and watch DVDs.

Giorgio has a faster internet connection at his office.

They have a digital video camera with them, which Luisa bought for Giorgio for his last birthday.

Maria doesn’t have a mobile phone, but she’s comfortable using one.

Luisa and Giorgio have taught Mauricio how to call the emergency number on a mobile phone, but he’s otherwise not used one even though he understands in principle how they work.

Group goals are a negotiated combination of individual goals. In a family trip, most of the long-term goals are set by the parents, and most of the short-term goals are set by the kids.

Mauricio has one major goal: to ride the big roller coaster over and over again. He’s never been on one, but he knows about it. He’s also very interested in the dinosaur area.

Laura has never been to an amusement park before, so she doesn’t know what to expect, but her parents told her about the costumed mascots and water rides and she’s excited to see those.


  • Have fun with his kids
  • Wants to use his new video camera
  • Wants to ride the roller coaster


  • Wants to spend time with Giorgio and her kids
  • Wants to ride the ferris wheel


  • Talk to her daughter
  • Spend time with her grandchildren

Combining these, we get a set of general goals:

  • Ride the big roller coaster
  • Avoid boredom
  • Spend time together

In our example, goals are individual but they affect the whole group, whereas needs are mostly group-wide. This may be a product of our process, or it may point to a general case of how group personas work.

  • Find each other
  • Find the bathroom
  • Be entertained while waiting in line
  • Get food/water
  • Rest for Maria, while kids are being entertained

Purchasing profile
Since selling stuff is a key amusement park revenue stream, we decided to do a short profile of what the group is likely to purchase throughout the day.

  • Ice cream, bought by Maria, as a treat for the kids
  • Soda in a theme cup, requested by Laura, bought by Giorgio
  • Lunch for everyone, bought by Luisa and Giorgio
  • Disposable camera bought by Luisa
  • Sunscreen, bought by Luisa
  • T-shirts for Mauricio and Laura, bought by Giorgio

Example: Ancona family scenarios
Having developed a general group persona, the next step was to develop some scenarios using the persona in order to test it and further refine it.

Day narrative
We began with a general narrative of what happens during the day. Here’s an abbreviated version of the first day:

6:00 AM: kids wake up
8:00 AM: breakfast at Maria and Carlo’s home
9:00 AM: family leaves for park
10:30 AM: arrive at hotel near park, check in
11:30 AM: leave for park
12:00 PM: arrive at park, buy tickets, go in, start getting oriented
12:30 PM: orientation chaos: where to go? what to do? Negotiation and prioritization.
12:45 PM: Giorgio and Mauricio head for roller coaster. Luisa, Laura and Maria start looking for a place where Maria can wait with Laura while Luisa joins her husband and son.
1:00 PM: Giorgio and Mauricio arrive, get in line.
1:15 PM: Luisa and Maria find picnic area where Maria can wait.
1:30 PM: Luisa joins Giorgio and Mauricio.
2:30 PM: Luisa, Giorgio and Mauricio get to the front of the line and ride the roller coaster. Everyone is very hungry.
2:45 PM: Group reunited, start looking for lunch.
3:00 PM: Lunch bought at stand near picnic area.

Where are Giorgio and Laura?
Using this structure, we started thinking about technological solutions: what problems are encountered? How can the information technology we know the family has or has experience with affect the situation? How can the park benefit?

Business problem:
People complain of getting lost when trying to reunite when groups separate.

Laura really wanted to go on the water flume ride, but since everyone gets soaked while on it, the rest of the family doesn’t really want to go. Giorgio and Luisa agree that he’ll go, while she and Mauricio and Maria go to the ferris wheel. Since everyone gets soaked, Giorgio doesn’t want to take his mobile phone and leaves it with Luisa. Now, how will they meet up again? They don’t know how long the lines at the various rides are. How will they know when to meet? If the water ride line is as long as the roller coaster and the ferris wheel has no line, then Luisa, Maria and Mauricio may end up waiting hours for Giorgio and Laura to get back.

Potential solutions:

  • Wait-time kiosks. If there are kiosks scattered around the park that tell people how long the lines at the rides are, then the family can estimate how long the whole process will take and pick a time and place to meet up again.
  • RFID bracelets/ride check-in. Everyone gets a wrist bracelet when they buy their ticket. Assume that each bracelet has an RFID (radio frequency ID) tag in it and people’s IDs are linked
  • Waterproof mobile phone bags. Watertight bags provided by the park for people waiting in line for water rides. These allow people to coordinate and communicate using the tools they’re familiar with.

Using the group persona, we were able to explore and evaluate how well these solutions worked, both for the Anconas and for the park. The low-tech solution, the bags, is cheap and requires the minimum investment by the park in new technology and by the Anconas in learning a new system, but it’s not without problems. What if Giorgio, who’s quite attached to his phone, doesn’t trust the bag?

What we learned
This exercise was incredibly helpful when we started designing technology to support people’s experience in the park.

Groups are not individuals, though they sometimes act like them.
As the persona is developed and as scenarios are written, the focus shifts from the individuals in a group to the group as a whole. The group is rarely treated as an entity identical to an individual, but it often behaves as one. So when the Anconas move around the park, they’re often moving as a group. Where they go may be heavily influenced by one person’s desires (Mauricio’s desire to ride the big coaster), but the decision is made collectively and they act as a group.

Group descriptions should have moderate detail, but not too much.
While it’s not necessary to describe either the group or its members in deep detail, some description is important. In fact, describing groups as groups is actually tough: we just don’t have that many axes along which we typically describe small groups: we can number the members and collect aggregate demographic information, but that’s about it. We had to invent a lot of the categories we used on the fly.

The design goal drives the persona description.
Remembering that this was an amusement park and that we were going to be designing ways in which the park could support and encourage the use of personal technology really helped focus the persona development process. It narrowed the directions we explored and how we spent our time fleshing out ideas. There were times when we’d go too far into describing the persona and clearly enjoying the storytelling aspect too much, which was fine and often useful, but then the design goal allowed us to edit what we had produced so that it was most relevant.

Imperfection is important.
We found we had a tendency to tell stories where everything goes right and technology saves the day and makes everyone happy. Though this made us feel good, it’s not realistic, and the exercise of examining where our ideas could fail, where they could be misunderstood and misused, was quite helpful.

This is a really useful tool for realistic idea generation.
When given a broad mandate, this technique allowed us to narrow the space of all possible uses of technology from what was merely possible to what seemed like it would be actually useful and valuable. It defined the space in which we could create innovative ideas and to understand where services that bridged technologies made sense and where they didn’t. It also allowed us to see the problems with some of the ideas.

Extending traditional techniques to groups is possible and valuable.
This was the first time I tried this technique. Frankly, I kind of invented it on the spot and my workshop participants ran with it, but the process of taking a known technique and stretching it to a new set of problems proved quite valuable, both in terms of helping us solve the problems we were tasked with and in terms of understanding what I know about individual personas.

Extending to other kinds of experience design.
So what does all of this amusement park stuff have to do with software and websites? It’s directly applicable to software that’s used by groups. Entertainment, education, and collaboration software is often used by two or more people simultaneously (and not in the sequential “I edit this, then I give it to you to edit” model, but simultaneously). It’s difficult to imagine teleconferencing software without thinking about two groups—one at either end of the connection—using it; sometimes these are groups of executives, sometimes they’re technical collaborators, sometimes they’re mixed. Each of these different groups has a different set of needs and expectations from the software, and each can be modeled as a group persona, rather than as individual users.

In the most general sense, as our tools become more social, as information processing and ubiquitous computing pervade our environment, so should our techniques to model their users. Group personas are a small and easy step.


Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore the Sanity. Indianapolis, IN: Macmillan, 1999.

Cooper, Alan, et al, Newsletters on Personas.

Kuniavsky, Mike. Observing the User Experience: a Practitioner’s Guide to User Research. San Francisco, CA: Morgan Kaufmann, 2004.

Olsen, George, Persona Toolkit (.pdf), February, 2004.

Disney Trip Report Archive, 27 July, 2004.

Mike Kuniavsky is the author of Observing the User Experience: A
Practitioner’s Guide to User Research
(Morgan Kaufmann), and has been
developing commercial websites since 1994. He is a founding partner of
Adaptive Path, one of the world’s premier user experience consulting
companies. Previous to co-founding Adaptive Path, Mike was the
interaction designer of HotBot, the award-winning search engine, and
creator of the Wired User Experience Laboratory, where he served as chief

He is currently an independent consultant, focused on ubiquitous
computing and on the ways that such technology changes everyday objects
and experiences. His blog is

Taking the “You” Out of User: My Experience Using Personas

by:   |  Posted on

The best laid plans…
In 1999, I co-founded a small San Francisco-based start-up called Pyra. Our plan was to build a web-based project management tool and we chose to focus initially on web development teams for our target audience since, as web developers ourselves, we had intimate knowledge of the user group. At the time the team consisted of three people: my co-founder, our lone employee and myself. We considered ourselves to be good all-around developers: competent in both interface and back-end development. We also assumed we were developing our product (called “Pyra” for lack of a better name at the time) for people just like us, so we could make assumptions based on our wants and extrapolate those desires for all users.

At this time, Microsoft had just released Internet Explorer 5 (IE 5) for Windows and we were anxious to use its improved standards support and DHTML in our application to make the interface as whizbang as possible. By limiting our audience to IE 5, we decided we would be able to deliver the most robust application, one that was sure to impress potential users and customers. Later, we told ourselves, we’d go back and build out versions with support for Netscape and Macintosh. So we set to work building the coolest web application we could, taking full advantage of the latest wizardry in IE 5 for Windows. Development was chugging along when Alan Cooper’s “The Inmates Are Running the Asylum” was released and I picked it up. When I got to the chapter discussing the use of personas, I was intrigued. Though I was confident in our approach, creating personas sounded like a useful exercise and a way to confirm we were on track.

Discovering Personas

“Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them!”

Cooper’s personas are simply pretend users of the system you’re building. You describe them, in a surprising amount of detail, and then design your system for them. Each cast of personas has at least one primary persona, the person who must be satisfied with the system you deliver. Since you can’t build everything for every persona (and you wouldn’t want to), the establishment of the primary persona is critical in focusing the team’s efforts effectively. Through the use of personas, the design process moves away from discussions that are often personal in nature (“I’d want it to work this way.”) or vague (“The users like to see all the options on the home page.”) . It becomes a series of questions and answers based on a concrete example from which the team works (“Mary, the primary persona, works from home via dialup four days a week, therefore downloading an Access database isn’t an option.”). In our case, the development of personas helped us recognize that the target audience we’d chosen, web development teams, wasn’t as homogenous as we first assumed. Not everyone who’s involved in web development is gaga for DHTML or CSS—some people on the team might not even know what those acronyms stand for, a simple fact we’d failed to consider up until this point.

Our team stopped working to discuss personas and Cooper’s approach and we agreed it sounded important enough to devote some time to it. As we sketched out our various personas (a project manager for a large company whose corporate standard was Netscape 3, a web designer who worked on a Mac, an independent consultant who worked from home), it became apparent we had made some bad assumptions. Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them! We’d been so blinded by our own self-interest we failed to realize we were building a useless team product. Sure, it would have been great as an example of what we hoped to build, impressive to any engineer or web developer, but a manager might not be able to access it. We were cutting ourselves off from the people who would most likely make the decision to use the tool—and no project team would signup for Pyra because an entire project team couldn’t use it.

We were a month away from releasing the beta version of Pyra at this point, but we knew what needed to happen. We had to go back and redo our application to work for Netscape and IE, for Windows and Macintosh, and in doing so, we needed to reevaluate our tool using our personas (specifically our primary persona) rather than ourselves or the mythical “user” to guide our decisions. So that’s what we did, pulling out all our beloved DHTML and remote scripting so our 37-year-old project manager persona could access the application from her home office in Seattle on a Saturday afternoon. Though the rework delayed our beta release by two months, it resulted in a tool our potential customers could use immediately.

Learning hard lessons
Through the process of developing personas, the mistakes we’d made became clear to us:

Mistake #1: We chose flashy technology over accessibility.
We allowed the geeky part of our personalities, with its lust for the newest and greatest ways of doing things, to overwhelm the decision-making process. Though there was a sense at the beginning that we needed to support other platforms, we let our desire to use the newest “toys” change the priority of doing so. This is a common mistake programmers and engineers make but one which can be avoided through the use of personas. Interestingly, when we redid Pyra based on our personas’ needs, we didn’t lose any of the previous functionality. We only changed how it was done, e.g., reverting to less elegant page reloads rather than DHTML client-side changes. The previous version had only been impressive to fellow geeks like ourselves, but we hadn’t realized that. More importantly, the essential quality of the tool was never lost, but by redoing it, it become available to many more people.

Mistake #2: We assumed users would be more impressed by a robust interface they couldn’t use than by a less elegant application that they could use.
Again, our technical hubris blinded us into thinking that potential customers would be impressed by how we built our functionality, not by what the underlying features were. We let our wants come between our product and our users.

Mistake #3: We thought we were the primary persona.
While we shared common goals with our some of our personas, and though one of the personas we developed was very similar to the members of our team, none of us were the primary persona. This crucial distinction between primary personas and secondary personas forced us to realize the interface we designed shouldn’t be driven by our wants or needs, even as members of a web development team. Defining a primary persona prevented us from releasing our original tool with its accessibility failures.

Less than a month after the beta release of Pyra, we released a second tool, Blogger. Though we didn’t create formal personas for Blogger users, the experience we gained by using personas infused our company’s approach to building web applications. Any time the word “user” was mentioned, questions flew: “What user? Who is she and what’s she trying to do?” Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application. The use of personas helped move all our discussions about the application, not only those related to the interface, away from the realm of vagaries and into tangible, actionable items. (“It should be easy to create a new blog.” “Easy? Easy for whom?” “It should take less than a minute to get started.” “It should take less than a minute for my grandmother to get started,” etc.) We developed a system of familiar, conversational personas on the fly, focusing on the primary persona without going through the formal process.

In retrospect, some of this sounds like common sense, and yet time and time again I find myself looking at an interface and making assumptions based on how I’d like it to work. Like a recovering substance abuser, it’s a constant challenge for me to refrain—I can always imagine that I’m the user. Even if your budget or timeline doesn’t allow for the development of formal personas, you can still benefit through the use of informal “conversational” personas, like we did while building Blogger. It takes discipline to break the old assumption habit but the more I use personas, the easier it becomes. I’ve carried the lessons I’ve learned through their development with me for the past three years to other projects and engagements; the use of personas resulted in a fundamental shift in the way I approach not only interface design but application architecture as a whole.

For more information:
Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, 1999.