Persona Implementation

Creating whiz-bang personas is a critical step toward integrating the needs, wants, and voice of users into your design process. Then what??

The following case study illustrates steps to turn paper-based personas into personalities our designers could refer to from ideation through validation. It works well with a 4 Voices” method I also use frequently.

Here are the handouts that are also referred to contextually throughout this case study:

Narratives-filledOut (.pdf, 130KB  )
Getting to Know You Questions (.pdf, 190 KB)
SharedObservations (.PDF, 120 KB)

Preparation: Match your project-specific goals/use cases/scenarios with primary personas

Like real people, personas’ vital statistics do not change based on a given context; nor, however, should their characteristics static: personas can evolve in their needs or react different ways based on their circumstance. If your organization has a large number of personas, isolate the top three or (maximum) four primary personas targeted by your project.

Ideally, every project comes with a set of business goals to strive toward, and measure success against. While organizations should not have to create different personas for different projects, it is helpful to start envisioning how these personas will be interacting with the specific functionality you are currently designing.

Step I. Generate original “Day-in-the-Life Narratives”
Narratives-filledOut (.pdf, 130KB  )

Stories have been around forever, populated with familiar, memorable characters that grow with every telling. Personas can tap into this same human tendency if the design team is encouraged to attaching actual memories to their personas while forming new associations – all of which are “owned” by the designers. Like buying gifts, it’s easier to give something meaningful, useful or delightful to someone you know than to a mere acquaintance.

To kick the storytelling mojo into gear, I presented the team with a Day-in-the-life Narrative for each persona. My starting point for the narrative was, of course, the persona data sheet (incorporating the age, economic bracket, education and family status, etc. of each), broadly set around the part of our site on which the project was focused. I’ve provided a link to the sample below.

As many persona data sheets do, ours came with lots of facts/data/information, accompanied by a paragraph describing the essence of the person in that person’s own words. You may want to explain the difference between this blurb and the content or purpose of your narrative, by saying that the narrative represents the persona’s context presented in a snapshot in time. It’s during this time that they will benefit the most from what they are designing.

Remember that the persona’s nicknames and Needs and Goals will not be filled in until Step III. when the team comes up with them collectively.

Step II. Answer Get-to-know-you Questions about Your Personas
Getting to Know You Questions (.pdf, 190 KB)

The following attachment contains feeder questions whose answers are NOT found in either the data sheet or the narrative. In fact no actual answers even exist (yet) – other than in the imagination and prior experiences / memories of your designers.

Guide your designers to use the Narrative as a spring board, asking them to look over the questions individually and then discuss them in the group. Note that the questions ask for much more detail than the Narrative and data sheet contain, and explain that team members will have to rely on similarities between the persona and someone real in their lives to fill in the blanks. Because everyone in the group will have his or her own “person” there will probably be some negotiation across the team to flesh out the personality, reference points, and so forth of the persona.

Ideally, these conversations would take place at the same time – either in the same location, or over the phone – but with all members participating. Certain team members may take more prodding than others to suspend cynicism or to simply ask you for the answer “since you wrote the narrative …” Keep calm and carry on! The benefit of this investment in time, teamwork, and negotiation will reveal itself as the creation of an actual relationship with the personas, who now have a “history” and “personality” to which this first seed group of designers are now privy.

Step III. Compiling the Team’s Shared Observations
SharedObservations (.PDF, 120 KB)

The final step before digging into the design is for you, the researcher/facilitator, to compile the collective answers of the group. I provided them via the link below. The unveiling of the team’s answers will take place at a second meeting – that way, you have some time to digest everything, and the designers can reflect on the discussions – kind of like thinking about someone after they leave…

After reviewing all of the bullet points/shared persona attributes, it is now possible to fill in the Needs and Goals section of the Narrative (Step I.). It is also time to give the personas statements by which they could be readily identified. Even if your persona date sheets come with these already, it’s OK to add another one based on the new context. After all, as multi-dimensional creatures, it would take more than one statement to represent who we are or what we represent! These statements could be nicknames (e.g., “Robert the Taxman”), statements (Christina “all I want to do is shop”), or mantras (“when the going gets tough, the tough get going!”) – anything that will solidify a place in the team’s mind as they design for these increasingly life-like “individuals.”

Step IV. Standing in as the Persona Proxy

At this point, your work as the user researcher is pretty much done. As the designers’ excellent user experiences evolve, it’s a good idea to check in at logical points in the process to keep them honest. By that I mean it is helpful to represent or stand in as the personas that, by this point, you all know and love. Encourage the designers to ask you questions about how the personas would use certain functionality, or what else they might need.

I found that it’s as much the process as the product that makes this interactive experience successful. Short of sitting actual users in front of your team as they work, this Getting-to-Know-You exercise is one way to enable designers to engage with them as they work.