Assignment

• A project proposal: due on 2/28/23.
• A project summary/progress report due on 4/11/23, or an optional (formal) project presentation to be scheduled for the last 4 classes (with the presentation slides due the day before your presentation).
• A final project report: due on 5/2/23.

The details are given below.

Acceptable project types

• Usability requirements through ethnographic observations or other requirement elicitation/gathering techniques, typically directly involving the target users.
• Initial design and follow-up design evaluation-and-refinement cycles/iterations following user-centered design (UCD), participatory design (PD), or other UI design processes and related techniques..
• Choice of appropriate interaction styles and detailed design decisions with justification.
• Implementation of the UI design.
  (Warning: Don't get bogged down on this! The focus of your project should be on UI design and evaluation, not implementation.)
• Evaluation (of design, prototypes, and/or implementation) through expert reviews, usability testing, or other appropriate usability evaluation techniques. Pay particular attention to your concrete, and ideally some quantitative, usability metrics to be used for evaluation.
• Identification of problems for further usability improvement and/or for process improvement.
• Followup improvement cycles as a second (and third, and ...) iteration of some of the above steps.

• If you choose to focus on design, such as designing a new system and/or its UI, at least some evaluation needs to be performed to demonstrate its usability.
• If you choose to focus on the evaluation of an existing system, (or something you designed/implemented as part of this project), you still need to have some design elements, such as changed and/or enhanced I.S. with justification, design sketches of an improved/modified system/UI, etc. based on your evaluation results.

Several other considerations are also listed below:

• It's generally a good idea to consider multiple design techniques, evaluation methods, and interaction styles and actually use a couple from each category in your project to get a hands-on feeling of how different techniques, styles and methods work in practical applications.
• Try to be as specific as possible in each of your activities. For example, when you evaluate the usability of your system, consider:
  • What is/are your specific evaluation technique(s)?
  • How about other techniques that might be appropriate?
  • What's the basis for comparison (baseline)?
  • What usability metrics are to be used?
  • How to collection the data needed?
• For a project focusing on design, design prototypes of different levels of details are expected, and supported by the accompanying evaluation activities that lead to the subsequent refinements/modifications of the initial design.
• For a project focusing on evaluation, be sure to include some objective/quantitative usability metrics and related data (and analysis of the data). For example, you should not only relying on general survey feedback and/or subjective rating of the UI from expert reviews. Detailed data from usability testing and/or actual usage measurement data that can be used to quantify usability would be appropriate here.
• Although the minimal requirement is to go through one design-evaluation, or evaluation-design cycle, it would be an excellent idea to at least attempt part of a 2nd cycle, such as design-evaluation-redesign, or evaluation-design-evaluation (start with evaluation of the original design, and end with the evaluation of the modified/improved design).

Project proposals

• an informative title (e.g., "UI Design and Usability Testing of XYZ", but not just the generic title like "CS 8316 Project", or "XYZ UI"),
• a one-paragraph abstract (at the beginning of the proposal) to give a high-level overview or executive summary of your project (not just the system or its UI),
• introduction: clearly identify the problem that you are going to address (typically limited to one or two paragraphs),
• brief background information (no more than 1/2 to 1 page),
• a well-justified solution strategy you intend to use (most importantly: which design/evaluation techniques? which interaction styles? etc., and why?),
• expected results (and data to be collected, particularly to calculate usability metrics for UI evaluation) and related analysis to be performed,
• followup actions,
• a rough schedule,

• Please provide information regarding each team member's roles and responsibilities.
• The amount of work proposed for a group project should be appropriate (proportionally more) for the group size. As a general rule of thumb, if something can be comfortably done by a single student, it is not suitable as a group project.
• You only need to submit one proposal and one report for the project by one team member, with the other(s) submitting a note or a link giving information about who is the submitter of the team. The proposal and report must follow the same instruction as the individual projects.

Please keep in mind that by the time you submit your project proposal, we have only covered less than half of the class material, although an overview of the whole course is given at the beginning of the semester. Therefore, you may make certain modifications to what you proposed later on, but the basic framework, scope, and direction should remain fairly stable.

I'll provide written feedback to your submitted proposals. You need to address the issues I raised in your final project report. However, in most of the cases, you do NOT need to submit a revised proposal, unless I specifically ask you to do so. (I.e., in the rare case that your proposal is "unacceptable", I'll explicitly ask you to re-do/re-submit a revised proposal.)

Project summary (progress report) or presentation? The choice is yours

You are highly encouraged to do a (full) project presentation. In that case, you don't need to submit the project summary/progress report. Each presentation should last about 15 minutes, with appropriate numbers of slides. The presentation slides need to be submitted the day before your presentation. You need to highlight the problem/solution-strategy/results/analysis for us to get the basic picture, but not necessarily all the details, which would require much more than 15 minutes. One common mistake in the past is too much background information but not enough UI design/evaluation technical information.

The primary purpose of the project summary/progress report, or the presentation, is to share the results, findings, lessons learned with the rest of the class. I'll also provide some brief feedback to your project, especially in the case of project presentations (live feedback).

Project report

Several common mistakes to avoid:

• It is supposed to be a "report", not a set of "presentation slides". So, limit your use of lists/bullets, and put most of the material/discussions in paragraphs. Similarly, only figures and tables without corresponding discussions do not make a good report.
• Your project report must contain UI design/evaluation related technical information. In addition, you need to describe/discuss this information unless it is clearly self-explanatory.
• Important figures/tables should be in the report itself, not in the appendix, accompanied by relevant descriptions/discussions in the main text of the report. On the other hand, you shouldn't include large numbers of the graphs, models, etc. produced for the project in the report text itself. As I mentioned above, they can be included in the appendix, if you desire, together with other material, such as raw data, customer surveys, etc.