1. CSC 341 Human-Computer Interaction
Lecture 2
PACT Analysis

2. Announcements Attendance sheet Please turn in HW1 Course website
Project ideas
Deadline for requirements analysis Oct. 1st.

3. Components of Good Design

4. Components of Good Design

5. Past PC Not considering users who used the PC
Systems developed by programmers who used computers for everyday work
Designers played computer games for years
Forgetting how difficult and obscure some of their designs can be to people who have not had these experience
Dr Ayman Ezzat modified version of Dr, Frank Kriwaczek

6. Now PC Web and mobile dramatically changed the age of HCI
E-commerce
E-Guiding
E-Learning
E………….
Before the immediacy of e-commerce, usability problems were only discovered after purchase.
If you bought a nice looking MP3 player and brought it home only to find it was difficult to use, you could not take it back!
The shop would say that it delivers its functions, all you had to do was to learn how to operate it properly. (read the manual!)
Dr Ayman Ezzat modified version of Dr, Frank Kriwaczek

7. The era of HCI Usability task
People are trying to accomplish their tasks in life. (system independent)
Ex: Call a friend to make dinner plans (iOS or Android doesn’t matter)
Introduce a system: User Interface should maximize their ability.
task
person
system

8. Why usability?
“A central concern of interaction design is to develop interactive products that are usable.”
“By this is generally meant:
easy to learn,
effective to use,
and providing an enjoyable user experience.”
A good place to start thinking about how to design usable interactive products is to compare examples of well-and poorly-designed ones. Through identifying the specific weaknesses and strengths of different interactive systems, we can begin to understand what it means for something to be usable or not.” [Section 1.2]

9. Example: hotel voice mail system
You read the instructions:
‘1. Touch 41.’
The system responds: ‘You have reached the Sunny Hotel voice message center. Please enter the room number for which you would like to leave a message.’
You wait to hear how to listen to a recorded message. But there are no further instructions from the phone. You look down at the instruction sheet again and read:
‘2. Touch*, your room number, and #.’
You do so and the system replies: ‘You have reached the mailbox for room 106. To leave a message, type in your password.’

10. Example: hotel voice mail system
You call hotel reception. They explain the process
You realize it takes 5 steps to record a message and 6 steps to retrieve it
You go out and buy a cell phone!

11. What went wrong?

12. What went wrong?
Inefficient: the system requires too many steps to perform basic tasks
Difficult to learn: instructions were not clear
Unintuitive: you cannot see at a glance what needs to be done
Confusing: with many options and it is unclear how to reach the desired one
Difficult to use.

13. Example 1: hotel voice mail system

14. What makes it better?

15. What makes it better?
Efficient: the system requires only one step to perform basic tasks
Easy to learn: simple but elegant design
Intuitive: you can see at a glance what needs to be done
Easy to use.
Aesthetically pleasing and enjoyable to use

16. … but there’s a problem!

17. … but there’s a problem!
No way to authenticate: anyone can listen to messages
Marbles can get lost
Hotel guests can take marbles as a souvenir
Not suitable for the context of use
Maybe useful at a house with no young children.

18. PACT analysis
People
Activity
Context
Technology

19. PACT analysis
People undertake activities, in contexts using technologies.
A student uses a phone to send a text message whilst sitting on a bus
Air traffic controllers work together using computers and flight strips to ensure smooth running of an airport in the air traffic control center.
A 70-year-old woman presses various buttons to set the intruder alarm in her house.
It is the variety in each of the PACT elements and their combination that makes interactive systems design so challenging and interesting.

20. PACT analysis
People
Activity
Context
Technology

21. People Physical differences Psychological differences
Height, weight, different capabilities in sight, hearing, touch,…
Psychological differences
Different ways of working; different memory abilities, spatial ability; different amounts of attention at different times; ability to recognize things or remember things. Different ‘mental models’
Usage differences
Experts versus novices, discretionary users of technologies, differences in designing for a heterogeneous group or a homogeneous group

