Neo Insight's e-newsletter on Usability topics and techniques.
We invite you to subscribe to our monthly e-newsletter.

Our next workshop

August 17, 2006	Usability challenges of new Web technologies – One day Workshop. Save $100 if you act now – early registration deadline August 4th.
September 21, 2006	Designing usable Web-based applications – One day Workshop Save $100 if you act now – early registration deadline Sept. 8th

Upcoming events

July 7, 2006	Demonstration proposals are due for CSCW2006, the Computer Supported Cooperative Work conference in November in Banff, Alberta.
October 9-12, 2006	UIE User Interface 11 conference in Cambridge, Mass.
November 14, 2006	World Usability Day . See how to get involved at "Make Yourself Useful".

---

Using scenarios and personas in analysis, design, and design capture

We use scenarios and personas because they help us – and our clients – think about users. Software designers have too many pressures to think about their users’ context. Scenarios and personas help designers keep a lot of things in mind related to the flow of users’ tasks. Personas and scenarios are a process – not a product – a method and means to an end. A persona puts a person into the interaction – the user has a task to do, and the software responds: a user goes to the web for something, and a web page offers something in response. Designing that interaction is about accurate and meaningful communication, and personas help us consider the varied contexts (business, organizational, task, environmental, etc.) of that interaction. Following are some ways we do that.

Personas describe a fictional user in details that help stakeholders understand users’ goals, tasks, and context surrounding the user experience we are analyzing. Beyond demographics, the persona describes a user's motivations, overall goals, contextual tasks, relationships, etc. Using personas in up front design helps designers grasp a variety of usage characteristics in personal terms.

Gathering data for personas and scenarios requires rigorous effort. Kim Goodwin of Cooper Design cautions that “personas are based on real data about users’ observed behavior patterns”, and they represent “archetypal users – a distillation of what you’ve really seen.” They must not be imaginary people generated by the development team’s brainstorming! Rigorous first-hand observation of usage and context provides rich background for developing personas.

1. How we use scenarios and personas to analyze user requirements

To study behaviour in vignettes. Vignettes are short stories about specific user tasks. We use them early in the design cycle, to help communicate a product concept, sketch, or early prototype. One or more personas will play a role in one or more vignettes. They can be quickly refined by role playing or brainstorming. We use vignettes to build consensus on a design team, and help the design team bring their concept to life. Personas developed at this stage may be limited in scope, only describing the context and motivations related to the task represented in the vignette.

To test hypotheses in research scenarios. A research scenario is a structured story we often use as stimulus material in interviews and discussion groups, to flesh out user requirements, usability issues, or business needs. We embed our hypotheses in short scenarios to help participants quickly understand a user's task within a meaningful context. Responses to research scenarios reveal behaviours we cannot elicit in public opinion research. They differ from vignettes in that they need to be evocative and push boundaries. If they don't, we often only get meaningless "motherhood" statements. If successful, research scenarios will evoke reactions that prove some hypotheses to be wrong, and validate others. The limitation of research scenarios is that due to their evocative nature they must be edited before being used further. 

Here is an example from a research scenario we created for interviews with farmers:

Interviewees rated this scenario highly, against tasks of finding information, saving search results, and discussing information. However, interviewees also told us government should play a role, rather than just suppliers. That’s what made it a good research scenario – we were able to test our hypotheses and gather meaningful responses.

2. How we use scenarios and personas in design iterations

Personas aren't something you do at the start of a design process and then forget. They evolve along with your organization and its website”, Bob Doyle explains in EContent. “Personas include the skills, the tools, and the working environment”.

To populate use cases with actors and their tasks. Use cases are structured techniques for defining user requirements in up front business analysis. For use cases, we express personas as actors, and their tasks as a step-by-step flow of interactions. We gather inputs from interviews, observation, usage analysis, audience segmentation, and focus groups. The system responses for key user interactions are detailed methodically until all key interactions, roles, and systems are described.

Use cases are limited because of their linear nature in characterizing user workflow. They don’t provide for inclusion of non-linear detail about related usage, social context, or business processes. Thus we often combine them with other persona or scenario methods. Plus they must be abstracted before applying to other systems or technologies – one reason why we create essential use cases.

