UX Design Personas (2019)

UX Design Personas

UX and UI Design Personas

The Persona or Personas are critical for finding valid test participants for UX research projects. There is no single perfect time for when a Design Persona should be updated.

 

In general, Design Personas should stay consistent with the goals, needs, behaviors, and mental map of the processes most people use when engaging with your website or app.

 

There are two very broad categories of types of Design Personas that can be considered when evaluating how often to refresh. They are

  1. Consumer Design Personas
  2. Business-Based Design Personas

 

Consumer Design Personas

Consumer Design Personas are generally consumer-focused, although that’s not to say they are only associated with buying or purchasing. Anyone who uses a website or app and is not part of the organization that created it might be considered a consumer.

 

This type of Personas may need to be adjusted every year or every other year, and sometimes more frequently than every year. That’s because the consumer space can shift and adjust fairly often, based on many factors, some of which include the following:

  1. Competitive factors in the marketplace
  2. Changes in technology or usage of technology
  3. Shifting consumer needs
  4. New processes or techniques for completing tasks
  5. Changes in the mental map for how processes are completed

 

Business-Based Design Personas

The Business-Based Design Personas category is very broad. It includes anyone who may need to interact with a firm including employees, business partners, vendors, or related types of users. Typically these users require more sophisticated, in-depth systems. Generally, their domain expertise is higher than that of the Consumer Design Personas.

 

Business-Based Design Personas may need to be updated less often than Consumer Design Personas, perhaps once every other year or potentially longer, with some needing more frequent updates.

 

This is not a hard-and-fast rule, because although many businesses are in stable environments, just as many others may be in fluid environments impacted by outside forces that cause frequent shifts in the needs and processes represented by Business-Based Design Personas.

 

In general, Business-Based Design Personas reflect a somewhat more “stable” environment than do Consumer Personas. This is because businesses often have fixed and formalized approaches to how they manage processes and critical tasks.

 

Also, the people that make up a business typically follow standardized processes and procedures, which often means that what worked for a Business-Based Design Persona last year may work perfectly fine for that Persona this year, and the next.

 

There are many factors that can impact the timing of Business-Based Design Persona updates. Some of the more common ones include

  1. New competitive businesses entering the marketplace with new processes or task-flows
  2. Changes in technology or usage of technology
  3. Shifting business needs
  4. New business processes or techniques for completing tasks
  5. Changes in business users’ mental maps for how processes are completed

 

Marketing Personas

The second type of Personas is the Marketing Persona, sometimes referred to as the Buyer Persona. Marketing or Buyer Personas are somewhat similar to Design Personas but with a few very important exceptions:

  1. Marketing Personas generally do not include critical tasks.
  2. Marketing Personas are often created by using demographic data only, without the use of field research observation (contextual inquiry).

 

Marketing Personas often rely on very large sets of quantitative data based on primary or secondary research, although sometimes (sadly) the opposite is true and they are based more on opinions of internal stakeholders than on actual data.

 

When to Update Proto-Personas

Because Proto-Personas are easy to make, they are also easy to update. I have worked with firms that actively update Personas with each weekly Sprint.

 

This may seem like a lot. But if you’re building your Proto-Persona as you go along with each sprint, then updating your Proto-Persona with the key learnings and observations you have from interactions with your design is a good way to continually optimize your Proto-Persona.

 

But that’s the trap with this type of Persona

The secret with Proto-Persons is to NOT update them with newer versions of the Proto-Persona, as odd as that sounds. Instead, take the opportunity to research real people in their environment and turn those Proto-Personas into Design Personas.

 

The Design Personas, because they are based on real people in their own environment, will prove to be superior to any Proto-Persona made from indirect observations, data, and intuition.

 

Design Personas are the most useful for website and app design and optimization. That’s because they are created by observing real people in their own environment interacting with tasks similar to the critical tasks being researched for the website or app. There is no single perfect time to update a Design Persona.

 

But they should be updated. In general, Design Personas should be updated as often as necessary to stay current with the goals, needs, behaviors, and mental maps of the people who will be using your website or app.

 

There are two very broad categories of types of Design Personas that can be considered when evaluating how often to refresh:

 

Consumer Design Personas: People associated with consumers and individuals using a product or service that are not directly working for or with a firm and who typically have lower domain expertise. Business-Based Design Personas: People who are either employees or business partners with a firm and who may have a higher level of domain expertise.

 