22. Psychological differences
Differences in perception and attention
Differences in memory - short term and long term
Differences in mental models

23. Mental models Also known as conceptual models…
…mental models describe the ways in which we think about things - about how we conceptualize things.
a key aspect of the design of technologies is to provide people with a clear model, … so that they will develop a clear mental model
… but of course that depends on what they know already, their background, experiences, etc. etc.

24. Anna is the online sales agent, designed to be subtly different for UK and US customers
Does she meet users’ expectations in both countries?
How would you envision an interface like this in Egypt?

25. PACT analysis
People
Activity
Context
Technology

26. Activities
Designers need to understand the kind of activities people are doing when interacting with products.
The appropriateness of different kinds of interfaces and arrangements of input and output devices depends on what kinds of activities are to be supported.
For example, if the activity is to enable people to bank online, then an interface that is secure, trustworthy, and easy to navigate is essential.
The world is full of technologies that support increasingly diverse activities: send messages, gather information, write essays, control power plants, program, draw, plan, calculate, monitor others, play games – to name but a few.

27. Example: Gps tv in car
Need to characterize user activities and prioritize them. Which ones are safe? Which ones are crucial?

28. Characteristics of activities
Temporal aspects (frequent or infrequent):
Making a call versus changing phone battery
Safety-critical or not:
Controlling car brakes versus turning up the volume for the ratio
Data-intensive or not
Filling forms versus swiping a card
Vague or well-defined
Online shopping or browsing versus searching a specific item

29. PACT analysis
People
Activity
Context
Technology

30. Context
‘Context’ sometimes means things that surround an activity and sometimes what glues an activity together
Physical environment is one sort of context
ATM or ticket machine versus computer at home
Social context is important
Help from others, acceptability of certain designs
Organizational context
Management structure, differing work environments, etc.

31. PACT analysis
People
Activity
Context
Technology

32. technology Hardware and software to consider
Suitability of medium for different contexts/activities
• Input
How to enter data and commands into the system: point and click versus typing, etc.
• Output
Characteristics of display, content, and feedback

33. Which technology? Multitouch, speech, graphical user interface,
head-mounted display, 
augmented reality,
gesture-based

34. That was a trick question!
If you make a decision about technology without being aware of the people, activities, and context of a specific problem, you end up overlooking crucial requirements

35. 5 minutes break

36. From PACT to Requirements

37. From pact to Requirements
Activities (and the contexts in which they occur) establish requirements for technologies
Technologies offer opportunities to undertake activities in different ways
Designers try to design technologies within some domain (a ‘sphere of activity’) to meet requirements
In designing technology (which may be hardware, or software, or both), they may also change people’s activities
Dr Ayman Ezzat modified version of Dr, Frank Kriwaczek

38. What are requirements?
A requirement is a statement about an intended product that specifies what it should do or how it should perform.
For example, a requirement for a website might be that the time to download any complete page is less than 5 seconds. 
We need to make sure that the requirements are as clear as possible and that we understand how to tell when they have been fulfilled.

39. The process of interaction design
The process of interaction design involves four basic activities:
Establishing requirements
Designing alternatives
Prototyping
Evaluating.

40. The process of interaction design
Reqs Analysis
Design
Evaluate
Develop
A process for HCI production to ensure usability goals are met

41. The process of interaction design
Reqs Analysis
Design
Evaluate
Develop
many iterations

42. Example:
Imagine you have been asked to design an application to enable people to share their photos, movies, music, chats, documents, and so on in an efficient, safe, and enjoyable way.
What would you do?
How would you start?

43. How would you start? Sketching out how the interface might look?
Work out how the system architecture should be structured?
Simply start coding?
Ask users about their current experiences of sharing files?
Look at existing tools, e.g. Dropbox, and, based on this, begin thinking about why and how you were going to design the application?

44. How would you start? Sketching out how the interface might look?
Work out how the system architecture should be structured?
Simply start coding?
Ask users about their current experiences of sharing files?
Look at existing tools, e.g. Dropbox, and, based on this, begin thinking about why and how you were going to design the application?

