CSC 484 Lecture Notes Week 2

CSC 484 Lecture Notes Week 2
The Process of Interaction Design (ID)

Relevant reading.
1. Textbook Chapter 9.
2. Paper of the fortnight (covering both weeks 1 and 2, due to short week 1):
  Investigating attractiveness in web user interfaces by Hartmann, Sutcliffe, and De Angeli, from the University of Manchester.

Assignment 1 presentation schedule.

Unless specific teams want to volunteer to present earlier, the following is the schedule:

Day Time Team
Mon, Apr 14 12:10 - 12:34 Sports
12:34 - 1:00 PDF

Wed, Apr 16 12:10 - 12:34 IM
12:34 - 1:00 Mail

Fri, Apr 18 12:10 - 12:34 Music
12:34 - 1:00 Word

The ordering rationale is that smaller, more ad hoc created teams go later.
Note that all written deliverables, including presentation slides, are due on Monday, even for teams that present on Wednesday and Friday.

This week's lab schedule:
1. Monday -- discussion with each team on assignment 1 progress; use free time to work on Assignment 1.
2. Wednesday -- full-class discussion of current research paper; remaining time available for A1 team work.
3. Friday -- 25 minute quiz; remaining time available for A1 team work.
More on the Wednesday lab discussion of the current research paper.
1. Please read it by then.
2. If you have any opinions, strong or otherwise, please bring them.
3. Specifically,
  1. Do you buy it, i.e., that quantifying attractiveness is worthwhile?
  2. Is there any real science going on here?
  3. Overall, do you give it a thumbs up or down?
Introduction to the ID process (Section 9.1).
1. It has much in common with the SE process, particularly a user- centered SE process.
2. Both have a fundamental goal of developing a product.
3. The high-level steps of the ID process, as presented on Page 17 of Section 1.5, are:
  1. Identify needs and establish requirements for the user experience.
  2. Develop alternative designs that meet the requirements.
  3. Build interactive versions of the designs that can be communicated and assessed.
  4. Evaluate what is being built throughout the process, from the perspective of the user experience.
What is involved in ID? (Section 9.2)
1. Again, the notion that the process is user-centered is a fundamental tenet of ID.
2. For software that involves an end-user, this should also be a fundamental tenet of a good SE process.
3. As you may recall from your SE class, there are types of software that do not involve much if any human end-user interaction.
  1. These include systems software and embedded software.
  2. For these categories of software, human user-centered design is necessarily not appropriate.
4. As we studied in CSC 308, showing users concrete examples of design alternatives is recognized as a highly effective way to involve them in the process.
  1. Show them sketches.
  2. Describe things in prose.
  3. Draw diagrams, appropriate to users' application domain.
  4. Show them interface prototypes.
5. A critique of the book's Box 9.1 on "The value of prototyping".
  1. Yes indeed, it can be very valuable.
  2. I'm not sure the chosen example motivates this particularly well.
  3. What they're getting at is the value of prototyping to attain full user engagement.
  4. There's a delicate balancing act to build a prototype as rapidly as possible, that has as much of what the user cares about as possible, with as little of the time-consuming implementation details as possible.
Importance of involving users (Section 9.2.1).
1. We said it plenty in 308.
2. We'll say it plenty here in 484.
3. The fancy term "expectation management" means simply this:
  1. Don't build up users' expectations with a bunch of hype about what the product could look like, and then deliver them something else.
  2. Rather, show them all along what it will look like, and deliver them that.
4. User involvement also helps develop a sense of ownership, which can be psychologically very important.
Degrees of user involvement (Section 9.2.2).
1. Levels of user involvement, from high to low:
  1. Users are paid permanent members of the development staff, and perform project management duties.
  2. Users are interim paid members of development staff, but the same users do not necessarily participate throughout the entire development period.
  3. Users are involved on a voluntary basis, for differing periods of time.
  4. Users participate indirectly, through paid representative with whom the users consult.
  5. Users are regularly surveyed and involved in studies, but do not participate on a day-to-day basis.
  6. Users are recruited "off the street" to evaluate the product at various stages of development.
  7. Users are "simulated" by product marketing staff and/or other development team members.
2. Choosing which level(s) of user involvement is very organization and product specific.
3. Broadly,
  1. Products for a particular organization can involve actual end users who work for the organization.
  2. Off-the-shelf products typically involve represented users, with actual or prospective users recruited at selected intervals for evaluation and analysis.
"Obvious" definition of user-centeredness (Section 9.2.3).
1. Early focus on users and tasks.
  1. Users' tasks and goals are the driving force.
  2. Users' behavior and context are studied.
  3. Users' characteristics are captured.
  4. Users are consulted throughout.
  5. All design decisions are taken within users' context.
2. Empirical measurement.
  1. Identify and agree upon usability goals at the outset.
  2. Use them to evaluate continuously.
3. Iterative design
  1. Show the users something concrete.
  2. Get their feedback.
  3. Repeat until done.