Consumer Design Personas can generally be updated every year to every other year, depending on many variables including the product, industry, types of users, and more. Business-Based Design Personas can generally be updated every year to every two years, or perhaps longer.

 

This is because in general internally-focused applications and related critical tasks the Business-Based Design Persona will be using may not be updated as often as consumer-based applications.

 

Marketing Personas (sometimes referred to as Buyer Personas) are based on demographic, geographic, and other data sources and typically do not include actual observation of real people in their environment. These Personas are often used by marketing, advertising, and product teams when creating communications for a target audience.

 

The Marketing Personas are most useful for identifying needs, pain points, and desires of prospective customers. This helps marketing teams create the messaging used to attract awareness and engagement of the prospective customers.

 

Marketing or Buyer Personas, like Design Personas, do not have a set time for when they need to be updated. Instead, various factors can influence when a Marketing Persona should be updated, including

  1. New or modified business processes or approaches to work
  2. Changes in technology or usage of technology
  3. Shifting awareness, pain points, needs, goals, or priorities
  4. New approaches, tools, or methods of accomplishing tasks or completing goals
  5. Adjustments in the mental maps for how processes should be or are completed

 

Proto-Personas are similar to Design Personas with the major exception being Proto-Personas are not created by observing real people in their own environment.

 

Often, secondary sources of data are used to build Proto-Personas, which enables them to be created quickly; this is a useful feature for agile-based firms that require weekly sprints and design research sessions.

 

Proto-Personas are easy to update because much of the “creation” of a Proto-Persona is based on indirect data and information versus the more difficult and time-consuming work required in finding and observing real people in their environment. Some teams update their Proto-Personas with each sprint using data gathered in usability testing to optimize the Persona.

 

However, this makes Proto-Personas dangerous because, without the direct observation of real users in their own environments, it is possible to arrive at the wrong conclusions regarding why and how users may actually interact with a website or app.

 

Proto-Personas can and should be updated to true Design Personas at the earliest opportunity. Now that you know the types of Personas, it’s time to turn your attention to the most important question: why Personas matter. 

 

A Persona User-Centered Design Story

Not too long ago, I was helping an agile team create an updated version of a form to help people sign up for job interviews. The design team only had a couple of days to come up with a solution for how to design a series of interactions and screens that would allow a person to do the following:

  1. View a calendar of available interview days.
  2. Choose an available time for the interview.
  3. Enter their email to receive a confirmation and reminder.
  4. Add their scheduled interview to their personal calendar.

 

The design team was very busy contemplating several design choices for how the interactions would work when I walked into their area. The team members were evenly split on what the best choice should be for potential designs. They were unsure which one they should go with and were discussing how best to pick.

 

One group wanted the old tried-and-true method used in the past. Another group wanted to use a design based on a competitor’s design that they thought was cool. Has this little scenario played out in your workplace in the past? I’m betting it has and that this sounds familiar to you.

 

I suggested using Personas to help with the decision. We pulled up the Persona of a casual job seeker the company had previously created. The casual job seeker Persona represented a large portion of the users of the company’s systems.

 

The casual job seeker Persona was someone with limited domain expertise (or domain knowledge, meaning familiarity with the subject matter) who only occasionally needed to search for a job.

 

Because this Persona had limited knowledge of the processes, terms, and procedures for searching for jobs, the design team felt creating a very simple set of basic interactions with lots of help icons and instruction text would be best. This design was based on the old tried-and-true method the company had been using.

 

And by referring back to that Persona both groups decided they had enough information to choose a design.

 

The design team realized the basic model of interaction they had initially picked might not be the best choice. The advanced job seekers might find the tools too basic and might find the help text and icons useless or annoying.

 

Rather than providing them with a seamless, efficient experience, the basic version might have been cumbersome and inefficient for this group. The design based on the competitor’s interaction design, which was more advanced, seemed to be a better choice when considering this Persona.

 

The design team again faced a choice. One set of designs seemed to work better for casual users, the other settings seemed to work better for experienced users. How to choose?

 

Using behavioral UX data, the team noticed that although experienced job seekers were fewer in number, the number of interactions they had with the system was far greater than the number of interactions with the casual job seekers. Clearly, the design team had to ensure experienced job seekers could have a satisfactory experience with the system.

 

In the end, using both of these Personas helped the design team to realize they actually needed two paths and interactive experiences. The experience was customized to enable advanced users to use the advanced tool, which had more features and functionality.

 