45. Think.. Understand.. conceptualize
Having a clear understanding of why and how you are going to design something, before writing any code, can save enormous amounts of time, effort, and money later on in the design process.
Once ideas are realized into code, it becomes a lot harder to throw them away

46. Establishing requirements
Whatever the aim of the project, the users' needs, requirements, aspirations, and expectations have to be discussed, refined, clarified, and probably re-scoped.
This requires an understanding of the users and their capabilities, their current tasks and goals, the conditions under which the product will be used, and constraints on the product's performance.
We seek a stable set of requirements that forms the basis for the design phase

48. Usability is hard People (users) are all different
People are unpredictable
Design skill isn’t enough
Evaluation with users is required
Designer’s pride
New ways to think, break out of the box
Programmers stink at Usability

49. Programmers stink at Usability
Usability is hard
Programmers stink at Usability
don’t think like ‘normal’ people
know the software internals, technology first
enjoy systems more than people
arrogant (my software!)

50. Principles of Co-Design
The user  rather than being a passive recipient of a product or service, becomes an active co-designer of the product or service

51. Personas
Rich descriptions of typical users of the product under development that the designers can focus on and design the product for.
They don't describe real people, but are realistic rather than idealized.
Usually represent a synthesis from real users who have been involved in data gathering.
Each persona is characterized by a unique set of goals relating to the particular product under development.

52. persona
A description of the user's skills, attitudes, tasks, and environment.
Each persona has a name, often a photograph, and some personal details such as what they do in their leisure time.
Precise, credible details that helps designers to see the personas as real potential users, and hence as people they can design for.

53. Persona

54. Data collection for requirements analysis
Interviews:  development team members meet stakeholders and users feel involved.
Focus groups: carefully planned, attendees are carefully chosen, and specific deliverables are produced
Questionnaires: could solicit impressions/opinions about current services. Or get opinions about specific suggestions.
Observations: of participants in their natural setting to understand the nature of the tasks and context.
Indirect observation: Interaction logging and sophisticated web analytics are particularly useful for improving websites.
Research similar products and study documentation

55. Project weekly activity
Each project group is to choose 2 of the data collection methods for requirements analysis.
Use these two methods (e.g. observation and questionnaire) to collect data from ~5 people
Based on your collected data:
Identify PACT
Describe one persona

56. More details

57. Functional requirements
Capture what the product should do.
For example, a functional requirement for a robot working in a car assembly plant might be that it should be able to accurately place and weld together the correct pieces of metal.

58. Functional requirements example
For a video game?

59. Data requirements
Capture the type, volatility, size/amount, persistence, accuracy, and value of the required data.
All interactive products have to handle some data.
Example: real estate app  data must be up to date

60. Environmental requirements
Context of use – refer to the circumstances in which the interactive product will operate.
Four aspects:
Physical environment: how much lighting, noise, movement, and dust is expected in the operational environment.
Social environment: collaboration and synchronization
Organizational environment: are there facilities or resources for training? How stable is the communications infrastructure? How hierarchical is the management?
Technical environment: what technologies will the product run on or need to be compatible with, and what technological limitations might be relevant?

61. Experience-based Design (EBD)
What?
“A user-focused design process with the goal of making user experience accessible to the designers, to allow them to conceive of designing experiences rather than designing services.”
How?
Identify key moments and places:
Where people come into contact with the service
Where subjective experience is shaped
Where the desired emotional and sensory connection needs to be established
Work with front-line people who bring alive these touch points in the journey

62. Where systems fail
From an HCI perspective, systems can fail at any of the spikes of the wheel
(Scott’s slide here).

63. Steps to requirements analysis
Identify user tasks
Observe the way users achieve those tasks
Identify weaknesses and opportunities for improvement through new s/w
Suggest specific requirements
Sketch a design
Obtain user’s feedback
Prototype using the specified requirements