And I surprised myself when the first thing that came to mind wasn’t a technical answer. The one thing I would advise? Don’t be afraid to push back. Meaning, if you feel at the core that a design suggestion or decision is not the right one for the project and its end users there’s probably a good reason and you should let whomever is championing it know. It could be a client or even a supervisor, it doesn’t matter. Standing up for users and for your own gut instincts is your job as a design professional, don’t shirk away from that responsibility. Always be open to the possibility that you could be wrong, of course, but at least be willing to put yourself out there and be persuaded otherwise by a good, healthy design argument.

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.

However, what the separation implies is wholly incorrect. Would one not expect a dropdown to appear when clicking on the arrow, or some other dynamic, on-page behavior such as an accordion effect? Instead, nothing happens when a user clicks the arrow. It is treated as a separate part of the button, yet there is no corresponding interaction — so why is it there?

True, this isn’t a game-changing or absurdly terrible issue (there are far more egregious problems in the WordPress dashboard, all of which deserve their own posts), but it does help illustrate how small details can communicate meaning based upon context, a user’s mindset and convention. Pixels, just like pictures, can be worth a thousand words. Best to make sure those words are the right ones in order to create more cohesive and enjoyable products for our end users.

Depending upon what browser you’re using, you may have noticed some slight CSS3-based enhancements. For instance, certain areas of the site have slightly-rounded corners that only appear in Mozilla and Webkit-based browsers (I know, gettin’ crazy over here!) I plan to utilize this site as a testing ground for some more CSS3 experimentation in the near future, including @font-face now that Firefox 3.5 supports the rule alongside Safari.

Also, this site is to become an archive of all my thoughts (well, the worthwhile ones) pertaining to user experience design. The first two versions of JustinDelabar.com were nothing more than one-page portfolios, whereas this version obviously has a heavy focus on the blog content. Time to get writing! I have several posts in the pipeline, so please stay tuned for those.

I look forward to hearing your feedback. Also, don’t forget to follow me on Twitter or get in touch about any projects you’d like to discuss.