For this design, new users were provided with contextually triggered help information and a quick tutorial to show them how best to use the system. They were also provided with a way to choose a basic path, but with a large “Advanced” button that would easily bring the beginner user to the advanced tool if they so desired.

 

This new design and prototype were further usability tested with actual users who represented the Personas. Based on the results of the testing, the system was further refined. Eventually, the system had a single path and single tool but with the ability to customize the experience by hiding or unhiding help text, the tutorial flow, and advanced features.

 

The moral of this story?

A tough design decision was made easier by referring back to the Personas that would be using the system. The Personas helped the design team to focus on how typical users would expect to use the system. Using Design Personas clearly helped the team focus on making decisions that would empower and enable both sets of user groups.

 

In addition, adding in some quick usability testing with real users to validate the designs enabled optimization to happen during the development process. This is true user-centered design at its best and a key reason why Personas are so helpful in the UX design process.

 

Aiding in Recruiting for Usability Testing

Another very important use for Personas is to help in identifying and recruiting people for usability testing. The Persona or Personas are critical for finding valid test participants for UX research projects.

 

The way it works it simple: you recruit people for usability testing who closely match your Persona. Testing people without the use of Personas means the usability testing data may be inaccurate.

 

That’s because the test might be with people who don’t match the typical users and thus may not share the same domain expertise, critical tasks, mental model, and related attributes of your Personas.

 

So Personas are great for finding, recruiting, and testing people who will match the typical users of your website or app. Easy peasy, right?

 

Personas and Remote Unmoderated Testing

There’s not too much that could cause UX researchers to disagree, but one item that sometimes does just that is remote unmoderated usability testing. There are many fans of this tool, but there are a few who poo-poo it.

 

The common criticism of remote unmoderated usability testing among this group is that it uses “professional testers” who may not match the Personas of typical users of a website or app.

 

This can be true, especially if the person creating the test doesn’t take the time to use the recruiting and screening tools available to ensure that the testers match the Personas.

 

For those who are familiar with remote moderated testing, you can zoom ahead to the next paragraph. Perhaps just hang out and grab some virtual pizza; I’ll be back with you in a minute.

 

For those of you unfamiliar with remote moderated usability testing, let’s chat. And for both of you, I’ll cover usability testing for UX optimization in more detail a bit later in this blog.

 

Remote unmoderated usability testing is a type of UX research in which real people test critical tasks on a website remotely, such as from their house or anywhere they have Internet access and a mobile or desktop device.

 

Typically the tester’s voice and screen interaction are recorded. It’s called unmoderated usability testing because the usability researcher is not present while the test is being conducted.

 

The way it works is testers are asked to perform certain tasks on the website or app while thinking out loud. Their screen interactions and voices are recorded while they conduct the test. After testing is complete, the researcher can view the resulting video. It’s a very handy, fast, and scalable way to conduct usability testing.

 

Testing services like Loop, TryMyUI, UserTesting, and Userlytics, among others, offer this type of remote unmoderated usability testing.

 

So why do some criticize remote unmoderated usability testing?

Because of the Personas, or to put it more precisely, the lack of ability to recruit testers who match Personas. Some researchers feel the testers who are available with these services do not match the Personas of a typical website or app user.

 

Some refer to these testers as “professional testers” because they believe the testers often test dozens or even hundreds of websites and apps.

 

In fact, most remote unmoderated usability testing services offer the ability to find, screen, and recruit testers who closely match Personas. If time and energy are put into screening and finding testers who match Personas, then remote unmoderated usability testing can be a very reliable source of UX research. It requires

  1. Knowing the Persona or Personas to be tested
  2. Creating a questionnaire or screener to identify testers who match the Persona
  3. Recruiting and testing with only those testers

 

If the researcher takes the time to do the above, then finding testers who match the Personas for remote unmoderated usability testing is no more difficult than using any other recruiting method.

 

And the Persona-matching testers who are doing the remote unmoderated usability tests will provide accurate results. So not only are Personas good for aiding in recruiting for usability testing, but they are also good for helping to settle arguments among UX researchers!

 

Personas and Scope Creep

Personas can help ensure teams are in alignment with which features and functions will be included in a website or app. This alignment can greatly help reduce scope creep or potentially negative changes in the design as the project is developed.

 

By referring back to the users via Personas and using those Personas to help focus the team on who the website or app is being created for, what functions or features the Personas need, and how the Personas typically expect a process flow to work. These important decisions can be made by referring back to the Persona and asking

