Now I’ll cover ways in which personas can be used during the project lifecycle to help guide design and content decisions. It’s an obvious statement but everything done during a project should be done to satisfy the target audience; and keeping your personas front and center will help you and your team stay focused on that goal.

Out of sight is truly out of mind; working in technology with our noses buried in our keyboards can alientate us from our user base. Once you’ve created your personas what do you do with them? My suggestion is to make sure everyone on the team has a copy or access to them. If you have a shared workspace I recommend printing them out and posting them on the wall.

Example Persona

I’ve attached an example persona (PDF) and will refer to it through the remainder of this article. This persona is one of about six created for a recent project that involved a site for sharing information about disaster risk reduction. The audience is governmental agencies, NGOs, academics, and some private industry. First, we see this persona has an ecology- we learn something about him personally and the world he lives in.

Second, it was created by the stakeholders who work with their end users. It was created based on the characteristics of people in Laslo’s particular user group (“international organization employee”). While this persona was created using tertiary information from our clients, it still does a good job of helping us understand his needs.

Using Personas

So now what do we do with Laslo? Let’s start at the beginning of the project lifecycle –Discovery. This is when we typically produce personas. I feel it’s important to create the personas first, even before documenting requirements. The reason is that Laslo will help to inform how we approach the requirements just based on our awareness of him. Often times we can ask really good questions of the stakeholders when gathering requirements when we know more about who the requirement will satisfy.

The CivicActions creative team is revising our process to fit even better within an agile development process. We’re moving away from creating highly detailed requirements documentation in favor of simpler “user stories” that capture much of the same information, but more quickly and from the end users’ perspectives. These user stories can also be included as part of the persona document. In the example you can see those “What actions…” questions at the bottom. Those could be developed into more stories. And if those user stories change for any reason we can refer to the persona information to ensure there won’t be any problems or conflicts with the changes.

During the design phase the IA creates wireframes and a visual designer may begin rough comps. The personas are used to validate this work, regardless of the fidelity of artifacts (wireframes or comps) at this stage. We can use the persona to ask questions of our work, for example: Does the persona have any physical differences (e.g. vision impairment) that might make this design challenging? does the persona have any technical challenges (e.g. low bandwidth connection) that might make this solution cumbersome?

Personas and QA

The next place personas become valuable is during QA. Since the personas will dictate the user stories the QA team can use the stories to develop their tests. And if usability testing is planned then the personas can serve as a model for the types of participants that need to be recruited and the stories will shape the test scenarios used during the study.

Personas & SEO

Personas can be useful even beyond the design phase. Personas can be used to inform your search engine optimization (SEO) strategy. We have documented ecological information for each persona along with their goals (user stories). For each persona you may want to think about how he or she might search for you.

Using the example persona of Laslo who works for an international organization, what words would he use to search for disaster recovery information? How are those keywords and phrases different from another persona, Helen, who works for a congressman in Iowa?

Also consider your personas in different contexts. What might Laslo search for during a normal work day? What might he search for after a major natural disaster when he needs to quickly find information for a press conference?

Personas & Strategy

After a site initially launches it’s easy to put away the personas and focus on maintenance and iterative improvements. But if these personas are your audience, how do you expect them to change over time? At the very least the audience will age. If the site is for a group of users who are in their late teens then what is the strategy for the site over the next five years, knowing the audience won’t all be teens forever?

What do the people that fit our personas, do with their lives? Will they marry in the next few years? Will they pursue additional education? Our strategies should take into account how the lives of our audience change so we can anticipate and prepare for their needs if we plan on serving them in the future.

This is another good place to consider context. If the persona finds himself or herself in a different context (“married,” “laid off,” “hungry”) will that affect how the site is used or the services you can potentially offer?

In this age of social networking it can be helpful to think about the social graph of our personas: who do they know, how do they connect and relate to these other poeple? Of those potential connections, who among them could also benefit from what we’re building? Could their influence affect how our persona interacts with our site?

