1cs480: graphical user interfaces. dario salvucci, drexel university. lecture 5: scenarios

1CS480: Graphical User Interfaces. Dario Salvucci, Drexel University.

Lecture 5:Scenarios

CS338: Graphical User Interfaces. Michael Czajkowski, Drexel University. 1

Narratives

A Narrative is a Story Narratives:– Stimulate Visualization Skills– Brainstorm Design Ideas– They stir up the brain!

Proper Narratives require some visualization tool to present the ideas as pictures.– Whiteboards– Plain old paper– Possibly computer Graphical tools?


Scenarios in Design

But wait, you want me to tell stories? Not quite: Scenarios! Scenarios solve design problems

through concretization.– A specific story with concrete items.– The story constructs and illustrates design

choices.– Scenarios still allow fluidity among design

team. Guess who is the star of your scenario?– That's right: Your Persona!


Your Persona: A Star is Born

Personas are user archetypes of your design.

Personas describe typical user role and behavioral traits.

Your story will focus on how your persona gets the job done!

Personas reflect Goals and not just Tasks!

Personas will help answer:– “What should this product be?”– “How will this product behave?”– “What will the product look like”


What is a Scenario, then?

A Scenario is a concise description of how your star achieves his goal.

Scenarios are role-played out by designers.– One person plays the Persona– One person plays the computer system.

Scenarios come in three flavours:– Context Scenarios– Key Path Scenarios– Validation Scenarios


Requirements and Framework Phase

Researchusers &

the domain

Modelingusers &

use contexts

Requirementsuser, business, &technical needs

Frameworkstructure

& flow

Refinementof behavior,

form, context

Requirements Definition Phase translates the Personas into design ideas and solutions. What?

Framework defines the beha,.voir of the program's interface and how it flows. How?


Requirements Definition Phase

The “What” of the Design, done in five steps.1) Creating problem and vision statements2) Brainstorming3) Identifying Persona expectations4) Constructing the context scenario5) Identifying Needs


Frameworkstructure

& flow


Creating Problem and Vision Statements Lets create a mandate to move forward. A

sort of “declaration” statement. These statements reflect a situation that

needs changing for both Persona and business.

Examples of Problem and Vision Statements:

Company X's customer satisfaction ratings are low and market share has diminished by 10% over the past year because users don't have the adequate tools to perform X, Y, and Z tasks that would help them meet their goal of G.

The new design of Product X will help users achieve G by giving them ability to perform X, Y, and Z with greater efficiency without problems A, B, C that they currently experience. This will dramatically improve Company X's customer satisfaction ratings and lead to increased market share.


Brainstorming

Wait a moment, brainstorming? Get the wacky ideas out of your mind.

Clear the slate off, get them out of the system.

Record brainstroming suggestions, but don't expect them to get much further


Identify Persona Expectations

What would your Persona expect? This is the Mental Model, the perfect

image of what the Persona would expect.

Identify:– What does the Persona expect from the

product?– What does the Persona desire from the

product?– What past experiences of the Persona will

influence the desires of the Persona?


Construct Context Scenarios

Context Scenarios are about people and what they do to get their jobs done.

They identify “touch-points” the persona has with the system such as:– Will the product be used for extended time?– Is the Persona frequently interrupted?– What other products must it be used with?– What is the expected end result?

Context scenarios don't describe how things are currently done, but how they will be done to achieve the user's goals.


Identifying User Needs

Analyze the day-in-the-life scenarios to extract persona needs.

The needs are objects and actions as well as contexts. These are not tasks, just needs:– Must call Joe directly from a softball practice.– Must check e-mail to respond to Zack.– Must download latest e-zine articles for school.

Types of Needs:– Data: Information objects needed.– Functional: What is performed on the system– Context: Describe relationships between

objects.


The What of your design

Requirements Definitions have now been formed.

You know what needs must be achieved by the product's interface

You understand why the Persona needs them by going through context scenarios.

Now we're ready for the How these solutions will be implemented.


Defining the Interaction Framework Structure, Flow, Behavior. The How of