“Will this Persona be able to use this tool if we include or leave out X in this design?”

 

And then there’s the opposite of scope creep minimum viable product (often called MVP) discussions. The goal with a minimum viable product is to create just enough of the functionality or features necessary for users to be able to achieve their goals, with little else in functionality available.

 

Teams use MVP to get a product into the market quickly, then to add functions and features to the product as time and resources allow.

 

MVP can be thought of as almost the reverse of scope creep. That’s because it’s the conscious decision-making going into removing functions and features to have a workable product that users find, well, useful.

 

Again, nothing beats having real users provide their input. But often there are so many smaller decisions that have to be made on a daily basis with these projects that have the design team refer to Personas when making decisions can be a great way to ensure the product will be useful to those it’s designed to help.

 

Conclusion: Why Personas Matter

Personas are critical in UX and in any analysis of UX. Some of the more important reasons focus on helping to bring users and their needs to the forefront of any discussion of functions or features. Personas can

  1. Add context to UX behavioral data
  2. Enable user-centered design
  3. Aid in recruiting for usability testing
  4. Decrease scope creep

 

Personas are critical for determining what data to review as part of a UX behavioral analysis. Personas enable user-centered design by representing users when teams do not have the time or resources to bring real users in for testing, but still, need to make decisions that impact the user experience.

 

It’s very difficult to quickly and accurately recruit for usability testing without having a Persona. Using Personas and referring to them when making screeners to recruit testers helps ensure that the results of usability testing are more accurate because the testers match the most common users (Personas) of the system.

 

Personas can help teams reduce scope creep by being the litmus test for whether a feature of the function is needed. And Personas can help when teams evaluate what an MVP experience should or should not include.

 

Now that you understand what a Persona is and why they matter so much, you’re ready to have some fun! Let’s go make a Persona, which is an amazing coincidence just happens to be the next blog of the blog! See you there.

 

How to Create a Persona

The majority of you more than likely already have Personas that you can use to help with the data you’ll be working with during the next blogs. 

 

But for the rest of you, if you do not have Personas to work with, no worries! This blog will help you create a Design Persona you can use as part of your UX analysis and optimization. So roll up your sleeves and let’s have some fun!

 

Where Does Persona Data Come From?

The primary source of data for UX Design Personas is a contextual inquiry. What is “contextual inquiry?”

Contextual inquiry is a user-centered design ethnographic research method in which the researcher finds the users on location and observes how they interact with systems in their own environment.

 

I once worked with a product team that wanted to better understand how truckers searched for jobs. The team thought about the different types of scenarios and situations where they might be able to observe truckers in their context, such as while driving or taking a break at a truck stop.

 

The product team went to a local truck stop with several questions in hand. They approached truckers and explained they were doing research to better understand how truckers think about jobs and how they look for a job.

  1. So what do you think happened?
  2. Do you think the truckers found the product team annoying?
  3. Do you think the truckers avoided the team, not wanting to answer any questions from strangers?

 

Well, it turns out the truckers were thrilled that someone wanted their opinion, and they were more than happy to give the team their thoughts. They really enjoyed being able to tell the team all about how they go about looking for jobs.

 

The product team came away with stacks of notes about the job search mental maps and habits of truckers. The information they gathered from this and other inquiries was used in the design of Personas and eventually early prototypes of the app that was developed for that market.

 

Without the contextual inquiry data gathered in the field, the Personas and resulting app might’ve taken a lot longer to get right. This is a perfect example of contextual inquiry and the process used to create a UX Design Persona.

 

So let’s go through the steps it takes to put together a contextual inquiry for Persona development and what it takes to gather appropriate information during the inquiry. If you’ve never done contextual inquiry or field research before, this may seem a little daunting but, as with anything in life, all it takes is a little practice and you’ll be an expert in no time.

 

How to Conduct Contextual Inquiry Research for UX Design Personas

So what are the steps necessary to conduct a successful contextual inquiry? How do you know what data to note when observing real users in their environment? And how do you consolidate your notes into cogent observations that design teams can use? It’s just a matter of four simple steps.

 

Step 1: Prepare

Before heading out to go talk to real people, it’s important to think about WHY you’re going out into the field and WHAT you want to observe. Ask yourself several questions:

  1. Who should I be observing?
  2. Where should I be observing them?
  3. What do I want to observe?
  4. What questions do I want to be answered?

 

