The Cult of User Personae

Posted by

On alternating Tuesdays, I get to be a young second-generation immigrant woman named Selene with great phone presence and multilingual skills. Or I could be a beefy mid-30s guy named Silas with a buzz cut and a flair for figures. Or any of a few others, or several of them in succession.

Every second Tuesday is sprint review day in my department. Our agile teams (those like me who create and test the code) gather to show our execs and internal customers what we’ve done since last time–i.e., during the last “sprint.” And I get to indulge in what may be the world’s least intensive acting career.

As a scrum master, I need sprint reviews to reflect progress made in enhancing our product’s functionality, tightening up its reliability, and shoring up its long-term viability. As a usability engineer, I need us above all to focus on the experience of the human user at the end of our efforts. How to do both? That’s where Selene and Silas (not their real names…not that they have real names) come in.

Selene, Silas and the rest make up our team’s pantheon of user personae. They are, in essence, imaginary friends of ours, in whom we amalgamate our understandings of those actual human beings who will create, administer, and consume data via our product. Many software teams use personae to guide their user-centered thinking, but there is a richness available in them that I think may go generally untapped.

When I am designing a control, I think about what Selene would like. When I user-test or field-test a UI in front of real users, I refine my understanding of who Selene is. When I help spec a feature through a “user story,” I phrase the objective in terms of what she wants to do—“As Selene, I want to switch display text language easily so that I can conduct business in different languages.” And when I demo a feature that has been coded, I impersonate her, literally announcing, “I’m Selene, and I’d like to switch the display text language to French so I can conduct business in that language.”

In fact, when I use the word “pantheon” to describe our group of user personae, I actually do so advisedly: Traditionally, pantheons personify an otherworldly realm in order to allow those in this world to relate to that realm, and in a sense, personae do the same thing.

A Roman smith felt his work was given meaning by its parallels to Vulcan’s; Polynesian mothers felt comforted by Haumea when facing childbirth; a Hindu shopkeeper invokes the blessing of Lakshmi on his business. In general, the archetypes in these pantheons essentially humanize the divine realm. Those of us in design and development also spend time thinking about a mysterious world we never truly enter but whose denizens mean everything to our tasks, and that world is the world of users. We make that world more intelligible and navigable by appealing to our personae.

The more we invest in our personae, the more present they become in our work—and the more our “usability culture” begins to resemble an honest-to-goodness culture. Ultimately, I can envision a style of work that bears some resemblance to many traditional societies’ casual relationships with their pantheons, in which our personae influence most of what we do and crop up in our conversations, jokes, and collective memories. What will happen, I wonder, if Silas becomes important enough—perhaps “venerated” enough—that our QA engineers “feel” him with them when testing, like a Spartan felt Ares with him in battle?

I have never yet opened a sprint review with any variant on “O Selene, accept our humble offering,” but the time may yet come. (Though for that, we may have to move our semi-weekly ritual to Mondays.) In the meantime, we will do what we can to propitiate the gods—er, that is, meet our users’ expectations.


  1. Sasha,

    do you also use context and situations for designing? What about the same personae expecting different things when they are in different contexts?
    I found the thoughts and discussions of the jobs-to-be-done crowd pretty interesting in this regard.
    Also I believe that demographic information does not influence behavior or expectations. What is in your persona description to help you design for the different needs?

    Best regards

  2. There is definitely some value in creating user personas before you start product development but I believe now it is being overused. Wondering if popular products of our generations like Facebook, Twitter, iPhone, Snaptchat or even Slack had elaborate User Personas in place before developing the products.

  3. I partly agree with Abhishek above in that it has become a UX Deliverable which is there because its part of the process than something which leads to something concrete, which can influence the Product Design. Whether it should indeed influence or not is always a contentious question.

    Also the diversity of the users make it difficult to have a concrete User Persona for a large section of the user.

    On a side note, whats your take on Empathy Maps?

  4. In reply to Jens (sorry for the delay), to me a persona should be as fully-rounded and believable a depiction of an actual individual human being as possible, while remaining an ideal amalgam of all users of a certain type. Such an individual will certainly have different motivations and responses in different contexts.
    One way of integrating a jobs-to-be-done approach with persona-driven design is in feature spec. (I generally spec via user stories expressed in terms of a persona, what they want to do, and why.) A feature is, I agree, rarely if ever desired by a user because of their demographic; it’s desired because of some contextual need. At the same time, an aggregate (and possibly ongoing) list of contextual needs informs and fleshes out the understanding of who a user persona is, *and vice versa*. It can be very similar to how our experiences of actual people influence our understanding of who they are, which in turn influence our experiences with them.

  5. In reply to Abishek and Anirudh, certainly any given technique has to be evaluated for its applicability to a particular product. If we discover that a particular process artifact is not actually adding value, nothing should force us to continue it. At the same time, 1) investment in personas, in terms of time and effort, is fairly small compared to other ongoing aspects of a product development process, and 2) it may not be easy to measure directly the gains conferred by the ongoing reminder personas constitute that one’s team is designing for and serving the needs of real people – or to measure the influence of such a reminder on design or design success.

    Empathy maps themselves seem like a natural fit into a persona “brief”; that is, one can easily include a map (or more than one contextual one) in the description of a given persona and thereby flesh it out further.

  6. User personas (or personae, if you are replete with pretense) are for people with limited imaginations. We don’t need to know the pretend-user prefers the color red, eats only twice a day or likes to drive only brand new cars. Thinking at a higher level is more productive; meaning that we should be considering a user’s purpose on a particular site or within an app, not their personal preferences, names or lifestyles. Yes, it’s fun to think they might be a jock with a buzz cut and a penchant for cheap IPA’s but in the long run it’s meaningless information that ultimately does not affect decisions. What affects decisions and actions is intent. Why are they using your app/site in the first place? What actions will they take? To me user personas really are just a cult of popularity.

  7. UX is the most important part of web design. It appears first to the any use so it is more important to make it unique and easily understand by any user. If user likes to explore your web site then they stay more and visit often.

Comments are closed.