COMPSCI 345 S1 C and SOFTENG 350 S1 C

Discovery:Interpretation and Documentation

Lecture 20Lecturer: Jim Warren

Based on Heim Chapter 4.3-4.4

Discovery

The voyage of discovery is not in seeking new landscapes but in having new eyes.

(Proust, 1982)

• Discovery Phase Framework• Collection (some key techniques

covered in earlier lectures)• Interpretation• Documentation

2© Heim 2008

Discovery Phase Framework

• During the discovery phase we must find out what we will need to know about the work that people do– We must understand what data is needed to

create the design– We must create the proper tools to gather and

interpret that data

3© Heim 2008

5W + H and Filters

• In your data collection– Note: What/How, Where/When, Who/Why

• Observe with various perspectives– Physical (what’s done?, what objects are

involved?)– Cultural (who bosses who?)– Functional (things created, documented)– Informational (what info is needed [and by

whom]?, how does the information flow?)

4

Data collection methods

• Observe– But remember Hawthorne effect

• Direct Elicitation– Interview, focus group

• Indirect Elicitation– Review corporate documents (e.g.

procedure manuals)– Ask people to keep logs/journals– Distribute questionnaires

5

Interviews

• Both open-ended (unstructured) and closed (structured) questions– Try to avoid leading questions– You want to learn what they really think/do

• Use predefined scenarios to stimulate conversation (“Say a client wanted... What would you do?”)

• Make purpose clear to interviewee and summarise back to them what you think they said– They might correct you and they’ll be happier knowing

you heard them

6

Focus Group

• Pretty much like an interview, but with a group of people

• Added benefit of ‘cross-talk’ (what they say to each other, especially if they argue a bit)

• Need a ‘moderator’ to keep in on track (and maybe a note taker besides)

• Need group to be roughly ‘peers’ – not a focus group if one person is the boss and everyone else just agrees

7

Interpretation

• After collection you interpret the information by:– Creating descriptions of the people who do the work– Describing the different goals involved in the work– Documenting the work step by step– Creating different stories about how the various

aspects of the work are done– Creating charts and diagrams of the work flow– Tracing the different stories identified with the

various people through the charts and diagrams

8© Heim 2008

Organizing the Discovery Process

• The data collected must be organized and transformed into information

• The tools we will explore include the following:– Task analysis– Storyboarding– Use cases– Primary stakeholder profiles

9

Interpretation means going from data to design requirements

© Heim 2008

Task Analysis• Task analysis is a way of documenting how people

perform tasks• A task analysis includes all aspects of the work flow• It is used to explore the requirements of the

proposed system and structure the results of the data collection phase

• Task decomposition– A linear description of a process that captures the elements

involved as well as the prevailing environmental factors.

• Hierarchical task analysis (HTA)– HTA provides a top-down, structured approach to

documenting processes.

10© Heim 2008

Task Analysis - Task Decomposition

• Identify the process• Describe the steps• Include the following:

– The reasons for the actions– The people who perform the actions– The objects or information required to complete the

actions

• Should try to capture:– The flow of information– Use of artifacts– Sequence of actions and dependences– Environmental conditions– Cultural constraints 11

© Heim 2008

Task Analysis - Task Decomposition

• Task decompositions include:– Goal—This defines the top-level goal for the

analysis• E.g. Schedule a team meeting

– Plans—Describe the order and conditions required to proceed with subtasks

• E.g. Reserve the conference room, A.V equip. based on availability of team members

– Information—This includes all of the information you need to perform the task

• E.g. Team member contact info, conference room schedule, A.V equip. use procedures

– Objects—These include all of the physical objects you will use to find the information

• E.g. Conference room calendar, team address book, A.V sign-up sheet. 12

© Heim 2008

Task Analysis - Task Decomposition

– Methods—These are the various ways you can proceed.

• E.g. Can contact team via email, IM, phone etc…

– Objectives—These are the subgoals• E.g. Contact team members, Coordinate schedules,

book room, book A.V equip, confirm meeting with team

– Procedures—These are the triggers that may initiate contingency activities

• E.g. Coordinate schedules, Check room & A.V bookings

– Contingencies—These will describe what you need to do if one of your methods does not work

• E.g. If you get no response from email try other methods of communication.

13© Heim 2008

Task Analysis - HTA

14

Start with a specific goal and then add the tasks or subgoals required to achieve that goal