Write down your thoughts and questions onto a one handy sheet paper. You can refer back to it during your sessions. It’s all right to only have a few questions when you head out. Remember the primary mission is to observe. By doing so, you may find additional interesting information that you never would have thought to ask about.

 

But by preparing and having certain questions already thought through and written out in advance, you will find your contextual inquiry sessions will be more productive and more efficient in helping you find important data for creation of Design Personas.

 

Step 2: Get Out of the Office

Some people find this a little bit intimidating, but you actually have to leave your office and go where your users are. Sometimes this can be more difficult but often it’s easier than you may at first realize.

 

It can be difficult if your users are professionals who are typically not out in the public, such as doctors, lawyers, police, judges, and other professionals. For this kind of audience, it will be necessary to do some homework and reach out through recruiters to arrange appointments to visit these people in their offices or typical locations.

 

For websites or apps that are being designed for business people, this can also prove to be a little bit difficult. I’ve found that your own network can sometimes be used to find these types of users.

 

Most of us have friends and family who work at businesses other than our own. Using that network to help you find business people for your contextual inquiry is a good way to recruit people in those environments.

 

If you are building a website or app that is applicable to the general population, then you should have no trouble going out to where people are and recruiting them for your inquiry.

 

Coffee shops, outdoor or indoor malls, parks on busy weekends: you get the idea. There are plenty of places to find people who would be willing to spend a few minutes sharing their thoughts with you.

 

As to setting up the inquiry, sometimes it’s as easy as just going to a nearby truck stop and asking people if they wouldn’t mind answering a couple of questions.

 

If your audience is more general, a great place to conduct contextual inquiry is a local coffee shop. Ask the person sitting near you for a few minutes of their time and offer them a coffee or a coffee gift card for their time.

 

A good rule of thumb for observing people in the context of their offices, homes, or other non-public locations is to arrange in advance to meet the participants. Scheduling sessions are efficient for their time as well as yours!

 

There are a variety of ways to invite people to participate in a contextual inquiry. What has worked well for me in the past is to avoid using any of the “stop” words when asking for a few moments of their time. What’s a “stop” word?

 

They are words that may invoke negative emotions or responses from your prospective contextual inquiry candidates. Words like “test” or “study” or “observation” or even “contextual inquiry” may cause people to feel uncomfortable about what you are asking them to do. Nobody likes tests, and being “observed” may feel to some people like you are asking them to become human versions of laboratory rats.

 

Instead, ask for time to learn a “little bit more” about what that person does. Explain to them you’re “hoping to get a better understanding of how they go about doing things” and “how they think about things.”

 

Explain that this information will be very helpful for the design you’re doing but that no personal information will be captured or used. You can even offer to compensate them for their time with a gift card or other incentive, just as a way of saying “thanks for your time!”

 

This next part is very important!

I’ve found people are generally more than willing to share their thoughts with you as long as they know you are not going to share their thoughts with a larger audience.

 

Of course, you will want to take all proper legal and privacy matters into consideration based on your place of employment and state/country laws regarding privacy.

 

Measures should be taken to properly protect yourself, your firm, and the participant, including having your participant sign a non-disclosure agreement and a release to use their information for your UX research.

 

Most firms, probably including yours, have these documents already and require that they are used, so it is often simply a matter of using these preexisting materials to make sure you are compliant with all of your firm’s policies.

 

If you are prearranging to meet someone at their location, have a schedule in place to coordinate your contextual inquiries. I typically send out meeting invites to confirm the session, which is a great reminder for the participant that they’ve committed some time from their schedule for you.

 

It’s also a great way for them to reach out to you if something has come up and they need to reschedule the session.

 

Prior to the session, usually a day before, I like to send out a reminder (typically an email) reconfirming the session and asking the participant to contact me if they need to reschedule.

 

And just to be sure that I will obtain the proper number of contextual inquiries, I like to schedule one or two extra sessions, knowing that it’s highly likely that one or two may end up canceling.

 

How many sessions do I schedule?

It depends on the nature of the study I’m conducting. In general, I like to observe anywhere from 5 to 10 sessions to ensure I have plenty of opportunities to identify patterns of use or similarities in mental maps for process flows.

 

Step 3: The Session

So congratulations, all your preparation has worked well and you’re now finally at your session! You remembered to bring your one sheet of questions, lots of paper to jot down your notes, and any nondisclosure or release agreements that your firm may require.

 

Here’s where a little practice will go a long way. The better you get at being friendly, open, and interested in the participant, the better your sessions will go.

 