The more often we can consider our personas during the process then the more we’re all practicing user centered design. And isn’t that really the goal? Designing websites around their intended users.

Personas: Who Makes This Stuff Up?

While the information we write about a particular persona is fictional it must have its basis in reality. If we’re building a new website then we should have some idea about the target audience. In a perfect world the Information Architects, User Experience Designers, or other user-focused team members would be able to talk to some of the end users (or potential end users). There are several structured methods for collecting information about end users: contextual interviews, task analysis, focus groups, and surveys.

Contextual Interviews

Contextual interviews are the most time intensive and costly. A contextual interview is conducted in the space where the end user actually works or lives. The UX professional basically shadows the person to understand what she is doing and also observes the “context” (or environment) in which she carries out her tasks. For example, if we were designing an intranet site for human resources professionals to record employee data we would literally sit in the office of an HR person, watch him process employee data, note where paper notes were used, when information was entered into or pulled from electronic records, when sticky notes were used to bridge information gaps, what he reached for when cross referencing records, etc.

The output of a contextual interview is copious notes that are synthesized into an affinity diagram, basically each note or piece of information is transposed onto sticky notes of various colors, put onto a wall and then grouped by the UX team. From these groups of sticky notes patterns, workflows, and associations are created that help us to understand what an HR person needs when working with employee data.

Task Analysis

A task analysis is much like a contextual interview, except it’s not concerned about the environment, only the actual task at hand. In the example of the HR person, a UX professional would note each step he would take when creating a new employee record. Steps are broken down into smaller and smaller pieces so that it can be re-created in the new intranet site.

Focus Groups

Focus groups are more general and collect the opinions and ideas of a group of people. We may ask six HR professionals to convene and proceed to ask them questions about their jobs, what they need in an intranet site, and what could make their jobs easier. The danger with strictly oral methods of information collection is that there is often a gap between what someone actually does and how they describe it.

Surveys

Surveys are often easy and inexpensive to administer. There are many free or inexpensive web-based tools available for creating surveys. Writing survey questions should be approached carefully. Questions should be clear, free of any language that could bias the respondent, and specific enough to elicit a clear answer. Besides the pitfall of low response rate we again have the challenge of people translating their real world experiences and feelings into a series of multiple choice answers. Surveys are best at collecting empirical data: gender, age, salary, education, etc.

In any one of these situations the UX professional needs to be as careful as a courtroom lawyer in how questions and statements are phrased. People want to be seen a smart, hardworking, and agreeable and we don’t want our questions to lead someone into answering in a way that obscures information that could otherwise be valuable for our project.

Creating Personas on a Shoe-String

Often times because of tight schedules and limited budgets these activities aren’t included in projects and teams are expected to hit the ground running. In lieu of talking to actual people an IA/UX consultant may need to find alternate sources of information. For example, documented user feedback from website support forms, customer call center records, or even talking to sales people who have had customer contact.

Alternate Information and Data Sources

If there is an existing website there may be emails or contact form submissions that contain bits and pieces of user feedback. This may end up in different departments (tech support, marketing, sales, etc.) Be sure to contact anyone in the company you can to ask for this kind of user feedback.

If the company has a call center it may be possible to get a print out of customer call records or even talk to some call agents personally. I’ve dealt with some who knew exactly what customers liked and didn’t like and were quite frank in letting me know. These are the people on the front line and they can be a valuable source of information.

Salespeople also know the good, the bad, and the ugly. They, however, may internalize how customers feel about the company and thus aren’t always forthright with that information, feeling as though it could be a reflection on them. I’ve found that there usually are a few salespeople who are willing to share what they know because of their commitment to really serving their customers, but you might have to dig.

And If All Else Fails…

There may be times when even third-hand information is not available. Then we need to either press the client for any details they can think of about the target audience, or simply use our imaginations. As creative professionals we can also call upon what we know about people like our target audience. However, we want to be careful not to create stereotypes, which are a demeaning caricature of someone belonging to group. Our target audience might include middle aged white men, but that doesn’t mean our persona has to wear JCrew, work as an accountant, and live in the suburbs. Our personas should have depth, a unique perspective, and opinions that reflect his individuality.