To portray a high level user goal in essential use cases. Essential use cases are a distillation of detailed use cases. Larry Constantine says these should be defined only after the rigour of analysing the detailed use cases that underlie them. We use these high level summaries to explain to partner design teams where their systems are included in the interaction. We use them to summarize the workflow or task analysis for stakeholders. Whereas a detailed use case is often  tightly coupled to a particular implementation, the essential use case describes less about the technology and more about the interaction in human terms.

An example of an essential use case we constructed in a homecare project described the interaction between a nurse and patient, high level goals, and made broad references to systems used in those interactions. The essential use cases allowed us to draw implications for other systems – like the need for more bandwidth from the home rather than to the home. These essential use cases communicated equally well with our healthcare clients, technology partners, and executive audiences.

3. How we use scenarios and personas in design capture

Scenarios and personas are useful as a way of capturing the knowledge that goes into design – the needs analysis, alternatives considered, hypotheses, tests and evaluations, and modifications. In this sense, they are part of an organization’s long-term Knowledge Management armory, and one way we ensure that our client’s capabilities continue to develop after we have completed a project. Nearing the phase when design closes, or goes into launch, more highly refined scenarios and personas are needed.

To clarify the overall value proposition. The value proposition captures the output of personas and scenarios in an “elevator speech”. The value proposition summarizes the customer, the concept, and the competition. It fills in this sentence:

After we refine the single-sentence approach through a few design iterations, it becomes a good communications tool during design capture.

To create a reference experience that exercises a reference architecture. The reference experience is built around a scenario that best communicates the product value in terms many listeners will understand. It provides the connection between the usage scenarios – built around personas – and how the technology and architecture deliver that value. It summarizes usage, as a reference architecture summarizes the structure of a system, and how underlying elements inter-work during a scenario. We use a reference experience to bring the architectural components to life as they help users accomplish their tasks and achieve their goals.

4. How other design organizations use scenarios and personas

To use a common approach across teams. Microsoft’s John Pruitt and Jonathan Grudin say personas “create a strong focus on users and work contexts through fictionalized settings. We’ve seen Personas go from scattered to widespread adoption. Our Personas are seen everywhere and used broadly.”

GeoConnections also suggests a common approach, providing Use Case terms and definitions for its diverse set of organizations it serves.

An article about the team that redesigned www.bbc.co.uk says “creating personas helped guide the development of both visual design and information design for the project. They’re a fun, powerful design technique that helps provide a framework for a successful project.” The BBC’s primary persona is summarized like this:

To summarize profiles of user groups. Whitney Quesenbery Usability says a persona is “a sample person, representing a profile; a specific character with a name, job title, background and personal history along with personal goals and wishes”. The detail behind the persona, the user profile, is “a summary of key characteristics or facts about a group of typical users”. The MAYA lab at Carnegie Mellon University, defines personas as “vivid descriptions of archetypal customers”. Here are some personas MAYA defined for a library project (skim to page 23 for the personas).

To communicate user requirements. Parrish Hanna of the Experience Planning Group tells how personas and scenarios help communicate requirements: “Personas and scenarios tell honest stories that are sculpted from diverse and comprehensive sets of data. Over the past few years, they have risen in importance and become a primary tool for communicating data analysis, strategic business frameworks, new product and service concepts, and cross-channel brand experiences.” Gary Randolph, from Purdue University, summarized user requirements in light-weight personas, citing the personas' description, personal goals, goals for the system, and interface implications. Here is one example:

Name	Job Function	Description	Personal Goals	Goals for System	Interface Implications
Andrea Mohler	Education Specialist Group	Frequent (even daily) user of system. Computer savvy.	Sees the system as a reflection on her. She wants it to be well thought of.	Needs to process groups of training records en masse.	Power-user functionality

 

---

If you have any comments on The Insighter, or ideas on usability topics you'd like to hear about, send us an email with your comments.

We invite everyone to subscribe to the Insighter, our monthly e-newsletter.

If you wish to unsubscribe, just send us an unsubscribe email.