The best tip I can give you on conducting contextual inquiries is to practice listening, observing details, probing, and asking questions, especially “why” questions. This is because you want your participant thinking aloud, explaining how they go about conducting tasks, and what their mental map is for the process they go through.

 

To get started at the beginning of a session I like to ask a few warm-up questions. You can start by thanking the person for their time. Ask them questions about their background.

 

If this is a work-related contextual inquiry, ask them about their job, why they got into it, and why they like it or don’t like it. By using warm-up questions you get to know a bit more about the person, plus you get them comfortable speaking with you.

 

If you are asking them to conduct a session on a website or an app, use the “show me” method. Ask them to show you how they do a task, and ask them to talk out loud as they go through the process of showing you.

 

During your session remember to follow these helpful guidelines:

Observe: Just listen and take notes. Let your participant do most if not all of the talking.

 

Probe: If someone says, “I like it because it’s easier for me to use,” ask “Why?” Drill down into the motivations and actions that ultimately cause satisfaction or dissatisfaction.

 

Follow Up: If your participant makes nonverbal clues like raising an eyebrow, hesitating, scratching their head, or other signs of difficulty, be sure to follow up on those clues. “Gee, I noticed you seemed to hesitate there. Can you tell me what was going on?”

 

Ask Open-Ended Questions: As a general rule of thumb, you want to only ask open-ended questions. These are questions that use words like “what,” “why,” and “how.” A good one is “Can you tell me more about…?” Try to not ask close-ended questions like “Would you…,” “Do you…,” “Is this…?”

 

Take Copious Notes: Make sure you write down lots of notes during your session. Although it may seem fresh while you’re there, you’ll find after your session that memory fades and important details may get left behind.

 

Some researchers I know use digital audio or cameras via their cell phones to record the session. As long as you have the participant’s permission to do so, and as long as your firm allows this, that’s another helpful way to make sure you don’t lose any important details.

 

Ending: At the conclusion of the session, be sure to thank the participant for their time. Make sure you provide whatever incentive you’ve agreed to give them. Ask them if it would be alright if you contact them to follow up later in case you need a bit of clarification on anything they shared.

 

Step 4: After the Session

Consolidate your notes immediately! Don’t wait! Try to consolidate your notes as soon as possible after the session because what was fresh in your memory immediately after the session will start to fade with time. Your impressions and observations are key, so don’t lose them by waiting too long.

 

Consolidate your notes by organizing them into an outline format with any potential important notes highlighted.

If you were part of a team that was doing contextual inquiries as a group, be sure to get together as a group as soon as you can to discuss your notes and observations, and review anything important that others may have noted.

 

It’s usually best to have a single set of consolidated notes to represent the observations of the group if there are more observers in the contextual inquiry than just yourself.

 

Common Attributes of UX Design Personas

Like snowflakes, no two formats for Design Personas are exactly the same across firms who use Personas. But when you’ve finished your draft Design Persona, you’ll probably see several common attributes that are shared among most Design Personas, no matter who has created them.

 

There are thousands and thousands of variations of Personas out there; just do a search for “UX Persona” in Google images to see what I mean. However, for UX design, research, and usability testing purposes, most Personas should share the same basic attributes in common (including yours):

 

Picture: Pictures are important because they personalize and humanize your Persona. They help tell the Persona’s story, so they must be an accurate visual representation of the Persona. Don’t just use any random picture. Spend time on finding and using the right picture to humanize your Persona.

  1. Critical Tasks: Typically no more than three.
  2. Scenario: Specific to the critical task or tasks, what is this Persona trying to accomplish?
  3. Background: The background for the scenario. Why is this Persona trying to accomplish a critical task?

 

Devices: What device or devices does the Persona typically use, or what third-party tools are required? This is less important now because most people can and do use multiple devices; however, it’s still important especially if you are discussing specific software or other solutions that require specific devices.

 

Domain Expertise: How educated or familiar is the Persona with the subject matter, terminology, and existing process flow? Do they have a good understanding of terminology and a solid mental map of how the process and task-flow should work, or not?

 

Environment: Where are your users when they are conducting their tasks? This is somewhat less meaningful now that the Internet is everywhere via mobile devices and tablets in coffee houses, at work, etc. Yet it’s still important to consider the environment in which the user is engaged with your website or app.

 

If you search for Personas on the Internet, you will see a huge variety in styles and types of Personas, from the very detailed to the very basic. But for UX design and research purposes, you can’t go wrong by making sure you have the above data clearly defined for your Personas.

 

