Overall, we were very impressed with the quality of work that all of you put into this demanding assignment. One main criterion for grading was judging the consistency of the task analysis. Specifically, we expected the final interface sketches to reflect the tasks identified from the interviews which were prepared through the problem description and questions. Here are some other thoughts we had while grading:

• Please follow the submission instructions
• Please keep projects to 5 printed pages-- if Netscape prints out 6-7 that's ok, but the longer the project is, the less fair to other students and the less leeway the graders have for mistakes.
• Keep your project in the format requested in the assignment (some people had extra sections before the background while others did not do a scenario walkthrough)
• Make comments that fall within the scope of the project-- 2 students talked about GPS devices for helping customers wayfind to pick up their pizza. But this analysis brings up an entirely different problem since one could walk to pick up their pizza, drive in a car without any technology that can support navigation (aside from the steering wheel), or perhaps in a car that is GPs enabled. .
• Discussions about technology (cookies, java applet) are secondary to design considerations (no discussion of technology was needed in this assignment aside from an understanding of what a simple HTML web page is).
• Paragraph Summery
• Should be a concise paragraph
• Should state the scope of your problem. Some people just mentioned "web interface" but did not discuss the scope of the project (1 company, for many pizza companies, kiosks)
• Task Analysis Questions
• These should be questions
• Make them relevant to the tasks involved-- asking about the height of the interviewee and not discussing any ergonomic details in the delivery process is irrelevant
• Should be specific-- questions like "what do you do when you get pizza?" should be broken down into areas such as "do you ever look at a printed menu before you call a parlor?" "Is there a place in your house that you keep menus?)
• Should not circumvent the design process-- e.g. asking "Will you prefer a web interface or a telephone one" without showing a finished interface is not a valid question. If the participant says they prefer the telephone that doesn't mean the design has to give up. Also asking people about Kiosks were similar.
• Interviews
• Ask participants the questions you prepared in your task analysis.
• Talk with the decision makers for pizza ordering. (e.g. a few people interviewed young kids, but if they rely on an adult to place their order, the interview should include both)
• Existing Tasks
• Do these tasks reflect what the users do (that were interviewed or observed)?
• Are these tasks unique (e.g. a task for ordering pizza and one for exchanging money are not distinct)?
• If you decomposed the tasks by user types, was the decomposition helpful? (see tables below)
• New Tasks
• Do they reflect what people want?
• Do they fulfill what is stated in your problem requirement?
• Scenarios
• Are the people in the scenarios representative of your interviewees?
• Do they step though your main tasks?
• Interface Sketches
• Does your design support the new tasks of your system?
• Should be clearly organized
• Low-fidelilty prototypes was all that was expected.  Some people put a lot of effort in using an interface builder which was not necessary.
• Scenario Walkthrough
• Does you interface handle a particular scenario from start to finishfor ordering pizza?

People who discussed in-store kiosks and observations received extra credit. Very few people listed one or both since this was such a large assignment and it was not mentioned again in the what to turn in section

A note on tables some people used for their task analyses:

Some people used tables to compare tasks among different user populations.  User populations should account for distinct and representative groups.  For example, one may choose an infrequent customer versus a pizza junkie.  Both of these groups will probably have distinct ways of interacting with the system and they both account for a large part of your population.  You may end up with a breakdown as follows:
 

	User Type X	User Type Y	User Type Z
Task 1	43%	10%	76%
Task 2	40%	90%	15%
Task 3	75%	40%	73%

Less successful were analyses of user types into arbitrary categories such as hair color (well, this is my example) which is not a meaningful category. The results were not very interesting:
 
 

	User Type A	User Type B	User Type C
Task 1	10%	10%	10%
Task 2	40%	41%	41%
Task 3	75%	75%	73%

In both cases, we looked to see if the interface matched user task frequency (e.g. if users frequently wanted to use a menu than the interface should reflect that).