Design is all about making decisions. From a rebrand to a feature specification, from a new product to a new logo, every design change presents you with a fresh set of decisions.
In open-source software, we often start out with the admirable goal of basing these decisions on the needs and preferences of our community. As a user-centered designer, this makes me feel like half the battle is already won – many companies would prefer to make these decisions entirely internally, and need a lot of convincing in order to take outside input seriously!
However, open-source projects can lean too far in the other direction. It’s not always practical to have the entire community weigh in on every decision. This can lead to a slower pace and to discussion fatigue, and can also cause louder or more urgent voices in your community to take on more weight than you’d like.
Personas are a way to crystallize your goals, keeping your focus on people without needing to call a meeting or ask for input at every turn. You can use them as a heuristic to help you make decisions. They’ll remind you of your mission, and keep you honest during your internal conversations.
In this article, we’ll take you through how to create personas for your open-source project. If you’re able to do actual user research, definitely base your personas on actual people you talked to. If you’re not able to do research or testing with users, we think you should – everyone should learn a few quick, basic tools for engaging with their users. If you’ve never done any engagement with your users and have been creating your product based on hypotheticals, you may be wasting your time.
What a persona is (and what it isn’t)
“Renee would love this,” my colleague said, pointing to a mockup of a redesigned file browser. Renee wasn’t our boss. Renee wasn’t a user we’d interviewed. Renee wasn’t even real! Renee was a persona we’d developed. If you’re curious, Renee was an experienced, savvy admin who had an encyclopedic knowledge of keyboard shortcuts and hated touching a mouse. She was a combination of several people we’d interviewed, our best guess at an iconic user for this particular piece of software.
A persona is a slight abstraction of a human who might use your product or service. It often takes the form of a quick portrait: a name, an age, a job, an appearance, enough to give you a sense of who this person is.
“Our audience is more than just a few people,” you might be thinking, “so why get so specific?” At first glance, defining a broad target demographic might seem more pragmatic, because you’re including more users in your intended audience – and, in the world of open source, we often strive to make our products inclusive and widely usable.
However, defining your audience broadly has a couple of pitfalls. First, it’s hard to use demographics to make decisions. Try and picture a woman between 18 and 35. Not so easy, is it? You certainly can’t think “would a woman between 18 and 35 understand this branding?” Second, using demographics to make product decisions can lead to stereotyping. Answers to questions like “would a woman between 18 and 35 use this feature?” might veer uncomfortably close to implying that a young woman would prefer pastel colors and a simpler interface. Nope. Not going there.
This is why we say that a persona is a “slight” abstraction: if you abstract too much, you’ll end up with a vague demographic description that isn’t actually useful to you. (Just like every article ever about “millennials.”)
You will probably want to make multiple personas. You can give them nicknames in order to keep them straight: a team at the UK Digital Service created 7 personas during a project to evaluate their Perfomance Platform, and named them (among other things) “Bart the Active Citizen,” “Anna the Strategist,” and “Eric the Guide.” Don’t make too many, though, or you’ll have too many “people” in the room.
What to include in a persona
Your persona will have three parts. The first part is demographic. Give your persona a name, an age, a location, and an occupation, no matter what. Be specific – “John Doe” or “Max Mustermann” won’t be very helpful to you! If it helps, pretend you are describing a character in a book or movie.
Then, depending on your product, you may want to answer some behavioral questions:
- Is this person a current user of your product?
- What communities is this person a part of?
- What are this person’s hobbies, or their family situation? (Include this only if it’s relevant.)
- What technologies does this person use, and why?
The third part of your persona has to do with their goals. You may want to answer the following questions:
- What are this person’s goals in life?
- What are their goals at work?
- What makes them feel good when using a technical product? And what makes them feel bad?
- If they use this product, why? And if not, why not?
- What do they want this product to do for them?
We’ve made these sections into a template that you can use (and modify). Download it here: PDF and AI
Not all personas need to follow this format – in fact, it’s better if personas have information specific to the product or project you’re working on. Our former fellow Gus Andrews put together a set of security usability personas. They include sections like access locations, technology threats, and physical threats, effectively building a threat model into each persona. So, feel free to customize the sections you include. Our suggestions are just a starting point.
Further links:
https://www.usability.gov/how-to-and-tools/methods/personas.html