Practical issues (Section 9.3).
1. Who are the users?
2. What do we mean by "needs"?
3. How do we generate alternative designs?
4. How do we choose among the alternatives?
Identifying the users (Section 9.3.1).
1. The book broadens the discussion of users to stakeholders.
2. This term is well known in SE circles, and includes the following types of people:
  1. end users -- people who will actually use the product or people who represent those who will use it
  2. customers -- people who purchase or procure the product, which they may or may use directly themselves
  3. domain experts -- people who fully understand the application domain in which the product will be used
  4. developers -- members of the development staff who do the design and implementation
  5. evaluators -- members of the development staff who specialize in product evaluation
  6. managers -- those who manage the development process, as well as those who manage end users when the product is installed in an organization
  7. visionaries -- those who have the "big picture" for the product and how it will be developed
  8. other interested parties -- anyone else interested in the product, including those with a financial investment, or those whose businesses or lives might be directly or indirectly affected by the product or its use
Identifying user needs (Section 9.3.2).
1. Some needs can be articulated directly by users, when we ask them.
2. Other needs are based on observed or measured user characteristics, including physical, behavioral, psychological, and social.
3. We can often understand new needs based on how current needs are met.
4. E.g., a 2000 CHI study found users' non-electronic habits can be a good basis for understanding their needs for a web-based software product.
Generating alternative designs (Section 9.3.3).
1. Start by looking at what else is out there (this should in fact be an explicit part of the process).
2. Consider incremental improvements to existing solutions.
3. Talk to people with (vastly) different backgrounds to gain different insights.
4. Introspect on your own creative processes for tasks other than developing software.
5. Draw analogies from how you solve other types of problems.
6. And, alas, talk to your lawyer about potential copyright and patent infringements (sorry, but it's the society in which we live).
Choosing among alternative designs (Section 9.3.4).
1. Examine external factors -- does the user like the design?
2. Examine internal factors -- is the design implementable?
3. Determine how best to present design alternative to the users:
  1. Prose descriptions, with descriptions and diagrams.
  2. End-user scenarios.
  3. Prototypes.
4. Clearly define quality criteria.
  1. Performance.
  2. Functional characteristics.
  3. Aesthetic characteristics.
5. Develop quantifiable usability criteria (more in coming weeks).
Lifecycle models -- the ID process meets the SE process (Section 9.4).
1. This should be familiar territory from your SE classes.
2. The authors sketch out a very simple ID process model in Section 9.4.1
3. Section 9.4.2 is a rehash of well-known SE process models.
4. Section 9.4.3 is the HCI wrinkle on things.

The ID process mapped to SE processes (Section 9.4.1 + 9.4.2).

ID	Traditional SE	Agile SE
`Identify Needs and`	Analyze	Analyze
Establish Requirements	Requirements	Requirements
		Test
Develop Alternative Designs
Conceptual Design	Specify Model	Refactor (later)
Physical Design	Design Interface	Design Interface + Code
Build Interactive Versions	Prototype	Implement
Evaluate	Evaluate	Evaluate
	Test (pervasively)	Deploy (partial functionality)
Iterate	Iterate	Iterate
	Design Code
	Implement Code
	Deploy


	Iterate

The Agile process generally involves more frequent iterations, with smaller work products per iteration than does the typical ID or Traditional SE process.
Design is often not an explicit step of an Agile process, but the interface design step needs to be part of an Agile process that includes ID.
The ID Evaluate step is often not an explicit part of an SE process.
1. The difference between Evaluate and Test is that the former focuses purely on end-user evaluation, with the latter focusing on functional system testing.
2. End-user evaluation could be considered part of a pervasive testing step, but it's better to show it separate.
3. This emphasizes that ID evaluation is a different kind of activity than SE system-level software testing, i.e., unit, module, and regression testing.

Process models in HCI (Section 9.4.3).
1. The Star model.
  1. Do traditional steps of analyze, design, implement, and prototype in any order.
  2. Always do evaluation after each step.
  3. This can be viewed as an iterative SE process, where steps can be skipped on any give iteration, and evaluation is pervasive.
2. The Usability engineering model.
  1. Can be mapped to any SE model.
  2. Adds more details to requirements analysis phase, including user profiling and defining usability goals.
  3. More clearly defines the specifics of user-centered evaluation, i.e., expands the Evaluation step.
3. ISO 13407 human-centered design standards -- nothing really new here vis a vis all the other process models.
Some general observations from the SE side of things.
1. The ID process as presented in the book is very skimpy on details.
2. To get a real product to market, one must address the kind of managerial and procedural details that are part of most good SE processes, such as version management, bug tracking, and regression testing.
3. The value-added part of the ID process is the introduction of user evaluation as an explicit and pervasive part of the process.
4. The notion that software engineers under appreciate user involvement is far less true today than it was ten or fifteen years ago (when a lot of the studies the book cites were published).
5. However, software engineers probably do under appreciate the importance of quantifiable usability analysis as an integral part of the SE process, which again is the significant contribution of considering the process from the ID perspective.

Day	Time	Team
Mon, Apr 14	12:10 - 12:34	Sports
	12:34 - 1:00	PDF

Wed, Apr 16	12:10 - 12:34	IM
	12:34 - 1:00	Mail

Fri, Apr 18	12:10 - 12:34	Music
	12:34 - 1:00	Word