Personas get a bad rap. Often when I talk to people about creating personas for their organization, I receive a list of reasons personas have failed for them in the past. We have previously documented some of the most common reasons that personas tend to fail:

  • Personas were created, but not used.
  • There was no buy-in from leadership.
  • Personas were created in a silo and imposed on people
  • People didn’t know what personas were or why they were useful
  • There’s a fundamental flaw with the personas

But there is another way that personas can fail, and sometimes stakeholders are not even aware of it: the personas have become outdated. One might be tempted to place the blame for this state of affairs with the current stakeholders or owners of the personas, but, in reality, often the problem is with the personas’ original creators. The problem is that the personas were never created to be updated.

When and How to Update Personas

Personas should not be updated merely for the sake of doing so. In fact, unnecessary updates can be counterproductive to the organizational adoption of personas. The stability of personas over time is critical to their ability to be remembered and internalized. On the other hand, personas need to be flexible enough to accurately represent the organization’s current users. This tension between stability and flexibility can be challenging to navigate, but there are some tools and frameworks to help.

Personas should typically be updated only in response to changes in the business landscape or in user base. Minor changes to features or service offerings typically will not necessitate a persona update.

That being said, our own research has indicated that frequent updates to personas do correlate to higher stakeholder ratings of personas’ impact on the product’s user experience. With that in mind, it is important to consider the scale of updates. Not every update needs to be a complete overhaul of the personas altogether. Again, entirely redoing personas will mean restarting the process of organizational adoption. Often, business or demographic changes can be incorporated into existing personas merely with minor tweaks.

Yet, even when armed with this knowledge, some organizations fail to make necessary and timely changes. Why? In some cases, it may be due to a disproportionately high amount of time and effort put into making the personas visually stunning.

Pretty Personas Are Not (Always) Good Personas

Earlier in my UX career, I wrote an article titled “The Best Personas Are Ugly.” The argument was that personas are meant to be living documents that can easily adapt and change with the fluctuating realities of a product or audience and, as such, should generally exist in a format that is easy to update, such as a simple slide deck. Often, I find that the “uglier,” less polished personas, meaning the work better and for longer.

Since writing that article, my view has tempered somewhat. There are times when a beautiful set of personas is appropriate –- for example, if personas are new to your organization and you’re looking to impress high-level stakeholders. Additionally, as noted above, the ability to iterate on personas can occasionally be a detriment, as personas that change frequently fail to be memorable.

The core components of my previous arguments, however, remain true: overinvestment in the visual design of personas is tempting, but risky. Below, I outline some of those risks, as well as some situations where those risks may be worth taking.

Uneditable File = Immutable Data

Imagine you’re collaborating on an article with a peer, and you want their feedback on your most recent draft. Would you send them the original document file (e.g., Word, Keynote, Google Doc) or a PDF? In either case, your colleague can easily read the file and let you know their thoughts; however, the two formats convey different messages and intent. A Google Doc, for example, encourages inline commenting and back-and-forth collaboration, implying that you are open to making both major and minor changes throughout the document. A PDF, on the other hand, implies finality and permanence. It might subtly convey the message “Send me an email if you see any typos, but otherwise, I’m feeling pretty set on this version.” Because your colleague cannot easily edit the file, it communicates that the data contained within it is final.

The same is true of personas. If the final deliverable is, say, a Photoshop file that your team doesn’t know how to edit or, worse, a printed poster and nothing else, it may as well have been carved on a stone tablet, because the message it conveys is that it isn’t changing anytime soon. If the product or your audience fundamentally shifts in a meaningful way, there won’t be a means of updating the personas to align with the changed reality. As a result, they will simply become outdated.

Outdated personas don’t get used, and unused personas get discarded. The impact may even reach into the future: the organization may forego personas altogether, because it already “tried” them.

Design with Future Iteration in Mind

For this reason, I generally advise teams to produce their personas in “the prettiest easily editable format available” for the team. This means that, if the team assembling the personas is a research team with no advanced-design skills, it should stick to a simple and utilitarian slide deck. This format will typically also make the personas easy to access and share, as persona decks could easily be posted where teams already go to for requirements (e.g., Confluence, wikis, design systems).

Teams that have access to design resources can produce highly polished artifacts. The trick is to accurately assess your team’s strengths and capabilities.

Example of a simple persona
A simple and easily updatable persona design like this one can prove much more valuable in the long run than something flashier and more polished.

The risk comes when a team feels obligated to make their personas beautiful and, for example, hires a freelance designer. This is where the overspending of resources on the initial iteration can inhibit the team’s willingness or ability to update the personas moving forward.

A persona is, first and foremost, a tool, and a tool is only as valuable as it is useful. While visual appeal certainly has value in the adoption and socialization of personas, particularly with external or high-level audiences, it is important not to overreach. Save that budget you may have spent on a fancy design agency and put it towards educating your organization about how and why to use the personas. You’ll be glad you did!