Personas have been a popular approach for guiding the design of Web sites and mobile apps. However, some in the UX community are now saying that personas have been superseded by the availability of more accurate data or by newer UX design and development methods. In this column, I’ll give a quick overview of how my team and I formulate personas, then discuss the three reasons I most often hear for abandoning personas as a design tool.
The Early Days of Web Design
During the first wave of Web design, before most people called it UX design, there were few standards or tools to rely on for strategic guidance. One of the earliest tools for introducing strategy into the more or less free-form creative process was the company brand book. A brand book is a detailed description of how to express brand attributes in visual design and content. Typically, a Creative Director would distribute the brand book of a company for whom we were designing a Web site at the beginning of a project and expected all subsequent design work to conform to its standards.
Champion Advertisement
Continue Reading…
At the time, companies typically created brand books for traditional media like TV and print. They had little or nothing to say about Web design. They went into great detail about typefaces, color palettes, imagery, voice, and tone. But they didn’t set standards for interaction design, usability, customer engagement, or on-going customer relationships. The result was that many Web sites were beautiful in appearance, but difficult to use.
Usability testing, a practice borrowed from application software engineering solved this problem on a tactical level. Usability specialists asked users to complete some tasks using a prototype or an implementation of the final design to figure out what was wrong with it. Then the product team fixed the identified problems. Web design professionals eventually realized that a major limitation of this approach was that it didn’t actually guide design. Usability testing evaluated designs only to recommend modifications that would improve usability. While very useful, this did not serve as a strategic force to guide designers to an optimal solution from the inception of a project.
Personas as a Design Tool
One of the earliest modeling techniques that UX professionals used on a broad scale to more strategically shape Web design was the persona. Alan Cooper introduced this approach, which Kim Goodwin explains on Cooper’s Web site.
“A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.”—from “Perfecting Your Personas,” by Kim Goodwin
I have had the opportunity to lead many persona projects for large companies in the US, Europe, and South America. I enjoy persona projects because they allow me to gain a deep understanding of key customer segments prior to designing digital experiences for them. I’m able to explore questions such as the following:
What makes a brand relevant to its fans?
Why do different types of customers behave differently from one another when using Web sites or mobile apps?
What factors influence purchases or other conversion behaviors?
Which characteristics differentiate one user type from another for the purposes of designing a user experience?
Persona projects allow me to lead team activities that I consider to be fun—such as in-home interviews, video diaries, shop-alongs, and journey mapping. I even enjoy the data analysis phase of persona projects, during which we review all of our videos and code the interview text with tags that reveal themes, opportunities, and patterns that form the basis of persona differentiation. We then post photos, artifacts, and quotations on all the walls of our war room to make sense of the data that we’ve captured, using a grounded theory methodology.
However, recent developments have led colleagues of mine to question whether personas are still useful as a tool for formulating a UX strategy. They feel there are more accurate, more comprehensive methods than personas. Some consider personas to be an anachronistic approach that we should drop from our UX strategy toolbox. There are three main reasons that people give me for saying that personas are no longer a useful tool for UX strategy:
analytics
A/B and multivariate testing
agile or lean development
I’ll discuss each of these three reasons in turn.
Web Analytics
The first reason that people give me for the demise of personas is the availability of detailed Web analytics, as well as the continual enhancement of analytics toolsets. Analytics tools have come a long way since the early versions that simply produced page logs with lists of URLs and the numbers of hits that pages received. Analytics tools currently produce a much more accurate view of user behavior and can provide an aggregate view of data very quickly—with statistical accuracy because of the large number of sessions. Given the correct page coding, analytics can tell us the percentage, or dollar value, of clicks for every design component on a Web site, showing us which design components are working for customers—and which are just there because Marketing or an executive wants them there.
The makers of analytics tools are constantly updating them with new features. With the proper page coding, analysts can map user paths and determine the percentage or value of sessions that have involved those paths. More relevant to our discussion on personas, analysts can define user segments based on certain criteria, then track the behavior of those segments. They can assign a dollar value to each segment and determine what percentage of the customer base a segment represents.
I agree that we should fully exploit the capabilities of analytics tools. In fact, on nearly every project in which I participate, I focus very early on the analysis of any available analytics or other quantitative data. However, there are limitations to the usefulness of Web analytics.
First, even the largest companies seem to have challenges correctly coding pages to produce the wonderful results that the marketing materials for these analytics packages describe. Coding is time-consuming and requires customization. It involves intense, prolonged collaboration between corporate functions that don’t typically communicate with each other outside of status meetings. Of course, the analytics companies can produce all the necessary coding, but this value-added service is very expensive.
As a result, I often get the following response when requesting detailed analytics data: “We could conceivably get you that data, if the pages were coded for it, but we haven’t gotten around to doing that yet.” So, as a consequence, we often don’t get the data that we really need. The analytics tool, in such cases, typically ends up being used as a reporting dashboard for executives, showing the total number of widgets in each category that were sold each day, represented in aggregated graphs and charts. However, it provides few specific insights about customer behavior that could really help us formulate a UX strategy.
The other weakness of the analytics-only approach is that it ignores how UX designers work. I have yet to meet designers who eagerly look forward to getting the weekly analytics reports. For one thing, it is like getting a report card on your work, communicating the equivalent of: here’s how your designs did yesterday. That’s intimidating. Even more daunting is the idea that numbers are telling them what to design. Working with quantitative data is not why they got into design in the first place. They want to be creative. They want to understand design problems and find solutions to them.
That’s where the use of personas has been very successful. When a team formulates personas on the basis of real customer data rather than just making them up, personas accurately represent the needs, wants, and cross-channel interactive behaviors of large segments of customers. Designers can internalize the needs of their key customer types, then think of creative ways of engaging them and making them successful at performing whatever tasks they are trying to accomplish. This is a very creative exercise, which validates their problem-solving abilities and professional skills.
So, I recommend a hybrid approach to my clients. We use analytics and all other available customer data to generate a set of characteristics and behaviors to use as raw material for our research protocol. Then, we do a deep dive on developing personas—interviewing customers in their homes, conducting video-diary exercises and shop-alongs, and formulating very robust customer archetypes with actionable, differentiated characteristics. Finally, we work hard to wire these archetypes to analytics, figuring out the distinguishing behaviors that match their attributes, which we can track through analytics. This allows us to measure how many customers match each archetype, how they respond to new design work over a number of releases, and how we need to modify the personas to ensure that they more accurately reflect a real behavioral segment.
A/B and Multivariate Testing
The second reason colleagues give me for the demise of personas is A/B and multivariate testing. They say that the personas approach is fundamentally inaccurate and unquantifiable because personas are based on small sample sizes and designers have to imagine ways to support the personas through design solutions. They say that persona definitions overlap, and the result is that you can’t really know which persona a particular design solution satisfies. Their approach is to do testing of actual design variations, get quantitative results, then let the better design win.
I agree that A/B and multivariate testing are very important tools. They show which design out of several options is the best in terms of actual results. However, they don’t tell you what the best design solution really should be. You must already have completed the design and developed it to an extent that lets you test it on a live site with users. Therefore, the tests don’t provide strategic guidance about what the user experience should be; they tell you only which of the existing solutions works best.
Another problem is that A/B and multivariate testing are expensive. You not only have to set up live tests of completely developed solutions that may fail, but you have to involve quite a few people and expensive software solutions to get them running.
The main weakness of A/B and multivariate testing is that it leads to incrementalism in design solutions. Team leads want the tests to succeed, resulting in a clear winner, so they introduce small design tweaks rather than completely different design concepts. This can lead to highly tactical exercises, producing minor variations on the current design rather than the design of innovative user experiences that result in a new level of engagement for customers. And that’s what personas let us do—when they’re rigorously formulated based on actual data.
Agile or Lean Development
The third reason colleagues give me for giving up on personas is that agile development processes don’t give them the latitude they need to formulate them properly. Personas don’t fit into any sprint. UX professionals adapting to agile methods say that they are hard-pressed to keep up with the demands of writing user stories, designing features for the current sprint, and ensuring that key features make it into the prioritized backlog. There’s no time for creating deliverables—especially deliverables such as personas, for which many developers don’t understand the need.
I understand this argument and agree that UX team members need to figure out how best to bring UX best practices to bear in an agile environment. In fact, I’ve put together a workshop to teach teams how to do just that. In this workshop, I advocate a modification of the persona process to fit agile development cycles rather than eliminating them to save time. Why? Because product designs are more likely to be successful when we base them on a thorough understanding of customer needs, not on efficiency of production.
While I acknowledge—and even embrace—the benefits that we’ve gained from the process efficiencies of agile development, I foresee a designer-led response coming. When we realize that many products have failed because of the lack of deep understanding of customer needs and behaviors and how best to meet them, the need for personas will become clear. Personas, or well-defined customer archetypes that we’ve based on primary data, are a proven method of gaining this understanding. Personas, therefore, remain an important tool for UX strategy.
Conclusion
There have been some who have proclaimed the impending demise of personas as a UX design approach since shortly after their introduction. While the optimal approach to creating and employing personas is still evolving—thanks to more useful data becoming available to design teams and new project-management methods—their usefulness has not yet diminished. If anything, personas have become even more useful because they put a human face on aggregated data and foster a user-centered design approach even within the context of efficiency-driven development processes.
I agree with all of these points. Another reason I think quantitative results are not the end-all is because they are really good at showing you what is, but are not so great as showing you what might be. Personas are great for considering what might be or even as a representation of a new direction you want to go in.
Only someone who has gone through a lot of Web analytics, A/B testing, and agile methodology knows that every single line in this post is true.
In my humble opinion, this all stems from the lie that we can now measure everything. No, we can’t; and the hypotheses and requirements that we create from personas are the best conversion boosters.
After years of dismissing personas, I finally worked with one that made a huge difference to our thinking. I think the difference is that it was the first time it was deep and insightful enough to matter. People assume that creating a persona is a trivial matter of coming up with a picture, some demographic info and some other fairly straightforward stuff. Not so. It can take months or years of insight and deep expertise to develop it. The persona is the outcome of experience, research, and experimentation.
In my opinion, collected usage data allows us to create more accurate personas, not replace them.
All this new data that we have available mostly gives us data on current usage. However, our current users might not be the user, or persona, we intended to have use our product. This might be a good thing when you’re on a lean path to find your product fit, but in other cases, it could be a problem that requires changing things to attract the correct user type. Here personas are very valuable there because they give you a focal point for everyone in your organization or team to work with or toward—or even just as reference to guide the current UX implementation.
I’ve had hit-or-miss success with personas over the years, for many of the reasons you mentioned. Part of the problem, I believe, is that our approach to personas examines people the way they currently behave. But what if we instead used personas to describe how our customers should behave in the future?
Personas then become strategic, and no amount of analytics can measure their validity. See my recent post on this topic, “Who Do You Want Your Customers to Become” for more.
I think what distinguishes UX strategy is the >User bit in UX. In other words, doing the user research—amongst other research exercises required for both strategy in general and UX strategy—up front is the value we add by doing this. In my practice, I blend as many forms of user research—both qualitative and quantitative—as possible, because it informs the strategy in a more robust manner.
In a recent project, robust qualitative interviews (130) and quantitative online surveys (3000) painted a picture, expressed through personas, that radically changed my client’s understanding of their target audiences and how they develop value propositions. They changed all their marketing and product efforts from classic demographic-based target audiences to psychographic and behavioural persona-based segments.
At the strategy stage in the project, personas were a useful tool to bring this new segmentation model to life, but were not an absolute requirement. I could have found other means to express the segments. Nonetheless, they made the shift more digestible and acted as a bridge, or a golden thread, from user research findings into strategy and through the iterative design and development process that followed.
Personas, more often than not, are for the client, not the UX guy. Why? Because most agencies use them to show the client that they have understood in the briefing what the target group is.
I haven’t seen any real budget for finding out who the target audience is—and therefore, in my experience, this information is taken from the briefing. And how should we create personas if we don’t get into knowing the real characters behind them?
In a sense, analytics are better than straight personas because it’s the real people or visitors of the site deciding.
I had clients who were really proud of a section of a site that no visitor was interested in, and I could prove that through the metrics, so we freed up resources for other parts of the site.
How would a persona have achieved this? An invented persona not interested in a part of the site can simply be rejected my the client.
I agree that a combined approach would be great, but most companies don’t collect customer data in a way that is useful to designers—but is to them—and if they have this data and they know their customers well, then the briefing will be accurate enough, and you can use the briefing as personas.
At least, that is my experience working both in agencies and as an internal design team leader.
Personas are one of the most powerful methods in product design—if created and applied properly. The problem is that many self-defined UX experts don’t have the expertise and the power to effectively establish this method in the company. Personas are a strategic instrument that can be useful for many parts of the company. A/B testing and Web analytics are additional, but not replacing methods. I think personas fit quite well in agile environments if the team is skilled and understands the benefits of the method.
After creating personas for years, this year I created them in a most UX-challenging environment: an XP+JAVA development, lean project at an advertising tech startup now 100 strong, and we’re getting toward success with them. The knowledge encapsulated and shared amongst the team and stakeholders alike has been invaluable—not only in shared understanding, but also for valuable consensus otherwise lacking—and led us to insights and conclusions that would have been impossible otherwise, I’m quite sure.
+1 for personas.
PS: Quite to the contrary of some no-persona-leaners, Jeff Gothelf, author of forthcoming Lean UX, firmly advocates personas in his workshops.
Content strategy should be done before focusing on IA, UI, IxD, or anything else associated with UX; and a content strategy needs to be informed by users’ wants and needs.
If the team can’t align to a set of personas, creating a cohesive content strategy will likely prove to be very difficult.
I agree that design might not find personas to be as valuable, but if content strategy is not based on user data, it will set the entire project up for subjective interpretation and could lead to a business-centric product.
It’s always better to start being customer-centric; and personas are a valuable way to keep teams focused. Whether it be a flimsy user profile or a full persona and customer journey set, having team alignment tends to make projects run smoother and return a better end-product.
Naomi: Great point. Using data is extremely helpful, but it’s kind of like driving using the rear view mirror: it shows you what has been up to now, but not the possibilities of where you could be going.
Xavier: Thanks for the validation. I think personas should accurately reflect analytics, in terms of behavioral segmentation, and be refined over time by using analytics results. But they are also a good way to invent hypotheses that would be difficult to arrive at through looking only at statistics.
Deb: I have had the same experience. Flimsy, conjectured personas turn people off forever to the concept. Our approach of basing personas on quantitative and qualitative data turns personas into realistic customer archetypes that we can measure and refine over time. They engender empathy in the design process for the life context, needs, wants, and behaviors that millions of people experience from a brand.
I agree that a blended approach is probably the most effective. You can never go wrong with richer, more accurate data.
I might argue that in many, if not most, engagements, there is no time to do an exhaustive audience segmentation, never mind building them out over months or years. I agree with an earlier commenter that, if the client has any useful, end-user data, that’s probably enough to get you pointed in the right direction.
I also disagree with the idea that “small design tweaks” identified during usability testing—A/B or another method—is a negative. In a large project, no matter how well you know the audience, you’re likely to have some big misses. Iteration is a major benefit of the medium, allowing designers to reevaluate content strategy or interaction models.
Though I have been surprised in usability testing in the past, experience counts for a lot during the analysis and design process. Traditionally, we know what’s worked in the past and when to go out on a limb with a new interactive model or content strategy. If it’s a sufficiently different approach—for example, Windows 8—personas will be of little value. The modern interface, for example, would appeal to almost nobody, but I’m sure usability testing helped refine their approach, which still needs refinement.
So, though I’m not opposed to personas as a design tool, I don’t see them as a required tool. Perhaps if a project presents itself as a good candidate, I may change my mind. Great article!
One thing I see as a problem with personas is that the word is generic and means different things to different people.
If you are doing observational research to build personas with clients that represent real customers’ behaviours and needs, then there will always be a need for personas, in my view. The power of being able to bring life to customers to help inform decisions versus subjective guesswork.
Web analytics is a quantitative tool and a very useful tool to use. But data can be misleading and can lead to you to make the wrong assumptions. A good read: “What Data Can’t Tell You About.”
For me, the greater challenge is differing definitions and quality of personas out there.
David: I agree that personas give people throughout the organization a common focal point for their efforts.
Raphaël: Personas are one work product that emerges from a task-based segmentation, and they provide nuance to mental models. I don’t see a conflict.
Jim: Thanks for the confirmation. I’ll have to take a look at the post you mentioned.
Jason: I agree that personas need to be based on data to be effective. If possible, the personas should be based on both qualitative and quantitative data—or at least be corroborated through quantitative data. One of their key values is putting a human face on the aggregated data.
derfrankie: Personas are also for the UX guy, because she or he should base their work on all key components of the UX strategy, including target behavioral segments. Otherwise, they are moving in their own direction, which is not constructive for any but the smallest companies. There is budget for target-audience definition, but it has to be justified by compelling results. Analytics are a much better tool for showing current site usage, but analytics do not inspire innovation, as the article explains.
Reiner: I agree that some executives are turned off by personas because the previous experiences they’ve had were led by people who didn’t understand the principles of behavioral segmentation or the intricacies of applying qualitative and quantitative data to a model.
Claire: In our workshop “Optimizing UX for Agile,” we start with the notion that linear persona creation—from research to completion—is not feasible in agile environments. Instead, the UX team needs to use a discover track or sprint to develop the personas, and then, in each sprint, overlay the backlog features with a relative value to each persona. This helps prioritize the backlog and also to deprioritize features that do not benefit the most important personas. Each usability test should result in a refinement of the personas, which, when tied to sprints, results in continuously updated personas rather than relegating them to the typical annual personas refresh.
Mike: I’d like to hear more about this process. Sounds like a good case study.
Jordan: I agree with everything except that flimsy user profiles are useful. I find they do more harm than good, because they cause a rationale to be built on false premises or non-representative characteristics.
Sam: I don’t think persona formulation should be part of a design engagement. I think they should be formulated for the company as an on-going model of customer behavior, refined over time to account for trends in the marketplace, new technology, changing customer needs, and so on. The problem with existing user data is that it’s not in a format that can guide and inspire the UX team or help leaders make a call when considering competing feature sets. A/B testing isn’t a negative, but it gives you a read only on designs that already exist, while personas can help you design innovative experiences that nobody has designed or perhaps even thought of. I think personas would be very valuable for creating Windows 8, because it’s a deep understanding of customer needs that would help the team avoid the syndrome of simply releasing a bucket list of features dressed up like a product.
Ilaria: The workshop is called “Optimizing UX for Agile,” and I would be happy to send you a onesheet describing the workshops if you send your email address to paul at uxstrategy dot net.
I have created and used personas very successfully on several projects over the last few years. And, yes, I think they have a clear place in UX strategy.
First, many organisations we work with still have only a superficial and largely unresearched picture of their customers. In those organisations, personas based on user research can have a huge impact. They are often the first crucial step in getting those organisations to start thinking outside in. For most people, they are much more effective at doing this than traditional market research charts and graphs that often feel very abstract and impersonal.
Second, to answer one of the points above, personas are a great repository of your evolving understanding of your customers. So don’t create them and forget them. Update them as your knowledge grows and your assumptions are proved right or wrong.
Third, they are primarily about behaviours, not segmentation. So, of course, one actual person can act more like one persona at one time and more like another persona at another time.
Fourth, also of course, personas are not a substitute for hitting the streets and talking to real customers. But in most organisations, not everyone can do that regularly. So use personas as a way to capture and communicate what you do learn.
Fifth, I don’t see any conflict between using personas to capture what you learn about customers, as well as using analytics and A/B testing. You can use the insights from analytics and A/B tests to refine your personas and, in turn, define new experiments. If your data doesn’t tell you something that you can put in the context of a real user, I would question what you are learning from it.
Sixth, Lean UX thinking has shown how quickly you can craft skeleton personas that capture your current knowledge and assumptions and highlight the areas where you need more research and experiments to expand and test your knowledge. So you can discard the we-don’t-have-time-for-all-that-research arguments.
Finally, personas have been described as empathy engines. We should not underestimate the power of that empathy plays in helping shape and drive through a UX strategy.
My understanding is that one of the most common misuses of personas today is to transform them into some sort of false market segmentation—just to make stakeholders happy.
My question: Do any of you have any good ideas about how to present knowledge of users’ behaviour to people outside the project team?
I believe that personas don’t necessarily work for this kind of knowledge transfer if the reader hasn’t been involved in the whole process from the beginning.
John: Thanks for posting your thoughts. This is a solid set of arguments for continuing to use personas to drive UX strategy.
Jon: The way you communicate user behaviour depends on the role of the people you’re communicating to. I think personas are a tool that everyone in the company can and should understand. But I think other documents could also help tell the story. For example, you could include an interaction model that shows how each persona uses the product or site today, with some aggregated analytics, and show how you anticipate they will use future releases in the UX roadmap. You could develop usage scenarios based on user interviews and/or analytics. If you’re presenting to marketing, you may want to show what each persona needs in terms of brand communication and strategy to become a loyal fan. If you’re presenting to IT, you might show graphs of usage patterns.
Personas without scenarios are as useful for UX strategy as linear thinking in a dynamic, disruptive world. With that said, I agree with all four points above. :)
I, too, still have faith in personas—even in a very agile, enterprise development environment. I think the biggest problem I’ve seen in their use is the inability of many in development to use them to inform design. It seems to take a seasoned UX professional to utilize them well to formulate designs rather than to simply validate designs against them. In addition, typical persona data does not give much information for the visual and interaction design sides of things. You still need top-notch designers in these areas that are aware of current trends and best practices. On top of that, the owners of product definition and features are often not the consumers of personas, which marginalizes their use. These are not flaws in personas per se, but they are misunderstandings of their use and value proposition, which undermine their effectiveness in practice.
Analytics and multivariate tests don’t explain why people do what they do. They give only data, a lot of data, but you haven’t the why, the needs, and the goals that guide this data.
For me, it’s impossible to create a design without personas, looking only at the quantitative data.
“I foresee a designer-led response coming.” It will have to be a final acknowledgment from division heads and Product Owners, admitting that user stories are just one step removed from an old-fashioned Functional Requirements Document. The user stories may accurately describe the functional requirements, but still produce a mediocre—or even worse!—an unusable piece of software.
Paul organizes the UX STRAT conferences and workshops to help experienced UX, CX, Product, and Service Design professionals continue to grow their skills, networks, and careers. A UX strategist and researcher, he also consults with companies to help them evaluate and grow their UX Strategy capabilities. He began designing ecommerce Web sites in 1995, in Barcelona, Spain; then founded Retail UX in 2002. Paul’s consulting clients have included some of the most successful corporations in the world—such as The Home Depot, Coca-Cola, SAP, Delta Air Lines, Philips, Macy’s, Bloomingdale’s, Cox, and GE. Paul manages the UX / CX / Product / Strategy Group on LinkedIn. Read More