The reality is Persona research is really just about observing people in their environment, asking questions, and learning more about them and the tasks they are trying to accomplish. And that is one of the beautiful things about Persona work: it brings you that much closer to the people you are designing for.

 

How to Create a Persona

Most of you already have Personas that are ready to use. But for those of you who don’t, you now know enough to be able to go out, observe people in their environment, and use your observations to put a Design Persona together.

 

Contextual inquiry is the method used to observe actual users in their environment to learn how they go about tasks, their mental map for process flows, and to ask questions and learn more about how they use existing systems.

 

It means getting out of the office and going to the places where your users are and observing them as they use the systems you are researching. It’s also a good idea to review secondary sources of information about users, always remembering they are secondary and cannot replace the contextual inquiry data.

 

The steps necessary for a successful contextual inquiry include doing the preliminary work of asking yourself questions about the purpose and goal of your sessions. During the contextual inquiry sessions, you’ll want to ask open-ended questions, listen more than talk, probe, and ask follow-up questions. You need to take copious notes!

 

After your session, you should consolidate your notes and begin looking for patterns.

  1. What do the participants share in common about their goals or desires? What are they trying to accomplish?
  2. How does the current system help them accomplish their goal or goals?
  3. What parts of the current process work well?
  4. What parts of the current process do not work well?
  5. What consistent task-flow successes, or failures, are shared among the users?
  6. What are the common pain points?
  7. What are consistent workarounds to existing problems?
  8. Is it common for people to have sticky notes with information on or near their computer to help them with their critical task? What’s on those stickies?
  9. Do people frequently rely on cheat sheets or other non-system documents to complete a task? What are they?
  10. Where are there gaps in the existing process? What are those gaps?

 

As you create your persona you’ll want to include several elements of important information including:

  1. Identify Critical Tasks: What are the top 1-3 critical tasks necessary for the end user to be successful?
  2. Document Environment of Use: Are there common places, devices, or third-party tools that are consistently used or needed?
  3. Define Domain Expertise: Is there common domain expertise, meaning familiarity with the systems, terminology, or processes?
  4. Identify Pain Points: What are the common pain points shared among users?
  5.  Create a Name: Be sure to be culturally sensitive. Focus on common names that are easy to remember and that can easily be used by your team.
  6. Find a Picture: As humans, we are visual creatures, so a face and name are important to humanize the Persona.

 

Creating Personas takes work. If you’ve not done it before, you may want to practice a few times with family and friends. Once you’ve tried a few sessions, I think you’ll agree with me that it is very rewarding to spend time with your users, learning more about them and that the time you spend will, in turn, make your design and development efforts that much better.

 

Click Test

Click tests, sometimes known as first click tests, help identify navigation and taxonomy issues with a website or app.

Click tests work by presenting the participant with an image of a website or app. The participant is asked to click where they think they would complete a particular task.

 

The location on the image where the participants click is recorded, and heat maps or related data visualizations can be produced showing where the highest number of clicks occurred.

 

Examples of click tests include asking the participant where they would click to find help, or sign-up for a service, or find information about xyz product. Because click tests can be done very quickly, and with any design image like wireframes or mockups, they are a very useful way to check navigation and labeling for new designs that are not yet live.

 

Most click test tools record where on the screen the participant clicked and how long it took for the participant to click. This data is typically presented in heatmaps where high concentrations of clicks are in hotter colors like reds or yellows and fewer concentrations of clicks are in cooler colors like greens or blues.

 

By adding questions after participants complete the click test, important WHY qualitative data can be obtained to help inform recommendations for optimizations.

 

The participant is asked to complete a task. The participant clicks where they think they would complete the action. This data is helpful for evaluating the task-flow and identifying any issues with users navigating the system and completing tasks.

 

Pros of Click Tests

  1. Click tests enable evaluations of where participants do and do not click when they are trying to accomplish tasks or navigate.
  2. Click testing is simple to set up, scalable, and fast, providing results in just a few hours.
  3. Click tests are a good way to validate a new design prior to it going live.

 

Cons of Click Tests

Click tests are subject to bias. Participants who already know a website or participants who do not match the Persona of a typical user can skew results.

Click tests are typically used for a single screen or at most a few screens deep, which means that longer task-flows requiring multiple screens may not lend themselves to a click test.

 

Because the click test image is static, a click test cannot replicate the website browsing or surfing behavior that sometimes occurs when users are trying to determine which path to take on a website.

 