In <a href=”http://www.softerwareconsulting.com/2009/02/04/how-to-create-effective-personas-part-1/”>Part 1</a> we talked about what makes a good persona, in this post we talked about how to get that information, and in Part 3 we’ll look at what we do with personas once we’ve created them.

I don’t know how to say it any more plainly than this: Creating personas are important.

The persona is so important because it affects so many other pieces of the project- discovery, design, QA, and even search engine optimization. A persona is the answer to the question “who are we doing all this work for?”. What you know about him or her will inform your choices about how your site will be found, how it will look and how it will function. Budgeting for personas is always time and money well spent.

Components of a Good Persona

Personas can take many different forms and I think the best personas contain at least these three things:

• A persona has a name. Don’t confuse personas with “user roles” or categories. “Authenticated User” is not a persona. “Ralph Perez” is. The persona will fit into one of your user roles and he will exhibit other traits and abilities beyond that role.
• A persona has a photo. Your persona is a human- put a face to the name and you’ll be better able to empathize with him or her. I use istockphoto.com for inexpensive photo images (I can usually find something for about $1).
• A persona has an ecology. The demographic data you specify for your persona will also, by inference, provide meta-data about the world he or she lives in. Take the time to desribe this world. Creating a basic story that includes education, family life, work, interests/hobbies, and physical characteristics (including handicaps) adds more dimension to the character and gives us more options when making creative choices. It’s those other qualities that may influence his behavior when searcing for or using the site.

Personas Have Opions- Just Ask Them!

In addition to these three pieces you can also optionally include a few questions to ask each persona. I’ve used this technique and it’s really helpful. One set of questions can be general and used for getting a deeper understanding of the persona. These can include things like:
- What are this Ralphs’s value words?
- What is this Ralph’s life mantra?
- What are Ralph’s unspoken questions about this website?
- What does Ralph expect from using this website?

Additionally we also asked some project-specific questions. For example:
- What is the meaning of money to Ralph?
- What are Ralph’s challenges around money?
- How does Ralph define value?
- Who else needs buy-in before Ralph will use this payment system?

These questions are valuable because they help us make better descisions around layout and design, can help us verify navigation, and even inform our marketing and SEO efforts.

How Many Personas Do I Need?

You’ll probably have anywhere from one to four or five personas for your project. If think you have eight then I would suggest revisiting your list of your user types and see if any of them could potentially be merged. If you do have that many then perhaps you’re actually trying to satisfy two *separate* audiences, in which case you may need to define two separate sites or interfaces.

In our next post we’ll look at an actual person and see how it can be used during the project lifecycle.

In my last posting Persuasion Architecture Part 1 I talked about the theory behind this idea. Namely, a site visitor needs resolution and answers to questions before following down a path and the better we can address those issues the more likely we can nudge our visitor along (towards our conversion point). We begin our work by getting clear about where we want our site visitor to end up- what does a conversion look like? A paid donation? A completed registration? A purchased book?When we know where we want the visitor to end up then we can anticipate the questions a visitor might have along that path.

The Eisenberg’s add an intersting spin to this by factoring in the personality type of the person we’re trying to persuade. Like most systems that attempt to describe human nature their system also uses four categories: the competitive, methodical, spontaneous, and humanistic. These types run spectrum around the use of time, attitude, and desires.

Competitive: driven, busy and wants the benefits: what can this do for me (i.e. what will it get me)?

Methodical: driven, deliberate and wants the mechanics: how will this help me (i.e. how does it work)?

Spontaneous: easy going, engaging and wants acceptance: why will this make me better (i.e. why are these features important)?

Humanistic: easy going, diffuse and wants to belong: who else has done/used this (i.e. who will I be like)?

Now we can begin sketching out how one of these types moves along a path of links to end up at the conversion point. Let’s use the example of making an online donation; our conversion point is the “Thank you for donating” page. A great many sites who take donations simply have a link:

Donate

