An Introduction to Personas
Products are developed to solve problems. Well, usually. Sometimes innovation looks for a problem to solve.
People can perceive the same problem in different ways. Their approach to dealing with these problems are going to vary, and ensuring that people are receptive to a solution to their problems takes research. It takes research because the product needs to anticipate how people are going to use it.
User stories are developed to encapsulate the behavior of different people. They describe a hypothetical person in hypothetical situations. The hypothetical is meant to be grounded in realistic situations and focused on the attributes and behaviors of target audiences. The challenge is to create contrasting “personas” that behave differently and have different motivations, to ensure the product becomes refined and can address many situations.
Jeff Patton introduces how to develop personas that are the encapsulation of how you as a product developer believe your users behave. He touches on the steps in the process of developing personas, some best-practices, and pitfalls to avoid. While the examples may be software-related, the process and principles are not software-specific and are universally applicable.
“Pragmatic Personas: Putting the User back in User Stories”
Notes from Jeff Patton’s Presentation
The video is around 1 hour in length. If you want an overview of what I got out of it, you can skim my notes here.
How to evolve your product/idea
- How do you make feature choices for software that you create?
- How do you determine if they’re good choices?
Possible answers to these questions:
- The customer specifies what they want to build.
- A “user proxy” specifies what they think the user wants.
- A thought leader may dictate what the software should be — watches the industry and tries to understand what the customer needs.
- FUBU – “for us by us” design works pretty well… at least for a while….
- FMBY – “for me by you” is often used by a XP customer or Scrum product owner – can be a single person standing in for a community they don’t necessarily understand
- MSU – “making things up” process – substituting
- User-centered design – have a user in mind and be the user and figure out what you like or don’t like when thinking about the use
“Long-hand” Process of Creating Personas
Personas should be fairly rigorous things. They should be thorough and know the users.
Identify “kinds” of users – separate people out, cut up a crowd
- What kinds of people will use the application?
- Concerns might be different
- Location might be different
- Time of day might be different
- Background or profession might be different
- Finances or timeliness may be different
- College or business person or….
- “User role” describes the relationship between the person and the product
- “Roles” change constantly
Start naming types or roles – whichever seems most natural.
- Pick most relevant user types
- Isolate user types that are begin eliminated, keep them somewhere
Profile users – get data you know or assume or can harvest, then decide if you need to do research
- Generally male or female
- What are their tech/computer skills?
- What is their domain knowledge or expertise?
- For sizing – how many people are in this market?
- Pains and motivations – not what they are trying to accomplish – but what makes them happy or want to use the product?
- What bugs them or makes them mad about similar products
- What are they using the product for? – usage contexts – what other products to they use for the same activity
- Categories of info i want to collect about users
Assemble a composite – a painted picture – Personifying chooses specific information to create a tangible example
- Choosing from the possibilities the concrete examples to flesh out
- Persona is the “test” for TDD
- Give persona a name
- Give role or job title
- Give minimal and relevant demographics
- Give descriptions that describe primary activities user will be engaging in
- Give descriptions that reveal characteristics that affect product usage
- Give descriptions that reveal goals, motivations, pain points
- Give quotes in persona’s language that express goals or pain points
“The inverse of risk is knowledge”
Talk about why this matters – the impact
- What is the design impact that makes your persona relevant?
- What features are valuable to this user?
- What characteristics must the design have to be suitable for this user type?
- “design imperatives” – design principles – product principles
- Ease of use – (Don’t say “easy to use” – instead, give examples that explains what this means for this persona)
- Retention of learning
- Efficiency of interaction
- Reliability of interaction
- User satisfaction
- User convenience
- Necessity for proficiency
- Importance of accuracy
Backfill important and unknown information with facts to mitigate risk
- Give assumptions based on personas
- Identify areas where info is sparse or incomplete
Critical areas to focus on in “back-filling” knowledge is to research among people that can provide info and quotes that describe who they use products
- Don’t capture requirements – understand people!
- Don’t ask about leading questions (hypotheticals)
- Ask people to recall experiences
- Don’t ask them to speculate on how they feel about things that a product might offer
If customers suggest features, ask what it would allow them to do!