At Blink we create behavioral profiles, along with key scenarios, to characterize users and usage.
If you have been around system design in the past several years, you have no doubt encountered personas: bright, whole, wholesome (and entirely fictional) users complete with family members, college degrees, cars, and recreational interests.
Personas are created to help project team members understand and empathize with users. This, in turn, should help drive better design decisions—creating features that will do the best job possible in meeting user needs. Unfortunately, there is a temptation with personas to focus on the personalizing details, giving less emphasis to the behavioral characteristics and motivations that should drive system design. Where this happens, personas have little value.
At Blink we prefer to characterize users in terms of behavioral profiles, devoid of personalizing details. But we aren’t opposed to telling a story to get project stakeholders to empathize with users—the difference is we accomplish this by using contextual details in key scenarios.
User Research is Key
The starting point for our process is user research. This involves going out and observing what users are doing and why. The particular methodologies chosen depend on several factors such as the specific research questions and the available budget.
Through user research we gain an understanding of how tasks are currently performed, what the barriers are, and where the opportunities lie. These data go directly into creating the behavioral profiles and key scenarios.
Example Behavioral Profiles
To create behavioral profiles, we look at patterns of motivations, goals, and usage. For example, let’s say we are creating a photo management and sharing system. We might have a behavioral profile for "Family Photographer" and one for "Photography Enthusiast." Behavioral profiles can be captured in table form, with cells for goals, motivations, and usage patterns.
Family Photographer
Usage Patterns
Photography Enthusiast
Usage Patterns
Adding Contextual Details: Key Scenarios
Where we do add contextual details is in the key scenarios. Key scenarios focus on the most frequent and important "chain of events." For example, a key scenario for the Family Photographer might be "Share Recent Images with Friends and Family." The scenario would be written as a particular instance of the scenario—for example Mary, who has just had a birthday party for her four-year-old son. Tasks included in the scenario might be import images, create an album, add images to album, decorate album, share the album—but these would be put in the context of Mary working with the birthday party images to share with friends and family.
Yesterday, Mary and Tim had a birthday party for their four-year-old son Jacob. It was an exhaustive undertaking, but everyone had a wonderful time and Mary got some great photos. Mary wants to create a web-based photo album to share not only with the people who attended the party, but with those who weren’t able to attend, including her parents who live on the opposite coast.
The details help "make it real," but by using them to describe actions, they are kept relevant to the tasks the system is designed to support. We have found that focusing contextual details on key scenarios gets us into the design process sooner and with clearer focus.
If You Choose to Use Personas
In many organizations, personas do have a place—particularly where there is a tradition of focusing on technology rather than users. As humans, we are naturally attracted to other people: personifying users can be a powerful agent of change. The key is to not let the personality of your personas overshadow (or replace) the relevant behaviors and attitudes. If you do use traditional personas, keep the following factors in mind:
Root your personas in data about actual user behavior. If conducting field research isn’t feasible, interview people in your organization that have direct and frequent customer contact: customer service personnel or sales people, for example.
When analyzing your data, focus in on key goals and behavior patterns—you want to create a few, distinct personas that will be easy for project stakeholders to work with.
Capture and describe relevant characteristics—skills, attitudes, motivations, goals—before adding any personalizing details.
Beyond Behavioral Profiles and Key Scenarios
At Blink, behavioral profiles and key scenarios are important inputs to design, but they characterize typical system use—not all system use. Even though we use key scenarios as the starting point for design for the most important functions, we also obviously need to consider all functions. For this we do more detailed task analysis using objects and actions. We’ll talk about objects and actions in a future essay.
About the Author: Heidi Adkisson is the Director of Interaction Design for Blink Interactive. Heidi joined Blink in 2001 and has over 15 years of software development experience working with large-scale system implementations. Prior to Blink, her experience included requirements analysis and interactive design, working with established companies such as AT&T Wireless and Microsoft.
If you have been around system design in the past several years, you have no doubt encountered personas: bright, whole, wholesome (and entirely fictional) users complete with family members, college degrees, cars, and recreational interests.
Personas are created to help project team members understand and empathize with users. This, in turn, should help drive better design decisions—creating features that will do the best job possible in meeting user needs. Unfortunately, there is a temptation with personas to focus on the personalizing details, giving less emphasis to the behavioral characteristics and motivations that should drive system design. Where this happens, personas have little value.
At Blink we prefer to characterize users in terms of behavioral profiles, devoid of personalizing details. But we aren’t opposed to telling a story to get project stakeholders to empathize with users—the difference is we accomplish this by using contextual details in key scenarios.
User Research is Key
The starting point for our process is user research. This involves going out and observing what users are doing and why. The particular methodologies chosen depend on several factors such as the specific research questions and the available budget.
Through user research we gain an understanding of how tasks are currently performed, what the barriers are, and where the opportunities lie. These data go directly into creating the behavioral profiles and key scenarios.
Example Behavioral Profiles
To create behavioral profiles, we look at patterns of motivations, goals, and usage. For example, let’s say we are creating a photo management and sharing system. We might have a behavioral profile for "Family Photographer" and one for "Photography Enthusiast." Behavioral profiles can be captured in table form, with cells for goals, motivations, and usage patterns.
Family Photographer
- Goals: Share family moments and events
- Motivations: Give joy to friends and family members; tell a story in pictures
Usage Patterns
- Irregular frequency: works with images in response to an outing or event
- Spends large amount of time crafting image captions; may collaborate with other household member to “tell the story” to friends and family—humor often an important element
- Enjoys adding thematic elements to photo pages—travel, parties, sports, etc.
- Creative unit = the page or pages containing images
- Time-sensitive: photo quality less important to timeliness, sharing an event as soon as possible
- Long-distance photo sharing may include talking on the phone while both parties view the photos online
Photography Enthusiast
- Goals: Create a compelling photography portfolio
- Motivations: Showcase photographic talent; have talent recognized by others
Usage Patterns
- More regular frequency: tends to work with images during a particular time devoted to the hobby
- Highly selective: spends significant time comparing images of the same subject against each other to select the highest quality image
- Photo editing highly important: uses Photoshop or other sophisticated editor to improve image quality or make creative composites
- Minimal or no captions
- Minimal or no thematic elements to photo pages
- Creative unit = image
- Public sharing of images
- Watermarking of images highly important to protect copyright
Adding Contextual Details: Key Scenarios
Where we do add contextual details is in the key scenarios. Key scenarios focus on the most frequent and important "chain of events." For example, a key scenario for the Family Photographer might be "Share Recent Images with Friends and Family." The scenario would be written as a particular instance of the scenario—for example Mary, who has just had a birthday party for her four-year-old son. Tasks included in the scenario might be import images, create an album, add images to album, decorate album, share the album—but these would be put in the context of Mary working with the birthday party images to share with friends and family.
Yesterday, Mary and Tim had a birthday party for their four-year-old son Jacob. It was an exhaustive undertaking, but everyone had a wonderful time and Mary got some great photos. Mary wants to create a web-based photo album to share not only with the people who attended the party, but with those who weren’t able to attend, including her parents who live on the opposite coast.
- Mary plugs her camera into her computer and transfers the photographs to the Pictures folder.
- As soon as the transfer is complete, her computer automatically launches the application and displays the just-transferred images in chronological order.
- Mary took a huge number of photos with the idea that she could always weed them out later. She wants to put together a collection (album) of only the very best photos.
- Mary creates a new album called "Jacob’s 4th Birthday."
- Mary would like to add a visual theme to her photo album. Because Jacob’s party had a "cars" theme, she browses for a matching photo album theme. She finds the perfect theme and applies it to the album. However, since she hasn’t yet added any photos, she just sees a car-themed "cover" for the album, which contains the album name.
- Mary carefully selects the photos for the album. She starts by selecting the absolute best photos first, regardless of where they fit in the chronology. As she adds photos, they are placed in the album in chronological order by default (but she can change the order if she desires).
The details help "make it real," but by using them to describe actions, they are kept relevant to the tasks the system is designed to support. We have found that focusing contextual details on key scenarios gets us into the design process sooner and with clearer focus.
If You Choose to Use Personas
In many organizations, personas do have a place—particularly where there is a tradition of focusing on technology rather than users. As humans, we are naturally attracted to other people: personifying users can be a powerful agent of change. The key is to not let the personality of your personas overshadow (or replace) the relevant behaviors and attitudes. If you do use traditional personas, keep the following factors in mind:
Root your personas in data about actual user behavior. If conducting field research isn’t feasible, interview people in your organization that have direct and frequent customer contact: customer service personnel or sales people, for example.
When analyzing your data, focus in on key goals and behavior patterns—you want to create a few, distinct personas that will be easy for project stakeholders to work with.
Capture and describe relevant characteristics—skills, attitudes, motivations, goals—before adding any personalizing details.
Beyond Behavioral Profiles and Key Scenarios
At Blink, behavioral profiles and key scenarios are important inputs to design, but they characterize typical system use—not all system use. Even though we use key scenarios as the starting point for design for the most important functions, we also obviously need to consider all functions. For this we do more detailed task analysis using objects and actions. We’ll talk about objects and actions in a future essay.
About the Author: Heidi Adkisson is the Director of Interaction Design for Blink Interactive. Heidi joined Blink in 2001 and has over 15 years of software development experience working with large-scale system implementations. Prior to Blink, her experience included requirements analysis and interactive design, working with established companies such as AT&T Wireless and Microsoft.
I agree with you! The starting point for our process is user research.
ReplyDeleteProWeb365 web design