Developing Personas

Now that Kelly and Pete have a great idea that they want to build, we'll move into the Persona creation part of the process. This will help them hone in who uses the application and focus on their needs. Feel free to review the Concept to Personas chapter in the first section of the book.

  • Kelly: So Pete, tell me, who is actually gonna use this MyFlix application?
  • Pete: Everyone! Who wouldn't want to watch their movies instantly on-line?
  • Kelly: Well "everyone," is a little broad. 7 billion people? Babies? People without computers?
  • Pete: Come on Kelly, you know what I mean, everyone like us, people that watch movies, you know, with computers, of course!
  • Kelly: Yeah Pete, I know what you mean, but we have a good relationship, you might not always be working with people that "get it," you assumed I knew what you were talking about. And you know what happens when you assume?
  • Pete: Yeah, you make an...
  • Kelly: Yeah -- Well the point is, we need to figure out a really clear idea of who will use our application so we can build the best application for them, think of apps you've used that you really enjoy using, where you do things naturally. These interactions happen because people have put a lot of work into identifying who you are and designing for you.
  • Pete: I'd rather just get started coding some things and make it look good later on...
  • Kelly: Pete, it's not just about things "looking good," everything about the end user informs your programming decisions, you know what they say about putting lipstick on a pig?! If we don't understand our users, it will show through our code, and our application might not be successful. Here I have an example for you.
  • Pete: Ok...
  • Kelly: You like the app you use for your blog right?
  • Pete: Oh yeah! It's super simple to use, I can just write my posts in markdown, and get them out quickly.
  • Kelly: Yeah that's great, you like markdown right, as a programmer it makes sense to you to write this way?
  • Pete: Sure does!
  • Kelly: Cool, well we should have your Grandma use it to write her flower arrangement blog too then!
  • Pete: Yeah right! My grandma can barely use Google, she wouldn't get Markdown at all!
  • Kelly: So you're saying that one app works great for you, but wouldn't work at all for a different type of user?
  • Pete: Uh... Yeah, oh. I get it. I see now, so if we were designing blog software we'd want to know if it was programmers or grandmas using it?
  • Kelly: Yeah sort of, once we know the users, through and through, we can make informed decisions about functionality, features, and the importance of certain features. Otherwise we are just making lots of assumptions. You might have assumed, as a programmer, that Markdown is a critical feature for blogging software, but if 90% of the users will be older, less experienced users, then they won't even care.
  • Pete: Ah, all right, I see what you are talking about, so how do we figure out the MyFlix users?

Start With The User

As we first discussed in the Persona chapter, understanding your user is critical to developing a useful application, that solves a user's problem without getting bogged down in "nice-to-haves." We just saw how assumptions can creep in everywhere, and our personal interests and biases can subtly inform our decisions about product direction.

Sometimes the user is the developer, but often the user is a different type of persona. Be sure to step back and understand your real user base.

  • Kelly: Ok, let's try that again, who uses MyFlix?
  • Pete: Well, I'd say that it would be people similar to us that enjoy movies, they'd have computers, be pretty familiar with using web applications to get what they want, have disposable income to spend on entertainment, don't like to wait around... they are probably young and hip, I know my grandma would get confused by this, she still uses VHS!
  • Kelly: Good Pete, that is a lot better, so one of our users is someone that consumes the content through our application, why don't we call them the content consumer?
  • Pete: Yeah that works.
  • Kelly: Anyone else use our app?
  • Pete: Nah I think that's it, people that want to watch stuff online, right?
  • Kelly: Well how do the movies get on the website?
  • Pete: We'll put them there once we are allowed to distribute them.
  • Kelly: How do we do that?
  • Pete: I don't know, some admin interface or something, or just manually put them on a server.
  • Kelly: Well that sounds like another type of user to me, cause uploading and managing content is sure different from simply consuming it. Sounds like we should also think about the idea of an application administrator?
  • Pete: Ah yeah, you're right, we would need something like that. We'll also need a different user to write professional reviews of the movies, a "movie reviewer!"
  • Kelly: Pete, good job, you are thinking in the right direction, but before we add a whole other user type, remember, our main goal is to make an application that let's people watch movies online, it might be a little soon to talk about reviews.
  • Pete: Yeah, but we are gonna add it anyway, so why not think about it?
  • Kelly: It's always important to think about the ways the application can evolve, but remember, we don't want to do any more work than we need to validate our core concept. I once worked on a big project to add search to an application, and there were all these "important features," but you know what we found after the release and recording peoples' mouse movements?
  • Pete: What?
  • Kelly: Only 8% of users even clicked the search box! And only 1% used the advance search features that the development team spent nights getting to work just right! I totally believe that reviews will be important for our app, but let's wait until our customers drive that need.
  • Pete: Wow, that's crazy, why didn't anyone use it, it must have been built wrong or something?
  • Kelly: Nope, it looked amazing, and there wasn't a bug in the whole process, the problem was that the guy in charge was so sure that users would want these features he didn't bother to do any tests or research, and used his political clout to get the project green-lighted. It's not always that easy, you can't go to investors and say "we need a million dollars because I am 100% sure this will work!" Maybe if you are Steve Jobs you can, but start-ups are usually rich on optimism and passion and poor on data and validations.
  • Pete: Ok, let's just focus on those two user types for now.
  • Kelly: Great, give me a few minutes to sketch out something called a persona.

