Adapted from branding and market-research tools, and popularised by Alan Cooper in The Inmates are Running the Asylum, personas are fictional profiles of key users of a system.
Distilled from user-interaction requirements, market and demographic research, and other sources, they are a useful tool for getting the design and development teams in the same headspace. While an extensive, line-by-line specification is useful for defining the scope and requirements of a project, personas are useful for defining the spirit of a project. A shared set of personas can put the entire team on the same page psychologically and emotionally — at least, for the purposes of a project.
Personas are not use cases or user permissions, though they may be a useful tool to define them. Rather, they are a psychological and personal profile of an expected user.
Defining these profiles is a useful exercise for the whole team. It allows everyone’s input into the project, and allows the distillation of common, important, and edge user requirements. It’s a great way to get brand managers, account managers, and marketing folk in early, and help them feel involved, and it’s a good reference point when conflicts arise later.
It’s also useful as an exercise to acknowledge and discuss the implicit personas that we design and develop for ourselves, our parents (or a suitable “basic user”), the user (sometimes a technological savant, sometimes not), the account management, the judging panel for an industry awards program, and so on. Without taking the time to address these imagined personas, we run the risk of subconsciously building our software for them.
Once we have taken the time to define our personas, refine them, imagine them, even playact them a little, we now have a shared emotional register for our work. We can frame our user interactions in terms of a specific persona, and use it as a shorthand for a specific frame of mind, a level of technical expertise, and specific desired technical and emotional outcomes.
This allows us to write our specification in more natural language, focusing on user flows and content journeys, rather than line-by-line use cases and data tables (caveat: please talk to your dev team before making this change).
However, personas are useful for more than simply modelling our users. Personas are a great tool for modelling our software itself!
Consumers are more likely to engage with software if they feel a positive emotional connection with it. As Aaron Walter, author of the excellent Designing for Emotion and user-experience design lead for MailChimp wrote:
Experiences that lack an emotional charge tend to fade from memory. Thus, conservative, familiar designs are likely to be forgotten. Medina eloquently sums up the main reason why we designers should employ personality and emotion in design: “The brain doesn’t pay attention to boring things.” When we design with personality, we are building a framework through which emotional experiences will remain in the memories of our users.
MailChimp succeeds for a number of a reasons. It’s a solid mailing-list tool, it’s easy to use, it has a freemium model for low-end users, good analytics, and a great template system. That said, there’s a lot of email list tools available, so how does MailChimp stand out?
MailChimp has a personality. It’s funny. It’s cheeky. It feels like it engages with you.
How does it do this? There’s clearly no monkey there, no comedian at the other end spontaneously conversing with you. It does this by having a clearly defined personality. A clearly defined sense of humour, both in terms of how it jokes and when it jokes. A lot of thought has gone into precisely when and where the personality is brought through in the site.
Now, documentation for giving a service, a brand or a software tool “personality” is nothing new. Copywriters have “tone-of-voice” documents. Designers have style guides. UX designers have interaction styles and patterns.
To bring this all of this thinking together requires a concerted effort, though. A tone of voice document tells us what to say, but not necessarily when to say it. A style guide gives us a sense of a brand or a style, but not necessarily a personality.
This is where a software project persona can come in handy.
We already anthropomorphise our software. From the Apple/Microsoft ads that portray Microsoft as a stuffy accountant and Apple as a scruffy hipster to the irritating teenager of MySpace to the neckbearded Unix, we tend to think in terms of personality.
Sometimes we associate the software with a company CEO, sometimes with a general brand avatar or spokesperson, sometimes with a cultural archetype. These personalities don’t always match the personality of the software, but they speak to a very human tendency to ascribe emotional and psychological attributes to inanimate things.
If we set out to define a persona for our software projects in advance, we can create a fuller picture of what we’re trying to build. We can understand its personality, its voice, its sense of humour.
We can, and should, still talk about look and feel, branding, marketing, tone of voice, design patterns, and so on. But starting with a software persona creates a powerful shared understanding that can underpin all of these discussions.