CS 5/7312 (Spring 2024): Course Project
Assignment
Your project is an integral and the most important
part of your learning experience in CS 5/7312.
It must include both the critical elements of UI design and evaluation (UX),
with possibly other elements in the UI/UX process as well.
Project related activities will consist of three stages:
-
A project proposal:
due on 2/13/24.
-
A project progress report
due on 3/26/24,
or an optional (formal) project presentation
to be scheduled for the last 4-5 weeks of classes
(with the presentation slides due the day before your presentation).
-
A final project report:
due on 4/29/24.
It can be either an individual project or
a comprehensive group project.
The details are given below.
Acceptable project types
The project should be an application of some specific
UI design AND evaluation (UX) techniques/models
for a new or existing program/product/application/service/etc.
Your project should include several of the following important elements:
-
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 frameworks/methodologies 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.
The most important elements are the design AND evaluation
activities performed by you.
An acceptable project must include BOTH these
elements and related activities,
although you may choose to focus on one while only performing
limited amount/scope of activities on the other.
For example:
-
For a project focusing on design,
such as designing a new system and/or its UI,
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.
In addition,
at least some evaluation needs to be performed to demonstrate
its usability.
-
For a project focusing on evaluation,
such as evaluating an existing system,
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.
In addition,
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.
For a group project, typically consisting of two team members,
both the design and evaluation aspects must be extensively covered.
In addition, more elements among the above
(and/or with more in-depth treatment of these elements),
a larger system,
and more
detailed/elaborated design/(possible implementation)/evaluation/repeating-the-cycle
activities should be included,
appropriate for the group.
The group size of 3 or more needs special approval from the instructor.
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?
-
Most importantly,
it's a project where you design/(possible implement)/evaluate ("do") UI for some system
and report the activities/results/findings/etc.
Therefore, a general discussion of or even a comprehensive survey about
UI/UX and related topics and activities will not be an acceptable project.
Difference in 7312 and 5312 projects:
-
For 5312:
The minimal requirement is to go through one design-evaluation,
or evaluation-design cycle,
-- this is the requirement for undergraduate students enrolled in CS 5312.
-
For 7312:
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).
Of course, I don't expect a full re-design, or a full re-evaluation.
Graduate students enrolled in CS 7312 are required to included such
2nd round of re-design or re-evaluation activities in their projects,
in addition to the first design/evaluation or evaluation/re-design cycle
required for all students above.
Project proposals
Your project proposal should be around 3-4 double spaced pages
in length, and should include the following information:
- an informative title (e.g., "UI Design and Usability Testing of XYZ",
or "Usability Evaluation and Redesign of XYZ",
but not just the generic title like "CS 5/7312 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,
In case of a group project, please also pay attention to the following:
-
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, one progress report,
and one final 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.)
Progress report
All the students are required to submit a progress report,
if you are not doing a full presentation (see below) in class
or on recording.
Your progress report should focus on project progress you made so far,
i.e., the main activities and results from your project
after the proposal submission/review/feedback cycle.
Here are some specifics about the progress report:
-
Your progress report should be around 3-4 double spaced pages
in length,
or about 6-8 slides in presentation slide format.
-
A brief summary of what you proposed earlier should be included,
1/2 to 1 page.
-
Focus: progress so far, post-proposal stage,
including data collected from ethnographic
observations/surveyors/execution logs/etc.,
design (prototypes) constructed,
usability testing and/or other evaluation activities performed,
result analysis, etc.
-
What remain to be done (progress vs plan/proposal),
and when.
I'll give you written feedback for all the progress reports submitted,
which should be incorporated into your final project report.
Optional project presentation
You are highly encouraged to do a (full) project presentation.
In that case, you don't need to submit the progress report
described above.
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 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
verbally live feedback), and may followup with some additional
written feedback,
so that you can make some adjustments to your project before
submission of the final report.
Project report
The project report should be around 15 double-spaced pages in length,
but no longer than 20 pages for an individual project
or 25 pages for a group project.
The report should clearly and comprehensively states the background,
problem, strategy, activities, results, result analysis,
lessons learned, followup actions, and a high level summary
(and an abstract at the beginning).
Each section should be clearly marked,
preferably using numbered section headings
(see, for example, the papers P1-P3 from our research group at SMU
available on Canvas/"Files").
Additional material, such as graphs, models, etc. produced,
information sources and raw data,
customer surveys, etc., can be included in the appendix and clearly
marked as such (so it will not be counted towards your 20 or 25 page quota).
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.
Most importantly, it's a report about what you did in UI design
and evaluation (and other activities) yourself.
Therefore, a general discussion of or even a comprehensive survey about
UID and related topics/activities will not be suitable.
(An unacceptable project. See "acceptable project types" earlier.)
Prepared by Jeff Tian
(tian@smu.edu).
Posted: Jan. 31, 2024.
Last update: Feb. 6, 2024.