In this chapter we'll go into the creation of a concept and then talk about how to pull out the personas implicit in the idea. Developing these personas will provide some fictitious users for your application that you reference throughout the planning process.
Throughout the book we will use images like the one below to indicate where we are in the planning process:
Genius is one percent inspiration, ninety-nine percent perspiration.
What if there were a way to share pictures with your friends using old style camera filters? What if people could rent out their rooms like a hotel? What if you could raise money for an invention online? What if there was an app to track things you needed to get done?
Having an idea for the next killer app is really the easiest part of building the next killer app. Like Edison said, it's the hard work that really makes an idea soar. Once you have an idea, breaking it down into executable steps the first part of getting it done. So don't spend too much time thinking about the idea, or debating its merits. Don't play arm chair CEO, get out and build something! See if it works!
For the examples in these next several chapters our idea is this:
What if people, that had lots of things to do, could some how record those things online! Let's call this bolt of inspiration: a "to do" application!
People are always complaining they can't organize themselves, maybe this app could help them! Our minds are racing with all the possibilities.
All right so we have an idea, and you may have your own ideas that you could think about while following along with the rest of this book. But how do we get from this fantastic concept for a product to actually building it? We'll start by fleshing out the personas.
This is the first question you should ask yourself once you have a concept. Figuring out who will actually be using your conceptualized application is critical because:
Typically organizations will engage in extensive user research, but for our purposes we can conceptualize typical users and do some simple tests to validate our ideas.
The goal of this exercise is to produce a set of biographies for what you might think are real people that would use your application. They have names, they have problems, and they will inform your application design. These little bios are what we are talking about when we refer to a persona.
Let's walk through each step of creating one or more personas for users of your application concept. We'll give examples for our awesome to-do app concept.
Pick a name that will both describe the persona and get to the root of this user. This will help you quickly distinguish between different personas. For our to-do app let's use:
Title: Soccer Mom
Personas don't have to be dull, they can be fun. This is your chance to create a person! The idea behind picking a name and a picture is to make this persona as real as possible, so when you further plan your application you are not just thinking about a generic user group, but this specific user.
We are not just interested in the stereotypical "soccer mom," but this specific one, Janet Spalding, and her wants, needs, and limitations. Don't go overboard here, but find resources that help support who this user really is.
Name: Janet Spalding
We want our personas as realistic as possible. List out several details to describe the persona demographically such as age, gender, job, education level, etc. This really helps evoke this persona in the mind of anyone that interacts with the product development process.
38 Years Old
Mother of 2 children, ages 9 and 11
Has a Masters Degree in Political Science
Works for a Government Lobby
A lot of the meat of the person comes into play in this section. Here we need to describe the motivations, goals, and tasks in which the persona engages. Try not to link it directly to your concept solution, but be honest with how this person really acts. What is important to this user in their life? What things do they need to accomplish?
Janet is a well respected lobbyist but never let's her job get in the way of taking care of her children. Her husband is often on business trips so she has to manage the house and her job.
- Ensure her kids regularly attend extracurricular activities
- Keep on top of the family finances so they can save for the kids' college fund
- Be on top of her work duties and never miss appointments
- Takes kids to and from soccer practice and school
- Runs errands, picking up groceries and similar
- Attends program meetings at work
- Generates reports
Because we are designing these personas to inform the planning of a software application, the technical environment and skill level of the user is paramount to inform the design. You certainly would design a reading application one way for a programmer with 25 years of experience and another way for a small child.
It can be helpful to discuss the user's proficiency with technology, as well as the devices that they use to access technology, and where that access occurs.
Janet is not very adept with technology, she uses the Internet all the time at work, checks email, and uses word processors. When she has a simple problem she either asks her children or the IT department. She owns and uses an iPad all the time between appointments and while on the go. She goes to so many meetings that she won't always have access to her desktop.
Coming up with something the user might actually say can be really helpful in expressing to everyone who this user is.
"I have to take the kids to practice, pick up the dog, complete these reports; I have so much to do it's overwhelming!"
Once you've come up with all the parts of the persona, they can be assembled to form a nice persona sheet with all the critical details. This is the output of this exercise and provides a one page to describe the user.
A common complaint about building personas is that it's a waste of time and that time might be better spent actually building software. It is kinda of strange that we might begin a complex software project with a little session of make-believe. But it is because of the complexity that a little play early on will help us to figure out our users and eliminate assumptions.
People have a lot of ownership over their ideas, they cherish them and they don't like information that may indicate that an idea is bad. This can result in making assumptions instead of actually doing user research. This can especially be the case when the ideas come from highly technical people, because, let's be honest, most of us are pretty out of touch with reality.
We might assume that a console based to-do app is a great idea because we would love to use it that way, but let's look at our persona. Janet just uses the Internet and can basically use her iPad. If you said "console app" to her she would not know what in the world you are talking about.
Alternatively, since we are on top of the latest trends in web design technologies, we might design a user interface that leverages lots of CSS3 and dynamic elements. But wait, maybe Janet is using government computers that are still running Internet Explorer 6! We had better ensure our app works and looks correct on older browsers.
Creating personas is a good way to have a simple document that a whole team can look at to judge various ideas and assumptions. "How would Janet respond to this? Would she know intuitively how to do that?" Remember, you are building to solve the user's problem.
In the next stage of the process we will put these personas to work! Let's have them act out realistic scenarios that involve our app concept and show how our ideas help solve their problems.