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.

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.

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.

• Case Studies
• Essays
• A Recipe for Effective User Interviews
• Eye tracking usability studies: what are users really looking at?
• Staff Picks: Usability Highlights from 2007
• How Useful are User Interface Patterns?
• Understanding Older Users: Is Your Website "Senior-Friendly"?
• Real-World User-Centered Design
• Consistency—when is it too much of a good thing?
• The Art of the Conceptual Prototype
• Participatory Design in World of Warcraft
• Minimizing Usability Risks in Web Applications
• Making Design Collaboration Work
• Staff Picks: 10 Usability Favorites for 2006
• Aesthetics and Usability: What can interface design learn from painting?
• Objects and Actions Analysis
• Matching Prototypes to Research Goals
• Keeping Page Layouts Simple and Easy to Scan
• Designing for Now, Later, and the Ideal
• Characterizing Users and Usage
• 800 or 1024?
• Seeing Red

Subscribe:

• Blink Essays Feed