Posted by jc-Qualitystreet on 2009/12/02
“Life is easy with personas” …
this is what I’ve been told by a client the last time I used the Personas method on an IT project.
A persona is a user-archetype, a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…
http://www.slideshare.net/toddwarfel/data-driven-personas Todd Warfel (UPA 2007)
More than a simple artifact or a one-page description, the Personas method is a user centered design technique, initiated by Alan Cooper in 1999. It provides a team with a common and shared VISION of the users of a service or product, in a very engaging format.
Why personas are relevant in Agile contexts?
In agile projects, Personas should be seen as a fantastic tool in the hands of a Product Owner team (composed by the Product Owner, a User Experience specialist, a Business Analyst…) to align the cross-functional team (dev, test …) to a shared and realistic vision of the users of the product to develop.
Personas provide you with the opportunity to integrate real User Experience all along your product development project.
Indeed, they enable the team to stay continuously focused on user primary goals and tasks by emphasizing what they want, their behavior, their needs and expectations but also their potential impediments
Another major benefit is that a specific persona can be easily linked to user stories. The “user voice format” is a good opportunity to place the personas under the spotlight. It makes your user stories more credible, more engaging. It also facilitates CONVERSATION and CONFIRMATION activities associated to each user story.
Personas are a powerful communication tool within and outside of the team. They can be used at the organization level for training, commerce or marketing activities.
How to proceed?
Option 1: Using existing Personas
Personas are ready when you start the project ; just use them !. User research was done previously, and personas are already a key element of the product vision. No need to construct them, but the Product Owner has to introduce the personas to the team when he communicates the Vision. One of the benefits of the personas is that it makes this description easier, both visual and based on storytelling. Based on that knowledge, Elevator Pitch or Product Vision exercises will be more effective with the team.
Then during the sprints, personas are associated to user stories, and help guide decisions on the Product Backlog priorization and UI design. Crucial, don’t you think ?
A classic example with Zylom (not current version):
Of course, Personas can also be used for testing activities: scenario based testing, usability testing, cognitive walkthrough …
I usually ask the team to include Personas on the Information radiator. It is an important communication act both from an internal and external perspective.
Option 2: Constructing new Personas
Personas don’t exist when the project starts.
Sprint / Iteration 0 is the perfect moment to initiate our “3 steps” process, of course in a collaborative way. This exploration sprint usually lasts from one to four weeks, depending on context.
Unfortunately a short timebox (one week for example) is a real difficulty especially for organizing workshops and planning user interviews. You’ll need to anticipate or to refine ….
Given availability issues, various impediments … “8 user interviews a week” is usually a maximum (actually it’s mine), but it gives you the opportunity to facilitate preparation workshops and to do quick stakeholders interviews in parallel.
You may understand why I like a duration of 3 or 4 weeks for a sprint 0
Here is my process to build personas:
Step 1: Preparation consists in:
- Organizing one or two workshops with a Product Owner team and various stakeholders in order to be aligned to the objectives and the methodology, to identify data sources, to determine categories of people to interview (for example the core roles)
- Informing the entire team of the process
- Collecting data from various sources including user interviews. According to me, 3 interviews by roles or categories identified is a minimum.
Step 2 Construction consists in:
- Analyzing data: from facts to behavioral variables, then from variables to patterns
- Establishing Personas skeleton
- Giving birth to the personas (storytelling and Poster) : I initiate the work (based on a template and data analysis) but I like doing this task in one or two workshops (this time with the entire team, development included). It’s fun and fosters the appropriation process.
Personas: A template
- Validating personas with various stakeholders (a qualitative validation); I only did one time quantitative validation with a large questionnaire sent to hundreds of users.
Step 3: Communication & use consists in:
- Putting the Personas on the Information Radiator
- Linking the Personas to User Stories
- Using the personas for priorization, storyboarding and wireframing activities
- Making a communication plan dedicated to the Personas
- Mobilize the entire team around the approach
- Limit the number of Personas
- Define a primary Persona
- Start the personas construction with the Product Owner team, but inform and finish it with the entire team
- Anticipate three or four workshops in the agenda
- Bring your personas to life using big cards or posters containing a name, a title / role, a script (the storytelling allowing good back in the character’s life), a picture, goals, triggers, influencers, delighters, features expected …
- Be careful on the choice of the photo: avoid celebrities, models or people you may know. remain credible.
- Don’t hesitate to communicate on your Personas: make a buzz !