1

SE 204 – Human Computer Interaction

Lecture 3: User-Centric DesignLecturer: Gazihan Alankuş

2

User Centered Design

• The following slides are based on Tom Yeh’s intro HCI class at UMD– https://wiki.cs.umd.edu/cmsc434_s10/index.php?title=

Main_Page

• There are also slides from Eric Ries– Eric Ries (@ericries)– http://startuplessonslearned.blogspot.com

3

Principles of User Centered Design (UCD)

1. Early focus on users and tasks2. Iterative design with prototypes3. Empirical measurement on prototypes

4

Why build a UI?

• Computerize a logistical process– E.g., inventory control, restaurant order taking

• Upgrade an outdated UI– E.g., Terminals -> Web -> Web 2.0

• Expect that people will use it– E.g., dot com craze, mobile apps

• Apply a novel technology – Software: sentiment analysis– Hardware: gyroscope

5

1984 Summer Olympics

6

Problem

• Athletes need to communicate– Athletes want to receive support from families and

friends who are far away– Athletes want to talk to other athletes in other villages

• Problems– It is a huge event!– There are people from all over the world

7

Solution: Olympic Message System

8

Challenges

• 10,000 busy Olympic athletes• When there is a call, they will probably be busy

training or sleeping• Many family members and friends • 50 different languages• No cell phones• Many with no experience with computers• Some with no experience with a push button

phone

9

Things at Stake

• Everyone is watching• No delay• No second chance• Subject to sabotage and abuse

• Ideal situation for the business question:– “What would you do if you had all the resources in the

world?”

10

Training is Difficult

• Hard to run training classes since the campus is large

• Impossible to train off-site non-Olympian callers

11

Design Process

• Ran scenarios with Olympic committee• Wrote user guides before creating the system• Live lab simulations• Consulted with ex-Olympian• Tested on friends and families • Tested on users overseas• Hallway prototype• Crash test• Pre-Olympic field test

12

Benefits of UCD

• Prevented well-intended but counter-productive changes from bosses– User-centric!

• Pruned wrong directions early– Prototypes

• Sped up the development process– It’s easier to develop when you know what to do and

why

13

Sample DialogUser: (Dial 8540.)OMS: Olympic Message System.

Please keypress your three-letter Olympic country code.Systeme de Message OlympiqueTapez le numer de votre pays, s’il vous plait.

User: USAOMS: United States. Les Etats-Unis.

Please keypress your last name.User: goulOMS: John Gould.

Please keypress your password.User: 319OMS: Welcome to Olympic Message System.

New Message from Stephen Boies.

14

What can we learn from this?

• Focus on the problem, not on features of possible solutions

• Identify requirements well• Extensively test your ideas before implementing

them

15

What are you focusing on?

Users

Computers

16

What are you focusing on?

Users

Computers

WHAT?

HOW?

Requirements

• The answer to the what/who question– What do the users need?– What is the problem?– Who are the users?

• Not the how question– How should we develop the system?– How will the user use it?– How will the user perform the payment?– How will the data be stored?

Requirements

• Goal: identify users and tasks– USERS: Who will use this?

• How do they think?• What do they like/know?

– TASKS: What do users need to do with this software?• What tasks do we need to support?

19

Idea!

• Let’s build an iPhone app to make money!– TV remote controller

20

In a perfect world…

Develop

Deliver$$$$$$$$

Users

21

In reality

Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug, Code, Debug,

Deliver$

Users

22

What did we do wrong?

• Sat down to code a vague idea.• Did not do any planning

Design First!

23

Let’s do some planning first

Develop

Deliver$$

Users

Plan

24

Also known as the waterfall model...

Develop

Deliver$$

Users

Plan

25

Waterfall Model

Develop

Deliver$$

Requirements

Design

Test

Users

26

Waterfall Model

• Proposed in the 70s– For manufacturing and construction industries

• Linear process• Assumes 100% completion before advancing to the

next stage– Sometimes assuming that you are superhuman!

• Each stage has a concrete deliverable– Emphasis on documentation

27

What if users don’t like what you created?

Develop

Deliver$$

Requirements

Design

Test

Users

28

Get users involved early!

29

Get users involved early

Develop

Deliver$$

Requirements

Design

Test

Users

Users

Users

30

Users are not always right the first time!

Develop

Deliver$$

Requirements

Design

Test

Users

Users

Users

“People don't know what they want until you show it to them.”

― Steve Jobs

31

Users are not always right the first time!

Develop

Deliver$$

Requirements

Design

Test

Users

Users

Users

“People don't know what they want until you show it to them.”

― Steve Jobs

32

Where most of the problem lies

• You cannot fully understand what users need• Users are not always right!

33

Iterations are very costly!

Develop

Deliver$$

Requirements

Design

Test

Users

Users

Users

These steps are long with concrete deliverables They assume 100% is done before advancing to the next

34

Make iterations cheaper!

35

Spiral Model: smaller scale iterations

Develop

Deliver$

Requirements

Design

Test

Start

36

Spiral Model: smaller scale iterations

Develop

Deliver$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

37

Spiral Model: smaller scale iterations

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

38

Spiral Model

• Steps do not assume that 100% is done– They acknowledge that it is incomplete and there will

be more iterations– There is less emphasis on documentation

• Iterations are cheaper and plenty– Project shapes up as iterations continue– At every iteration, a candidate solution is improved to

create another candidate solution

39

Design iterations: Rochester Digital Library

40

Design iterations: Rochester Digital Library

41

Design iterations: Rochester Digital Library

UCD in Spiral Model

42

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Users

???

Early focus on users

43

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Prototyping

44

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Keep users in the loop

45

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

46

Meeting Users’ Expectations

• It’s not about adding features• Support users’ goals• People will not form unreasonable expectations

47

Benefits of keeping users in the loop

• Adequate and timely training• Ownership

An option: participatory design

48

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

49

Remember the Three Principles of UCD

1. Early focus on users and tasks2. Iterative design with prototypes3. Empirical measurement on prototypes

50

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Sample project loop (homeworks will be modeled after these)

Proposal (idea)

51

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

User and task analysis

52

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Design sketches

53

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Paper prototypes

54

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Computer prototypes

55

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

56

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Implementation (even more iterations)

Acceptance testing

57

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

Delivery

58

Develop

Deliver$$$$$$$

Requirements

Design

Test

Start

Design

Requirements

Develop

Test

Requirements

Design

Develop

Test

59

Why is it difficult to develop good software?

• Because there are too many unknowns• When you write code, you make assumptions and

commit to decisions– You should minimize the dependency of your

assumptions on opinions. Rather, they should depend on facts and observations.

60

Here’s how most startups are operated

• Agile development• Product and customer development• Lean startup

Problem: Known Solution: Unknown

“Product Owner” or in-house customer

AgileUnit of progress: a line of working code

Problem: Unknown Solution: Unknown

Product Development at Lean StartupUnit of progress: validated learning about customers ($$$)

63

Iterative Loop

IDEAS

CODEDATA

BUILDLEARN

MEASURE

64

An overview of all homeworks in this semester

• Come up with new software ideas• Requirements analysis with users• Sketches, storyboarding and paper prototypes• Testing prototypes with users• Creating computer prototypes

65

We will announce Homework 1 tomorrow

• In the meantime you can start thinking about it– You will come up with three problems that can be

solved with software• Either there should not be existing software similar to it• Or users should have major problems with the current

solutions

– You should have access to potential users for this software

– You will interview at least one user for each category and report your findings

66

Midterm date

• July 31st!