design.1) Defining form factor and input methods2) Defining views 3) Defining Functional and Data elements4) Determining Functional groups and

heirarchy5) Sketching the interaction framework6) Constructing key path scenarios


Frameworkstructure

& flow


Defining form factor and input methods How will the product be viewed?– Web application, phone application– What kind of lighting?– What type of screen resolution– What will the environment be like?– What ratio of novice:expert users?

And how will the input get into the product?– Keyboard and Mouse– Remote Control?– Thumboard, Touchscreen, Voice– Game Controller?


Defining Views

Primary States of the Product Use the context scenarios for this Cluster together into one view the

different types of data together if it makes sense.


Defining Functional and Data Elements The visible representations of functions

and data in the interface.– Panes, frames, and other containers on

screen– Groupings of physical control, object

manipulation.– Individual knobs, buttons– Data objects: images, graphs, icons.

The functional requirments from needs.– Assignable quick-dial buttons– Lists of contact information– Voice activation


Determine Functional Grouping

Real-Estate– What should be the biggest, and why?

Containers:– Containment relationships between

elements– Optimization of containers for flow

Grouping– Which elements are used together,

grouping.– Sequencing of related elements


Sketching the Interaction Framework


Constructing Key Path Scenarios

Key Path scenarios go into detail where context scenarios would not.

Key Path scenarios determine the primary actions of the Persona and the primary functionality of the system.

Key Path scenarios must be easiest to learn, as they are used the most.

Shortcuts on Key Path scenarios should be allowed as users get tired of pedagogy, like Clippy.


You now have the How

You now have determined how the interface will be structured, behave, and flow.

You know:– How the user will input into the interface.– How the interface addresses key user

needs.– How the user will group information

together.– How the user most frequently uses the

interface.


Paper sketches & storyboards

Advantages– support brainstorming– do not require specification of details– designers feel comfortable sketching

Drawbacks– do not evolve easily– lack support for “design memory”– force manual translation to electronic

format– do not allow end-user interaction


“Electronic paper” sketching

Quickly sketch this...



Add behavior…



Transform it to this…


SILK = Sketching Interfaces Like Krazy! Designer sketches ideas rapidly with

electronic pad and pen– SILK recognizes widgets – easy editing with gestures

Designer or end-user tests interface– widgets behave – specify additional behavior visually

Automatically transforms to a “finished” GUI


SILK: Screens

Screen = rough sketch of single screen state,including layout & components

Features for handling screens– editing: use strokes to delete, move,

group, …– history: save, restore, annotate– widget inference / recognition


SILK: Specifying behaviors

Behavior = association of a screen object with another screen

Specifying a behavior– put relevant screens in the “storyboard”– draw arrow from object to screen


SILK: Component recognition

Infer / recognize components based onstroke-based gestures– scrollbar = long thin box + small inner box

Difficulties– different strokes for different folks

• different stroke(s) may produce same drawing,but may be recognized very differently!

– requires that system be trained for specific user

– more on recognition later...


SILK: Component composition

When a component is recognized…– does the new component contain or is it

contained by another component?– is the new component near another

component?– is the new component in a sequence of

components of the same type?


“A Tighter Fit with Web Site Design”

Make SILK more useful to designers– technically: based on Java 2 for

portability– functionally: support web design

SILK

Another Tool: DENIM


DENIM: Creating pages


DENIM: Site map view

Zoom Slider


DENIM: Storyboard view


DENIM: Sketch view


DENIM: Run mode


Pan and zoom Pencils– Generic pencil for sketching– “Event pencils” for sketching arrows

associated with particular events Rubber stamps– For inserting components– Built-in components (e.g. buttons) can

be sketched

DENIM: Additional tools


Discussion

Would you use SILK? Why or why not?

What might SILK be especially good for?What might it be not so useful for?

Could we build a prototyping tool with the same goals but using a different modality?(e.g., using speech instead of sketching)

1cs480: graphical user interfaces. dario salvucci, drexel university. lecture 5: scenarios

Documents

graphical user interfaces

drexel university

needs requirements user

michael czajkowski

user archetypes

contexts requirements

design choices

design problems