The Content Consumer

It looks like Pete is always getting ahead of himself. Good thing Kelly is there to keep him focused on the task at hand. There will always be the temptation implementing ideas that seem good. Having discussed the basics of their application with users, they are ready to put pen to paper and create actionable personas. Let's see what Kelly has come up with:

  • Kelly: Pete, check this out.
  • Pete: Cool, who is that, a new developer to work on MyFlix?
  • Kelly: Ha ha ha, no Pete, this is Blake our content consumer persona!
  • Pete: Yeah you mentioned persona, but is that a real person? What is it?
  • Kelly: No I made him up, based on our brief discussion of the types of users that would user our application.
  • Pete: This seems kinda detailed, why have a picture and age and all this stuff?
  • Kelly: We'll isn't it easier to identify him, can you picture Blake in your head when you think of using the app?
  • Pete: Yeah sort of, I guess it sticks in my mind, like "what would Blake want?"
  • Kelly: There you go, exactly, having all this detail paints a solid picture for us, we stop thinking about grey, boring "users" and start thinking of real people. Can you tell me something about Blake that would make you build the application in a certain way?
  • Pete: Hmm... Well... it says that he likes following certain shows his friends watch, so maybe when we build the app, we can have a way to follow other users... and have a box that shows "what your friends are watching?"
  • Kelly: Very good Pete! We still have a lot of work to do before we specify exact features like that, but you are on it, knowing about the user helps you make informed decisions about the functionality of the application.
  • Pete: Cool, but what about the other user type, where's the persona for that person?
  • Kelly: We'll that's your job Pete, let's work through it together.

