Persona Driven Development

Be an advocate for your users

When you develop a software project, do you understand who you are developing for? Do you understand what that person is interested in? What types of technology does your user have exposure to?

Understanding your users is essential for building a great product. A successful product is one that customers “actually want”.

But how can you build something that people “actually want” without understanding who they are? That’s where Persona Driven Development comes in.

What is a Persona?

A persona is a fictitious person who represents a certain user group within your app. In the context of app development, a persona can represent people who have the same lifestyle choices, have the same preference for technology platforms, and purchase similar apps. They also fall in the same age group and have the similar education and other typical demographics.

What is Persona Driven Development?

Persona Driven Development is an approach to software projects that puts users first, making development decisions based on who uses your app and what their scenarios of use are.

Essentially, if you understand who your user is, what products they are using, what platforms they are currently on, and what issues they have, you can better manage your project and prioritize your stories, or software features, for your sprints.

You can use personas even before you start development. If you understand your user before you ideate for your app; before you write a single line of code, you can make informed business decisions for your product, such as understanding what platform to develop your app on, and what revenue model your app should adopt.

This practice is also essential for eliminating bias in prioritization. It’s easy for developers to develop features that they think will be useful or cool for themselves, but not necessarily for their core users. In an environment where speed, rapid iteration, and MVPs are important, you might be wasting time developing an unnecessary feature.


How do I develop a Persona?

There are a lot of different ways to develop a persona. This is the process I use:

Step 1: Talk to people who use competing products (or use your own)

This step is easy to start but hard to master: your goal in this step is to try to understand the benefits and pain-points of your service and other services out there. To do this, you want to interview people who use products that are in the same market category as yours. Ask them as many questions as possible. Remember, it’s always better to ask too many questions than to ask too few. If you don’t ask the right questions in this step, developing a persona may be very difficult later on.

In this process, you should keep a uniform question set so that you can directly compare responses between different people. It’s okay to delve deeper or keep an “other” section based contextually upon people’s responses, but you want to structure the majority of your questions.

For example, if you are developing a calorie tracking tool, you may want to start by interviewing users of competing products like MyFitnessPal or Nutritonize. You might additionally consider interviewing users that use fitness tracking devices as they might have used a calorie tracking tool and ended up disliking it in some way.

These are some (but certainly not all) of the questions you should be asking:

  • What do you use this app for, and why?
  • How frequently do you use this app, and for how long?* (note the distinction: are they using it for one long period of time or short bursts throughout the day?)
  • What pain points are do you run into when you use the app?*
  • What features do you use the most?*

*Keep in mind that these questions ask a user about their own behavior, which may differ from how their actual behavior. Getting a sense of both what a user thinks they do, and what they actually do is a good idea.

For example, when I interviewed users of MyFitnessPal, I found out that these users tended to use the app 3–4 times a day to enter their caloric information. Usually, this was right before or after their breakfast, lunch, or dinner times. In addition to that, I found out that most users wanted to lose a lot of weight or gain muscle mass. Finally, I noted that these users didn’t really look at the graphs that tracked their daily calorie balance over time (weekly, monthly, etc). They actually spent the majority of their time within calorie logging process.

Now that you have all of these responses (or raw work activity data), you can use this data to generate groups and themes to drive your personas and create scenarios of use.

Step 2: Group together your notes and create Work Activity Notes

From the previous step, you should have quite a bit of data to sift through. We now take all of that information and distill it into what we call Work Activity Notes.

First, read through your notes that you took in the previous step and turn each note into a bullet point of some sort. You’ll want to summarize your note into 1–3 succinct sentences, extracting the main point from the raw notes that you took earlier. Your goal should be to get around 60–100 generated notes extracted from your raw notes.

Here’s an example conversion from my interview with users of MyFitnessPal:
“I starting using MyFitnessPal when I wanted to get back into shape. I started running a lot and I wanted to set calorie goals for myself. I use MyFitnessPal to keep myself under my calorie goal. I try to log my information around the time that I eat. If not, I’ll try to enter the data at the end of the day. One thing that I really don’t like is that I constantly have to search and re-enter foods. For example, if I have eggs for breakfast every day, I can’t click on it and just add it. I have to keep reentering eggs every single day in the morning.”
I took that conversation I had with that user and broke it down into the following Work Activity Notes:
“I use MFP to lose weight and get back into shape”
“I keep track of my calorie goals using MFP”
“I try to log information throughout the day when I eat”
“It is important for me to have the best view of my day, so I will backfill data at the end of the day”
“I dislike having to reenter the same data on my food tracker”

*These generated notes are essentially the same as Agile story names and you could generate them in the same exact way if you wanted to. Heck, you can even start out with the famous “As a User,….” line if you wanted to.

Once we have these generated notes, we want to group them into categories. I recommend tagging each generated note into an appropriate category name. You can use these tags to generate groups and themes. I’d recommend using sticky notes and pieces of paper for each generated note. Alternatively, you could use software such as Mindnode. Both methods work just as well!

For example, “I keep track of my calorie goals using MFP” could be tagged goal-tracking.

By the end of your process you should have approximately 7–10 groups of notes with about 5–10 notes each. From these notes, you should be able to generate a persona and maybe even some scenarios of use.

Step 3: Generate your Persona

From our previous steps, we now know who our general userbase is and what they like and dislike. Based on this information, we can come up with a Persona*.

*Typically, you should generate a set of personas for a product, for the sake of the example, we will only construct one

A persona is an amalgram of the real users you have interviewed — a representation of a set of user’s backgrounds, behaviors, motivations, frustrations, and stories. The key to generating

For example, here is a generated persona for my calorie tracking app:
Jacob Leopoldo
Jacob is a 23 Y/O working professional who gained a few pounds after graduating. He is no longer in shape and he wanted to lose 15lbs after the new year. In order to better track his activity, he bought a fitness tracker and is using a calorie tracking tool. He tends to use this app in short bursts throughout the day. He tries to fill in his calorie and macro information right after he is finished eating. If he can’t get to it, he will do it after work. Jacob likes to plan his meals to reach his calorie goal, but, he bases his eating choices when he goes out with his friends on how many calories he has left and by searching through the calorie tracker app for meal options. Jacob loves getting badges for keeping an active streak on his calorie tracking app.

Within this paragraph, we’ve described Jacob’s background, how he behaves in situations, what motivates him, and his scenarios of use for this application. This information can be very useful through the software development lifecycle and can play a key part in feature prioritization. As a developer or a PM on this project evaluating a feature or goal, I can think and ask myself, is this something that Jacob would use and base my decision upon that statement, giving me a concrete and user-research backed answer, instead of one based upon my personal assumptions.

Hopefully, this information will help you make better decisions about whatever software project you are working on and can help you build a killer product in the future!



Special thanks to Chen for the thoughtful edits + contributions to this article!

HH Design is a community around design in the context of technology.

contribute