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.

“The Internet has no such organization – files are made available at random locations. To search through this chaos, we need smart tools, programs that find resources for us.”

Search engine optimization goes beyond traditional marketing and advertising by providing techniques to help a site increase its organic traffic (visitors from search engines) by increasing relevance and assisting the indexing activities of search engines. Search engines use special software to index, or record, the content of your site. Much like library patrons who find books based on title, author, or subject, the search engines find websites based on the unique words (keywords) we type in.
Relevance is a website’s connection or affinity with the keywords typed into a search engine. Search engines calculate the relevance using a number of criteria, including how often those keywords are used, where they are used, and the site’s relationship to other websites with similar keywords.

From this we can begin formulating the basis of our SEO strategy. These three foundational elements are: content, coding, and community.

Content

People are searching for something- an answer, a recipe, a service, a product. Your content must use or pertain to the keywords people are searching for. Good content is the most important thing.

Coding

Your content is supported by a scaffolding called code- the html used to structure and present your copy to end users. That scaffolding can be optimized to help search engines better index your website.

Community

Your site isn’t an island but is part of a larger community of websites that are related by mission, audience, and/or content. Being an active part of this community helps increase your relevance.

In order to know who to appeal to and how to appeal to them it’s best to start by being very clear with yourself and your website by asking:

1. What do we do?
2. Who do we do it for?
3. How do those people find us? What words might they use?

From this exercise you should begin formulating a list of your keywords- those unique words that describe what you do and how your audience will find you.

In upcoming post we’ll look at each of the three foundational items in more detail and begin drafting our strategy.

In my last posting (Usability Basics: Keep the User Informed) I talked about how the interaction with other humans differ from interactions online because of something called a feedback loop- the ability we have of constantly assessing the verbal and non-verbal communication that is happening.

Helping a user prevent errors is another way of closing that feedback loop online to create usable sites. In the physical world we come up against real boundaries that signal to us about potential problems. I don’t need messaging on the side of an eight ounce glass telling me not to put more than 8 ounces in it, otherwise I’ll have a mess- I can see how much the glass will hold. Online we’re not always privvy to such physical cues, in which case we do need assistance via messages, instant feedback, or imposed limits in order to avoid problems.

One of the most visible ways this usability principle is applied online is with creating passwords. How many times have we created a password, only to be presented with an error telling us that we didn’t do it right. Oh, you forgot to include a number, or capital letter. Preventing errors is all about being upfront with users and giving them (us!) the information we need to avoid extra clicks, extra time, more page reloads, etc. Let’s look at Drupal 6. This version uses messages to help me prevent making an error when creating a password. The site checks the password on the fly, telling us how many characters we must use, recommendations on the types of characters to use, as well as providing a “strength” meter to show us how well we’ve done before we submit the form for procesing. Nice.

Another way sites are endeavoring to help prevent errors is through the use of Ajax to validate field values and provide instant feedback. Kayak.com does a good job of helping users prevent errors. When searching for a flight I begin typing in the name of a city and the site returns a list of potential matches. This actually satisfies two usability principles- helping me to prevent errors by displaying only valid city names and ; and it relieves me from having to remember the three letter airport identifier. Good job.

Using imposed limits to help avoid errors is very common when selecting calendar dates. The Wachovia website uses text fields with the proper date format listed below the field. This is better than not having any format information, but I can still enter an improper date and submit the form. A better solution is to force the user to select a date from either a drop down list or via a calendar widget. This ensure the date is entered correctly the first time and helps the user avoid making an error.

Helping prevent errors is communicating to your site visitors about rules they must follow, boundaries they must operate within, and values that are expected to ensure they can keep moving forward. This is one important piece of creating usable websites, designing positive interactions, and keeping processes as transparent as possible.