Interactive Systems SoSe 23

Introduction to Use Case reporting

Slides from the HCI lecture by Prof. Steimle

Use Case Reporting
We have shortened a few slides from the HCI lecture as a recap.

This also involves scenario-based design, which can be the basis for use
cases. However, for your final report you only need to look at the use
cases.

But it is always good to think outside the box and have a little more
knowledge about the methods you are using.
 What are User Needs?
Users rarely know what is possible
Users can’t tell you what they ‘need’ to help them achieve their
goals

E.g. in the 1990s, who would have said to need a mobile device for playing back short
videos from a large collection of mostly home-made videos?
 65

Task Analysis
Instead, look at existing tasks.
Try to understand
• the characteristics and capabilities of the users
• what the users are trying to achieve
• how they achieve it currently
• whether they would achieve their goals more effectively and
• whether they would have a more enjoyable experience if they
were supported differently

➔ Envisioned tasks can be rooted in existing behaviour

 69

Scenarios
Telling stories is a natural way for people to explain what they are doing

A scenario is an informal narrative story

Simple, ‘natural’
Personal, not generalizable
Offers only one perspective

Often generated during interviews, brainstorming sessions or workshops

Focus on activities, not on design solution
Scenario-based Design
◦ The whole design process is based on scenarios
◦ Advantages:
◦ Scenarios are stories
◦ Stories are simple and easy to understand
◦ Allow discussion
Scenario
◦ A story about a user using your product to carry out a task
◦ Example: “How Paul uses a website to order flowers for his
mother’s birthday ?”
◦ Should involve: the ‘who’, ‘what’, ‘when’, ‘where’, ‘why’, and ‘how’
of the usage.
Scenario
◦ Context
◦ Background about everything the reader needs to know
◦ Person
◦ Situation
◦ Programm
◦ Scenario
◦ Detailed story
◦ Describes:
◦ How the user accomplish his goal?
◦ Via program,......
Establishing Requirements
◦ Who are the users?
◦ Background?
◦ Skills
◦ System use (novice, casual, frequent)

◦ Users vs stakeholders
◦ Stakeholders are everyone affected by the system
 36

Why Establish Requirements?

Personas
◦ Rich and realistic description of a fictional person
◦ Helps understand the users
◦ Captures goals of this set of users
◦ Captures skill, background, and attitudes of the user

◦ To build personas:
◦ Demographics (age, gender, ..)
◦ Background information (job, interest, hobbies)
◦ Needs and interests
◦ Motivation
◦ ...
Personas

Example from: US Department of Agriculture’s Economic Research Service, https://www.usability.gov/how-to-and-tools/methods/personas.html

 59

Example
Personas
• In this lecture, we are not focusing on the personas.
• It is fine if your persona is very basic:
• Fictional name
• Age
• Experience with technology XY?
• Frequent user of your project
 73

Use Case Diagram

Capture a list of possible actions between an actor and a system to
achieve a goal
• focus on user-system interaction (rather than just a task)
• assume detailed understanding of the interaction

Part of UML (Unified Modeling Language)

First identify the actors; then examine each actor and identify their
goals in using the system
 75

Example use case diagram for travel organizer

 76

Use case for travel organizer

Alternative textual description

1. The system displays options for investigating visa and vaccination

requirements.
2. The user chooses the option to find out about visa requirements.
3. The system prompts user for the name of the destination country.
4. The user enters the country’s name.
5. The system checks that the country is valid.
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the entered country for a
passport holder of her nationality.
9. The system displays the visa requirements.
10. The system displays the option to print out the visa requirements.
11. The user chooses to print the requirements.

You should present them in a more appealing way!

How to get a good Use Case?
• Think of a meaningful and relevant scenario.
• Fill the scenario with life through a persona.
• How would your persona solve the scenario using your project?
• Describe the solution in detail and you have your first use case ☺
• You can also use images and graphics to illustrate your use case.
• Feel free to describe your persona in the use case (but it’s not required). Maybe a
different persona would solve the task different, e.g., by using other modalities.

• Repeat this three times and you are done.

• Use different scenarios for the three use cases that are result in different
use cases!