Expand recursively until you reach granularity suitable to your purpose

Annotate with procedural flow among subgoal activities

(Gerald covered HTA in Lecture 13 – note that Heim uses a different HTA notation. We’re using the notation from Dix et al in this course)

© Heim 2008

Storyboarding

• Storyboarding involves using a series of pictures that describes a particular process or workflow– A bit like a comic strip or the scene selection menu on

a DVD– Origin: from early 1900s design specification for a

movie

• Can be used to study existing workflows or generate requirements

• Can facilitate the process of task decomposition• Used to brainstorm alternative ways of

completing tasks

15© Heim 2008

Use Cases• Use cases represent a formal, structured

approach to interpreting workflows and processes– Designed to describe a particular goal and explore the

interaction between users and the actual system components

• The two main components:– Actors: similar to stakeholders, but can also include

other systems, networks, or software that interacts with the proposed system

– Use Cases: Each actor has a unique use case, which involves a task or goal the actor is engaged in

• Describe discrete goals that are accomplished in a short time period

• Describe the various ways the system will be used and cover all of the potential functionality being built into the design

16© Heim 2008

Use Cases Example

17

Use case diagram of “schedule a meeting” process.

Use Case

Actor

© Heim 2008

Use Cases• Can be diverse paths through a Use Case

– Basic Path: The primary path through the use case is the one that is completed without any diversions from error conditions or extenuating circumstances

– Alternate Path: Alternate paths test the exception-handling capabilities of the system

• They capture premature termination of a process, choosing of a different method and possible error conditions

– Scenarios: Each unique path through the use case is called a scenario

• Scenarios represent discrete instances that combine to create the complete use case

• They are the lowest level of the use case and should cover all conceivable paths and alternatives.

18© Heim 2008

Use Case notation

• Part of UML – see http://www.agilemodeling.com/artifacts/useCaseDiagram.htm (where stick figures are standard for actors, even when the actors aren’t people)

• Can also use activity diagrams or program flowcharts (good if there’s a lot of branching)

• Can just use numbered steps (with branching as pseudocode)

19

Primary Stakeholder Profiles

• Primary Stakeholder Profiles are used to define the target user

• The constructs covered include:– Context of use– Cognitive ability– Physical ability– Individual profile

20© Heim 2008

Primary Stakeholder Profiles• Context of Use for a common office

desktop system

21© Heim 2008

Primary Stakeholder Profiles

• Cognitive Abilities of the target user affect the design

• The cognitive abilities of the target user may be specific or more general

• Note: Domain expertise may not correlate with computer literacy

22© Heim 2008

Primary Stakeholder Profiles

• Physical Ability: the human condition includes wide ranges of abilities– visual– auditory– haptic

23© Heim 2008

Primary Stakeholder Profiles

• Individual profiles: There are situations when personal user information is required– E.g. if you are designing educational

software you may want to specify age by grade level.

24© Heim 2008

Documentation

• The results of the discovery phase are recorded in the following published documents– Mission statement– Requirements document– Project management document– Usability guidelines

(you could do a whole course on each of these four – certainly on requirements or project management – we just describe them briefly for this course)

25

Mission Statement

• Project goals – What is the value proposition? – What needs will the new system address?– How will it address these needs?

• Project scope– What does the proposed design include or

exclude? – What are the external constraints such as

time and finances? – How will you decide when it satisfies the

design proposal?

26© Heim 2008

Requirements Document

• Requirements– Functional –basically a list of required

features– Information – what info. is needed to carry out

functional requirements– Physical – hardware? Also consider

interoperability with legacy systems

• Inputs/outputs• Constraints - e.g. time, money, security…

27© Heim 2008

Project Management Document

– Definition of the tasks involved in the project

– Risk – e.g. time, money, security, safety– Evaluation criteria and methods– Implementation– Training requirements– Maintenance– Future needs

28© Heim 2008

Usability guidelines

• While Nielsen recommends a small set (esp. his 10 general ones!) for Discount Usability Testing, a project may endorse a particular set that’s much longer and more specific– esp. common when there’s a handover from

gov’t to a contractor at this step; but they can be good anyway

– E.g., 247 web usability guidelines at http://www.userfocus.co.uk/resources/guidelines.html

29

• We have now covered discovery, the first part of the design process model

Summary: The Design Process Model

30