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.
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:
A/B and multivariate testing
agile or lean development
I’ll discuss each of these three reasons in turn.
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.
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.
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