Using Personas in Open-Source Projects

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?

preview of persona template

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.


Straight Talk: New Yorkers on Privacy

Our research on New Yorkers’ use of mobile messaging offers actionable insights into how to design secure communication tools for a mass audience.

Usability and Security: Not Binary Properties

People who think about computer security for a living sometimes cringe when they read about the subject in the popular press. Security is a complex and nuanced topic, and it’s easy to make assertions that don’t hold up to careful scrutiny. One basic-but-unintuitive principle is that security is not a binary property: in the absence of other context, it’s hard to definitively say that a particular system or piece of software is “secure” or “insecure”.

Users are people too: our talk at Shmoocon

Last week Gus and I gave a talk at Shmoocon in DC. The focus was on helping technologists who don't have experience in human-centered design processes conduct basic research to improve their existing open-source tools. We covered four basic steps that we believe even small or volunteer teams can take: Agree on your target users Do an expert review of your UX to identify (& fix) low-hanging fruit Interview real users Build a model of your users and their needs Smooth the path for user feedback Iterate until you get it right Overall the talk was well received, with a few choice quotes making their way onto Twitter.