chapter 3 Use case scenario, persona and user modeling

USER FOCUS: Persona who are they? probably not like you! talk to them watch them use your imagination 2

 One method that has been quite successful in helping design teams produce userfocussed designs is the persona.  A persona is a rich picture of an imaginary person who represents your core user group. 3 USER FOCUS: Persona

4

Scenarios are stories for design: rich stories of interaction. They are perhaps the simplest design representation, but one of the most flexible and powerful. Some scenarios are quite short: ‘the user intends to press the “save” button, but accidentally presses the “quit” button so loses his work’. Others are focussed more on describing the situation or context. Like the persona it is perhaps more detailed than appears necessary, but the detail helps make the events seem real. 5 Scenarios:: DESCRIBING TASKS

6

The figure shows plain text, but scenarios can be augmented by sketches, simulated screen shots, etc. These sketches and pictures are called storyboards. 7 Scenarios:: DESCRIBING TASKS

For example, we might imagine a digital Swiss army knife, which has a small LCD screen and uses the toothpick as a stylus. The knife connects to the internet via a wireless link through your phone and gives interesting tips from other Swiss army knife users. Try getting two together at a party – you will see this would appeal! It sounds like a great design idea – but wait, try acting out the use. If you have a Swiss army knife, use it, or use something pen knifesized if you don’t. The tip on the LCD says, ‘open the stone remover’: a small LED glows near the right blade – you open it. ‘Now push the blade into the rubber of the grommet’, it says. You do this and then look for the next instruction. Look at the knife in your hand... oops, your thumb is covering where the screen would be. Perhaps a voice interface would be better. 8 Scenarios:: DESCRIBING TASKS

You can see already how scenarios force you to think about the design in detail and notice potential problems before they happen. If you add more detail you can get to a blow-by-blow account of the user–system interactions and then ask ‘what is the user intending now?’; ‘what is the system doing now?’. This can help to verify that the design would make sense to the user and also that proposed implementation architectures would work. 9 Scenarios:: DESCRIBING TASKS

In addition scenarios can be used to:  Communicate with others : other designers, clients or users: It is easy to misunderstand each other whilst discussing abstract ideas. Concrete examples of use are far easier to share.  Validate other models: A detailed scenario can be ‘played’ against various more formal representations such as task models or dialog and navigation models.  Express dynamics: Individual screen shots and pictures give you a sense of what a system would look like, but not how it behaves. 10 Scenarios:: DESCRIBING TASKS

There is different ways of describing the patterns of interaction with a system. These are more complex and involve networks or hierarchies. In contrast scenarios are linear,they represent a single path amongst all the potential interactions. This linearity has both positive and negative points:  Time is linear Our lives are linear as we live in time and so we find it easier to understand simple linear narratives. We are natural storytellers and story listeners.  But no alternatives Real interactions have choices, some made by people, some by systems. A simple scenario does not show these alternative paths. In particular, it is easy to miss the unintended things a person may do. 11 Scenarios:: DESCRIBING TASKS

 Scenarios are a resource that can be used and reused throughout the design process.  helping us see what is wanted, suggesting how users will deal with the potential design, checking that proposed implementations will work, and generating test cases for final evaluation. 12 Scenarios:: DESCRIBING TASKS

 A more formal definition than a scenario or story From OO techniques, including UML, OOSE, etc.  Note terms in text: task scenario concrete use case essential use case use scenario 13 Use cases:: DESCRIBING TASKS

Use Case: “A sequence of actions a system performs to yield an observable result of value to a particular actor.” Actor: Someone or something outside the system that interacts with the system A user of the system in a particular role Part of Use Case Modeling is identifying and describing actors Important: We want an “external view” of the system 14  User case modeling Use cases:: DESCRIBING TASKS

Each use case has a name e.g. Borrow Copy of Book A family (or set, or class) of scenarios One main scenario for “normal” behavior or situation A sequence of interactions documenting Also set of different but related scenarios Documenting Use Cases (Maybe) A UML Diagram showing all of them - Actors are stick-figures; use cases are ovals (Certainly) For each use case define using English - A clear textual description (like a stories, a scenarios) - A set of scenarios in outline form 15 Use cases:: DESCRIBING TASKS

Actors - BookBorrower - JournalBorrower - Browser (person who browses, not software) - Librarian Use Cases - Borrow copy of a book - Reserve a book - Return copy of book - Borrow journal - Browse - Update Catalog 16

 Borrow copy of a book: A Bookborrower presents a copy of a book. The system checks that the s/he is a library member, and that s/he has not checked out too many books. If both checks succeed, then the system records that the member now as this copy of the book. Otherwise it refuses the loan. 17

18

 single, generic user (non-intelligent): Every interactive system that is built incorporates some model of the user for whom it is intended. In many systems this model is the designer’s view of the user and is implicit within the design. The designer has in mind a ‘typical’ user, and builds the interface accordingly. it does assume that all users are essentially the same and have the same requirements. 19

 User-configured model (adaptable): Systems allow the user to provide a model of himself around which the system will be configured.  Simple examples of this are browser or preferences that can adjust certain parameters of the system to the requirements of the user.  the user is able to adapt his own environment to suit his preferences. This increases the flexibility of the system but places the onus of the customization on the user. 20

 System-configured model (adaptive):the system construct and maintain a model of the user based on data gleaned from monitoring the user’s interaction.  This model can then be consulted when required.  This automatic approach to user modeling also has the problem of the setup time required, during which time the user has a default system, but the onus to build the model is taken away from the user. 21

 how are user models constructed and maintained? There are a number of approaches:  Quantification  Stereotypes  Overlay 22

 Quantification:  This is one of the most simple approaches to user modeling. The system recognizes a number of levels of expertise, which it will respond to in different ways.  The user is placed on one of these levels, and moves between them, based on a quantitative measure of his expertise at that time. Different activities are given weightings, and the user is scored according to the weightings of the activities he takes part in.  If the score exceeds a certain threshold, the user is moved to a different expertise level and the system adapts accordingly. 23

 Quantification: (example) Move from level 1 to level 2 if system has been used more than twice commands x and y used effectively help has not been accessed in this session system has been used in last 5 days 24

 Stereotypes:  the system classifies the user as a member of a known category of users or stereotype.  Stereotypes are based on user characteristics and may be simple, such as making a distinction between novice and expert users, or more complex, for example building a compound stereotype based on more than one piece of information. 25

 Overlay:  It is one of the most common techniques.  Here an idealized model, often of an expert user, is constructed and the individual user’s behavior compared with it.  it has a representation of optimal behavior. 26