The Application Administrator

  • Pete: Oh boy, ok I'll do my best, how do we start?
  • Kelly: We'll let's start simple, with a title, find a picture and sketch some rough demographic details... who is this person?
  • Pete: Um, this is hard, how should I know what kind of administrators we'll hire?
  • Kelly: Yeah, Pete, it is hard, sometimes people will go out and interview tons of people and distill down different types and build the personas from this research, then they go back out and confirm their personas are a good match. We won't go that far, but think Pete, how would you go about getting an administrator?
  • Pete: Well, let's see, if they are going to be managing content on the site, they would probably need a good technical skill, but they won't need to be a programmer, I'd want someone who is detail oriented, does that work?
  • Kelly: Yeah, we are lucky in this case, because our admin is an internal user, and we basically get to pick who we want. We won't always have that luxury. If you are ever unsure that means you need more information, or you need to experiment.
  • Pete: What like actually put out a job posting for our admin user and see what kind of people show up?
  • Kelly: You got it! That is one kind of way to validate our thinking, you have a better idea now of what this persona might be like?
  • Pete: Yeah, let's call her Carrie, here's a picture I pulled off the Internet, I'd think she'd be maybe a little older than us, bachelor's degree, single, maybe she would quit a job at a movie office to work with us?
  • Kelly: Ok, add that to our template.

  • Pete: Here we go...
  • Kelly: Yeah that's looking good, now come up with a quote that really sums up this user.
  • Pete: How about: "When those episodes are approved, I need the files ASAP so I can upload them to the site!"
  • Kelly: Yeah that sounds like it should work, it sounds like something a real human would say. So what is this user's motivations or goals?
  • Pete: They want to upload movies!
  • Kelly: That's their motivation?
  • Pete: Yeah?
  • Kelly: Well, why do they want to upload movies?
  • Pete: Uh, cause that's what we hired her to do?
  • Kelly: Ok, well why did we hire her?
  • Pete: Kelly! To upload movies!
  • Kelly: Pete! Come on... but why did we decide to hire her!?
  • Pete: Because she's a good person!? I don't know, because she always does her work on time? Because she is methodical, and never misses a deadline, because she is the best person for the job!?
  • Kelly: All right good, so what is this user's motivation?
  • Pete: She wants the customer to enjoy using her app, so that she can be successful at her job. Because of this, she'd like to upload the movies in a timely fashion... so I guess we should design the application to make her job really easy?
  • Kelly: Well done. Remember, humans aren't just robots that will do whatever our app tells them to, they have motivations, and higher order goals, and when we help them achieve those goals with our application, they will enjoy using it more and more. Why don't you add a summary of Carrie, this quote, and her goals and tasks to the work sheet.

  • Kelly: Ok Well done, finally let's add some details about the environment and technical abilities.
  • Pete: She probably knows how to use a computer and other applications, seems simple enough.
  • Kelly: Sorry Pete, but it's not that simple, maybe in this case it is, but remember not all users are alike. The Technology environment they find themselves in can really impact how they interact with an application. I have another war story for you.
  • Pete: Oh here we go...
  • Kelly: Just listen. I was working on a project that was building an application to let government workers better analyze certain data in their administration. It was a really good looking concept, the designer they had was amazing, and when we started building the app, it was beautiful, it used every cutting edge feature of HTML and CSS, and was very intuitive to use. You know what the problem was?
  • Pete: It didn't work in IE?
  • Kelly: You got it Pete, the whole app had been built in a fantasy world of high performance Macs running Google Chrome, and when the app was finally run on the ancient government computers with an older version of IE, it looked horrible, and half the features didn't work. If only the team had taken the time to assess the technology environment of the end user, they might have designed for them first, instead of for themselves.
  • Pete: Oh yeah, I get it, ok, I added all the technical details, what do you think?

  • Kelly: Great Pete, looks like we got two solid personas that represent two key user roles of the application. We can use these to accurately describe the features we will build for the app. What do you think?
  • Pete: I think that was helpful, can we get started on building yet?
  • Kelly: Not so fast, we still aren't 100% sure of what to build and in what order.
  • Pete: And I suppose you have some other activity to figure that out?
  • Kelly: I do, but why the attitude?
  • Pete: I just don't understand why we have to do all this stuff before getting started, I mean isn't Agile development about just doing things fast, fixing things later?
  • Kelly: I'm curious what you mean by "getting started?"
  • Pete: You know, coding!
  • Kelly: Well, Pete, I'm sorry to inform you that we have already started building our application, and these steps can be just as important, if not more important than coding. Think about it, how much work is done before building a house? You've got to get plans approved, drawn up, and so forth. People don't just start digging holes and pouring cement! In fact, because you can build most of a house on a computer first, you can make changes to the design well before it becomes really costly to do so.
  • Pete: So you are saying this persona stuff is like building a house on a computer first?
  • Kelly: Kinda. Agile is about feedback loops, not just doing things fast, it's about doing a little work, so we can learn something, and then adapting to that new information quickly. It really didn't take us that long to come up with these personas but we learned a whole bunch about our application users. If we had wanted to make a change or throw something out and start over, the only cost would be several minutes and a few pages of paper.
  • Pete: Ok, I see your point, I probably wouldn't have gotten a whole bunch of things programmed in the time it took to do this, I do want to use my time efficiently. So what's next?

The Persona-Role Relationship

One important thing to note about the development of the MyFlix personas in this chapter is that they are closely tied to the idea of "application roles." Sometimes you may have many personas for one role, but that can get confusing. For now, it's best to think about a persona as the typical user that will engage with the app in a certain way.

As we have shown, we have one persona that consumes content and another persona that administrates the application. Once we get into the next parts of the examples, and particularly the story writing, we will directly refer to each of these personas, as they drive the particulars of their respective features.

If you do find yourself thinking of two wildly different types of people that have the same role (like, for example older and younger users of a dating app), it's best to focus on a primary persona early on. Focus your efforts on one thing, and you can always add to it later.

Now let's see how our team will handle the building out of the scenarios!