Presenting findings: use cases, personas and scenarios

Findings are presented as structure, as stories or as summaries

Intuition

A table of interview quotes helps the analyst but not the developer. The lecture covers three ways to turn findings into something a team can use: a structured notation, a story, or a summary.

Lecture 5 lists three presentation styles. Structured notations have a clear syntax and semantics to present a particular viewpoint, for example a use case diagram. Stories and storytelling are an easy, intuitive approach, for example personas and scenarios. Summaries use tables, graphs, diagrams or video.

Use cases are step-by-step interactions

Use cases focus on functional requirements and capture interaction. They can be used to think about interaction design or to capture requirements. There are two styles: essential use cases, and use cases with normal and alternative courses.

Compare

Essential use case

Divides tasks between user and system. Focuses on user intentions and product responsibilities. No implementation or interaction detail.

Use case with alternative courses

A numbered normal course, plus alternative courses for exceptions. In the visa example, an invalid country name (step 4) gives an error message and returns to step 1, and an invalid nationality (step 6) gives an error message and returns to step 4.

The visa example runs: the product asks for the country, the user gives it, the product checks it, asks for nationality, the user gives it, the product checks visa requirements, provides them, asks whether to share on social media, and the user provides the details.

In a use case diagram, use cases are ellipses (actions by one or more actors toward a goal), actors are stick figures (a person, organisation or external system), the optional system box shows the scope, and solid lines are associations linking an actor to a use case. The example figure did not extract.

Personas are typical users, scenarios are their stories

A persona is synthesised from real people based on user research. It is typical, not idealised, given a name, characteristics, goals and personal background, and relevant to the product. A good persona helps designers make decisions and reminds the team who will use the product, avoiding elastic users, self-referential design and edge cases.

Mechanism

Create personas in three steps. 1 Identify behavioural variables from demographic data (activities, attitudes, aptitudes, motivations, skills). 2 Identify common patterns by mapping participants to behavioural data. 3 Synthesise and build the model.

Persona types on the slide: primary (the target of the interface), secondary (primary needs plus additional features), supplementary (a combination of primary and secondary needs), customer (the needs of the customer, not the end user, who may also be a primary user), served (not users, but directly affected by the use of the product) and negative (users the product is not meant for). The slide arranges these in two columns, so which of them count as the “main” set is unclear in the extraction.

A scenario is a narrative describing the tasks performed by the persona. Ask: who is the persona, what triggers the experience, what happens, and what is the outcome. The lecture example is the Thomson family planning a sailing trip with a travel organiser system, covering context (different locations and devices) and an outcome (the system emails a summary of options).

Exam detail

Persona versus scenario: personas are rich descriptions of typical users, not specific people. Scenarios are narratives of tasks performed by the persona. The lecture summary slide credits Courage and Baxter (2005) for how user profile, persona and scenario relate, but the figure did not extract.

Pitfall

Do not treat a persona as one real participant. It is a synthesis. Do not confuse “elastic user” (a vague user stretched to fit any decision) with a persona type.

Secret City shows the chain from data to design artefacts

Secret City: Edinburgh is an interactive narrative platform with two user types. Players use a mobile app to find their way around Edinburgh and activate Story Nodes defined by geographic location, viewing text, media and puzzles. Creators create the stories players experience. Data gathering used a focus group of potential users, interviewed informally over phone, email and instant messenger. The Benyon reading (Chapter 3.7) shows user stories transcribed from those interviews, personas built from them (George and Sarah, players and creators), conceptual scenarios (picking, resuming, saving, completing, creating and publishing a story) and requirements lists with a rationale.

Worksheet W5 applies the same chain to your group project: choose a UN sustainability goal, identify challenges and opportunities, decide the technology, brainstorm requirements, find common themes and prioritise the most critical, and map requirements to features. It is assessed group work, so no answer is given here.

Recall

Give the four scenario questions and the three persona creation steps.

Scenario: who is the persona, what triggers the experience, what happens, what is the outcome. Persona: identify behavioural variables, map participants to find patterns, synthesise and build the model.