1. COMPSCI 345 S1 C and SOFTENG 350 S1 C Discovery: Interpretation and Documentation Lecture 20 Lecturer: Jim Warren Based on Heim Chapter 4.3-4.4

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Use Cases Example 17 Use case diagram of “schedule a meeting” process. Use Case Actor © Heim 2008

18. 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

19. 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

20. 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

21. Primary Stakeholder Profiles Context of Use for a common office desktop system 21 © Heim 2008

22. 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

23. Primary Stakeholder Profiles Physical Ability: the human condition includes wide ranges of abilities –visual –auditory –haptic 23 © Heim 2008

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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/guid elines.html 29

30. We have now covered discovery, the first part of the design process model Summary: The Design Process Model 30