User personas have become more prevalent in the design community over the last year or so, no longer just relegated to highly funded, data-driven projects, which is partially a reaction to shrinking budgets and shorter timelines. Anyone can develop effective personas that help place the user at the center of website experiences that lie in the sweet spot between customer needs and business objectives, even when money and time are tight. All that is needed is the right approach, including talking to the right people and asking the right questions early. In this post I’ll be discussing what personas are, the value they bring to design projects, and how to best develop them for maximum effectiveness when resources and timelines are constricted.

For those unfamiliar, personas are imaginary constructs of website users that can encapsulate everything from demographic information and emotional states to on-site goals. They can have made-up names and/or titles (eg, “Bob, the Paranoid Checking Account Holder”) that can serve as a point of reference in design conversations (”How would Bob approach and interact with this bill payment screen?”). At their core, personas are created to help designers, developers and stakeholders step outside of their own worldviews to see problems from an end user’s perspective. Personas can be used as a filter for features, as well, to ensure something is an absolute necessity before blowing the budget on crazy widgets that might provide little value in the end (”Does Mary really need to see a news ticker on her account summary page?”)

For personas to be effective they obviously need to be based around accurate information. In smaller projects that information is most likely going to come directly from the project stakeholders. In many cases it might be difficult or impossible to get a chance to interview actual users in a target demographic, so it is extremely important to interview those who have close contact with customers/end users. The first step of most design projects (at least successful ones) is a strategy meeting where business objectives are discussed. During this initial meeting, insist that whomever in the organization has the closest contact with end users–perhaps someone from customer service–is involved in the discussion. In many cases, depending on the size of company you’re working with, the lead stakeholder may be the person with the most information on the project’s end users. Every project is different, but there are some base questions you can ask about users to get the conversation going. Here are some that I find effective:

• What are some statements or questions you hear over and over from first time customers?
• What about your business or product are people confused about?
• What frustrates your customers about your type of product/service?
• What makes your customers take the next step to contact or purchase?

You will most likely have a ton of notes after this interview process, so the task then turns to taking all of that information and creating personas that aid the design process.

The first decision you’ll have to make is how many personas the project needs. It might seem most obvious to create personas based around demographic or other surface-level differences between end users, which, depending on the project, could be effective. However, I suggest breaking personas down based upon goals, especially when demographic or ethnographic information is limited. By understanding differences in motivations and goals it becomes much simpler to decide on a base number of personas. A general rule of thumb from my experience is that more than three personas tends to dilute the overall goals of the site–you might simply be trying to do too much and failing to satisfy anyone in the process. If more than three personas makes sense for your project, which could certainly happen, it is best to prioritize the personas based on shared criteria (effect on the bottom-line is my favorite) to decide which three to include.

I’ll use Vacation Rental Station, a vacation rental web application we recently launched at Rise for a client, as an example of how personas were utilized in a real-world project. The budget and timeline for the project were fixed, so the strategy process and persona development had to be quick but still provide a workable direction for the project’s success. We conducted our initial meeting with the client where we learned about the site’s objectives and users goals and motivations. I settled on two personas centered around two separate goals — finding a vacation rental property and posting a vacation rental property. And, thus, Mary Williams, the Vacation Rental Seeker and Jack Smith, the Rental Property Owner, were born.

For these quick and practical personas I followed an approach I learned from Dan Brown and his excellent book Communicating Design (highly recommended). Each persona is broken down into four areas:

• Motivations
  Can be considered the user’s overarching goals, the reasons behind why they’ve chosen to spend time interacting with your site. (eg, “Find a vacation rental within budget and availability range.”)
• Scenarios
  Represent the user’s context, the hows and whys of the site visit. These are meant to help the project team and stakeholders better understand a user’s mindset while interacting with the site. (eg, “Mary has a week of vacation she’s planning and only a couple windows of opportunity in which to use it.”)
• Website Features
  Content and/or functionality that directly addresses a user’s motivations/goals. This is where ideas for website structure and functionality begin to really develop — features are developed to address needs, instead of features being developed for the sake of having a lot of features. (eg, “Advanced search and sorting options for vacation rentals.”)
• Behaviors
  Interactions that help users meet their goals, the connections between motivation and features. (eg, “Sorts and filters results with Ajax-powered sliders and links on results pages.”)

Each persona can have several motivations and scenarios, and each motivation and scenario can have several features and behaviors. You can view a PDF of the rental-seeker persona for the Vacation Rental Station project for greater understanding. You can also view the final result of the search page mentioned in Mary’s first Motivation and Scenario to see how the information was put into practice.

User personas are just one of many tools that can be found useful in design processes. I do not claim they are perfect or that they are for everyone. Although, when used in concert with other tools, including competition analyses, usability testing, and a myriad of other approaches, they can provide greater clarity and shared understanding of design problems and solutions.

This entry was posted on Saturday, July 25th, 2009 at 2:03 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.