When to Use Click Tests

Click tests are most useful for new websites or designs that are not yet live. Because images of wireframes or mock-ups can be used for the test, testing can occur very early in the design and development process. Using click tests early in the process can help improve conversion well before a website or app ever goes live.

 

Click tests are also useful for testing existing websites, to evaluate not only places people should be clicking but also places they should not be clicking.

 

Click testing can reveal web design treatments that are causing people to click designs that do not actually link. Knowing this can help designers improve the designs to reduce the number of wasted clicks and improve the number of good clicks. Vendors that offer online click testing tools include UsabilityHub and UserZoom.

 

Eye Tracking

Eye tracking is the process of measuring the gaze points of a participant as they are viewing a webpage or other visual object. It’s beyond the scope of this blog to get into the technical details of how eye tracking works, but a very high-level overview is helpful.

 

Eye tracking uses hardware and software to monitor and track the movements and fixations of a participant’s eyes. A fixation is when the eye momentarily stops (for only hundreds of microseconds) to gather visual information.

 

By gathering fixations and related information like saccades (the rapid movement of the eye from one fixation to the next) and scan paths (a series of saccades and fixations), the gaze points of a person’s eyes can be recorded and presented as heatmaps.

 

With eye tracking heat maps, greater areas of fixations have hotter red colors and lower areas of fixations have cooler blue or green colors. Areas with no fixations have no colors.

 

The old, kludgy, hard-to-use helmets that contained the hardware to conduct eye-tracking have given way to sophisticated glasses, and now no wearable hardware at all, to track eye movements. Eye tracking is effective for obtaining data on where people look, and sometimes just as importantly where people do NOT look.

 

Pros of Eye Tracking

  1. It provides data on what elements on a page are or are not attracting attention.
  2. The data is useful for understanding the WHY of people either clicking or not clicking elements on a page.
  3. Follow-up questions can probe to learn what elements are or are not attracting attention and why.

 

Cons of Eye Tracking

  1. Testing requires special hardware or software required to collect data.
  2. The act of observing objects, or not observing them, does not necessarily imply an action will occur, so the data may not always correlate with website activity.
  3. The use of special equipment or software may skew results by removing participants from a more normal environment.

 

When to Use Eye Tracking

  1. Eye tracking data can help you evaluate what elements may or may not be attracting several types of attention:
  2. “Good” attention points
  3. “Neutral” attention points
  4. “Bad” attention points

 

Graphics and visual design on a website can be powerful tools for capturing a visitor’s attention. This is extremely helpful when you want your visitors to know important information or direct their attention to a call to action such as a “Buy Now” button. These can be considered “good” attention points because the attention is helping the user accomplish goals.

 

However, graphics and visual design can also accidentally pull a visitor’s attention AWAY from the very information or calls to action you were hoping your visitors would see. Those items can be considered “bad” attention points. An example would be a graphic image that looks like a clickable button but is actually not clickable.

 

Preference Test

A preference test is a qualitative tool that can help determine which of several design variations participants prefer. Preference tests are helpful for providing user insight as part of a design process.

 

Preference tests work by showing several versions of a design to a participant who then selects which variation they prefer. After their choice is made, the participant typically completes several open-ended questions as follow-ups.

 

These questions can include the degree to which they prefer their choice and why they picked that choice. This is where the all-important WHY qualitative data comes from.

 

Online preference testing is a very fast and effective way to capture user-centered data because the tool is available to anyone anywhere in the world who chooses to participate in the test.

 

Pros of Preference Testing

Preference testing is useful for determining which variation of design users prefer, and why they prefer that design. Because testing is conducted online, participants can be recruited from anywhere in the world where there is Internet access and at any time.

 

Preference tests are a helpful way to resolve discussions among a design team on which design variation would be the better choice.

 

Cons of Preference Testing

Preference tests can provide inaccurate data if the participants do not match the Personas, if there are not enough participants to provide accurate data, or if the test itself is not carefully developed to exclude bias.

 

Preference tests are based on which design a participant prefers, but just because the design is preferred doesn’t necessarily mean the design will perform better. Preference tests should include the additional follow-up questions; otherwise, the choices made have no context for why the choice was made and thus no qualitative data.

 

When to Use Preference Testing

The best time to use preference testing is when there is a need to determine which of several iterations users prefer. This can occur at any time in website design or redesign project, but obviously earlier in the process is better. 

Recommend