If you received a plain white note in the mail and it said “marry me”- would you? Of course, the risks in marriage are more substantial than simply clicking a link in error and my point is that- wouldn’t be better to know a little more about what I’m getting myself into before I commit?

Before our visitor commits to the Donate link (a Conversion Beacon in PA-speak) he or she may need to have a few questions answered. The Eisenberg’s call these Points of Resolution. And it’s at these points that we use the four types and their needs to anticipate those questions. This process is meant to mirror the traditional sales process and in our case, since we can’t speak to this visitor face to face and sell him or her on donating (or registering, buying, subscribing, posting, etc.) our site needs to antipcate those things that might need to be resolved before the visitor continues and donates, registers, or buys.

Dan, a competitive type will see the Donate and link and (perhaps) need to have the following points of resolution answered:
- What credit cards does the site accept?
- What happens to the money?
- What is the process for making a donation?

Some of these can be presented as links- for example, “How do I donate online?” that links to a brief explanation of how the online process works. Others, like “what happens to the money” can be preseted as short text near the Conversion Beacon (read: Near the donate block there is a block that contains a short teaser about the charities supported by these donations). Small icons of credit cards can answer Dan’s first question. In a few seconds these questions can be resolved and the visitor feels more confident in making his or choice to donate.

This methodology has been used traditionally in ecommerce type sites because the monetary benefits can easily be measured (and are- the Eisenberg’s have some great case studies with hard numbers backing up their methods). Aside from any capitalistic gains, it certainly fits nicely within the desire for more humane interfaces since it provides the end user with more information to make better choices for himself or herself.

Yesterday I walked into a local retailer and found this widget I’d heard about. I was considering buying it, but had a few questions for the saleman, so I went over to him and asked “Can you tell me more about this widget, like how long will it last between charges?”
“Buy it now,” he replied.
“Well, I might, but I have a few questions. Besides battery life, what kind of warranty does it come with?”
“Buy it now,” he said.
I pursed my lips, “Yeah…I’m thinking about it but I need to know how this will work with my computer. Are the cables included?”
“But it now,” he smiled.
I stuffed my hands into my pocket to keep from strangling him and sharply turned around and left the store.

Okay, while that didn’t really happen to me yesterday this kind of scenario does happen to folks every day on the web. Many sites are created under the assumptions that visitors don’t read text, can’t navigate, and will buy/register/forward/embed/link/invite/rate/read/share/upload/select/vote/etc. simply because we provide a link for doing such. Sure, some of these actions are low risk, but some of them- given the amount of information we encounter each day, our available time and money, and personal goals at the moment- require us to make choices.

Persuasion Architecture (developed by the Eisenberg brothers at Future Now, Inc.) overlays the traditional sales process (prospecting, initial contact, present, handle objection, and close) onto the web. Many sites do a good job of trying to close the deal (Buy Now) but a poor job of handling objections- the critical step before the close.

The name “persuasion architecture” is spin on traditional “information architecture,” which is concerned with how information is organized and accessed on a website.
The concept behind persuasion architecture simply implies that there is information that will help someone make a choice and that information must be availale to satisfy any objections before the choice is made (and hopefully the choice we want the person to make). In the traditional retail situation a salesperson is available to handle a buyer’s objections, answer questions, and give the buyer a warm fuzzy that he or she is indeed making the right choice. Had the salesperson in my store example above simply and succinctly answered my questions the likelihood of buying the widget would have increased greatly.

All of us have questions when using the web- from the simple question “where will this link take me if I click it? (and is it worth the risk)” to more complicated ones like, “If I order this $500 stereo component online can I return it? If so, how? Who else liked this component? How will this component interface with my existing system? What cables will I need?” A site that can answer my questions, overcome my objections and instill confidence that I am making the right choice is the site that will close the sale, gain a registration, or encourage me to take action.

Next week in Part 2 of Persuasion Architecture we’ll look at the questions different types of people generally have before making a decision. These can be directly tied to our site’s personae to ensure we’re speaking to the right audience.