NUS SoC, 2012/2013, Semester I HCI Design Studio (COM1 2-02) / Tuesdays 10:00-12:00
HCI is inherently about people and computing systems. In the project, students will form teams to design something for someone. This theme can be reduced to two parts: the something and the someone.
Something may refer to a website, a tangible object, mobile application or other artefact.
Someone refers to a particular class of users. The projects do not need to be reduced to practice (i.e., "implemented" / "programmed"), but may be if the team wishes to do so.
Projects need to be cognizant and relevant to the HCI theories and phenomena which have an influence on their design. Projects will also need to have executed at least one round of evaluation and planned a second. Evaluations need to be detailed and feasible, and when executed, be accompanied by sufficient analyses. They should also consider human ethics protection, as discussed in Week 4.
Teams will need to keep weekly progress logs (suggest using a Google Docs spreadsheet as a weekly schedule). Here is a sample progress log, that assigns tasks to members and records progress and effort. Alternatively you can use other software engineering practices, such as a scrum task board to help you in your organization. Teams will also need to do at least a lo-fi prototype of their system (suggest using MyBalsamiq). Students are also welcomed to use (on a semester loan) a Microsoft Kinect sensor from Prof. Zhao's HCI lab if they would like to implement a project that would require such a sensor. Contact Min and CC: Prof. Zhao if you would like to use the Kinect.
Project themes: Min would like to suggest that you try design for someone other than yourselves (i.e., not non-handicapped young adults aged 18-25). However, it's true that you should largely design for people that you have access to, so please try to utilize your own social network and connections to try to design to satisfy this suggestion. Of course, it is a suggestion only, and there will be no penalties for groups who do design products or services for their own use.
Teams are encouraged to work on projects related to their culture, religion, ethnicity or extracurricular activities. Teams may also find working on projects underlying humanitarian causes or universal usability of interest. Min is also coordinating the Code For Science Singapore contest, so groups wanting to do projects based on this theme may also do so (getting leadership credit and possible cash prizes in the process). You can take a look at the three incomplete design briefs that I've written to help inspire your ideation.
Students will need to form mini-teams of 1-2 students each in Week 1. Min will then further group student teams with different backgrounds into project teams of 3-5 students by Week 3 for this assessment milestone. Each mini-team will be given the chance to state preferences about which other mini-teams they want to merge with to form project teams, although this will only be used for input by Min in the final allocation. This is done to ensure that students have a chance to work with different students and with at least some new students that they do not know.
Your team will need to practice good time management and project management to meet the requirements for the project. A simple model project schedule can be found here in GDoc, or from the top navigation menu. In particular, note that the course project emphasizes evaluation; as such, in the sample schedule, there is a separate column of tasks and roles for evaluation. You'll want to factor in your team members' workload; including when your members will have to give their student theory/phenomenon presentations.
Keep your project's scope small and focused, as for a term project, you'll be hard pressed to finish all that you have scheduled to accomplish. It's usually much easier to expand the scope of a small project than to shrink the scope of a large project. We recommend that you finalize the scope of your project no later than Week 5, allowing only minor changes to the project's scope after being informed by the results of your first evaluation.
Finally, because your project's grade is primarily based on the write-up and presentation, ensure that you have reserved ample time to create the poster and write-up, and if applicable, the optional video. The optional video may be helpful for your peers to evaluate your project if they miss your presentation to Min.
Find out more information about the pitch on its separate web page. This will be done on Week 3.
As one of the pedagogical goals of this course is to practice evaluation and research methodology in HCI, your team will be required to do evaluations of your projects as part the milestones for the course. Your team needs to carry out (at a minimum) at least one round of prototyping for the course project, and have planned one additional round. Most teams should be able to carry out two complete rounds of evaluation.
Timing: We suggest finishing the first iteration of the project prototype by the midterm break, and finishing the second iteration by Week 12, given that you need to also write-up your work.
Evaluation 1: Your first evaluation can be a quick evaluation with yourselves as design experts. This should be regarded as a formative evaluation, to help you narrow the design choices that you have come up with thus far. This can be a very effective model if your team has different people assigned to the design roles and the evaluation roles (or you can have two competing designs in the first round, where the designers of one model evaluate the design of the opposing model and vice versa). For this first evaluation, you can follow a cognitive walkthrough or a heuristic evaluation methodology. Importantly, you'll want to document this process so that it can be properly reported in the project poster and write-up. This means you should keep a log of the problems encountered through the evaluation method and the subsequent work that your team did to address those concerns (or discard them, with justification).
Evaluation 2: Although the project is only a term-length project, the second evaluation should be regarded as (partially) summative, evaluating the effectiveness of your product, application or service. For this second evaluation, you should not use yourselves as your evaluation team, but instead recruit subjects that are as close as possible to your intended (well-scoped!) audience. For a summative evaluation, you'll need to incorporate subjective usability metrics or acceptance tests (e.g., the SUS scale presented in Week 4). We suggest interviews or surveys for this second evaluation. Unlike the first round, you can relate the identified problems with your design to the subjective evaluation results and suggest fixes as future work in the body of the report. You should probably not attempt to fix the design problems discovered by the second evaluation (unless serious and easy to fix), as it may be better to focus your efforts on readying your project for presentation.
Optional Guest Project Evaluation: Min will also assign another project team to your aid your team in evaluation. This second team can be used in either the first or the second evaluation as guest evaluators, either as design experts (i.e., for the first, formative evaluation) or as interview or survey participants (in the second, summative evaluation). The assignments will take place by email.
In Week 8 (e-Learning week), and at any other time during the semester by appointment, your team may elect to get feedback about your project from me. You can discuss any aspect of your project, including roles and responsibilies, project scope, evaluation ideas and the report writing. To facilitate the mid-project check-in, you may find it useful to prepare a short slide presentation to focus your questions and needs. Such a presentation might be 5-10 slides in length and cover your teams' schedule, achievements, issues encountered, planned future improvements and the project's relation to HCI theories and phenomena that have been covered.
You may find the past mid-term check-in guidelines (that were in-class graded milestones) for the past the CS 4201 course helpful (taught by Prof. Zhao Shengdong). The site also has archived, sample check-in slides from previous group projects.
Each project team will need to create an A1-sized poster communicating your project's output (You'll need to convert part of your print quota to print them at the Technical Services; I suggest doing this early in the term when you have unused quota). The poster will need to show your project's key idea, needfinding results, prototypes, relationship to theories and phenomena in HCI, and evaluation plans and results. During the planned poster session during Reading Week, to be held as part of the SoC Term Project Showcase, your team will need to have the poster manned during the entire poster session; a presenter needs to be present for the presentation to Min (slots to be posted in the shared spreadsheet). The report and poster (both in .pdf) are due in the IVLE workbin by 2359 Tuesday 20 Nov 2012.
An (optional, but highly encouraged) video of at most 5 minutes can also be submitted. This video will need to present roughly the same information as the poster, but may do so in a more condensed version. Videos might be composed a bit like an advertisement or movie trailer, going through the application's motivation, showing a scenario of its use, pertinent design choices that need to be highlighted, and evaluations that were executed and a distilled set of results. The videos may be shuffle-played during the poster session, if space and facilities allow. If no video is presented, the poster and its presentation will take up all of the milestone's grading percentage (20% of the final grade). All teams must create a poster; there is no video-only option. You are welcomed and encouraged to give each other tips about best video and presentation creation practices on the IVLE forum. The video is due (if turned in) by 2359 Monday 19 Nov 2012 (to allow Min to collate them into a playlist for the Project Showcase.
The write up should be a comprehensive log of your project's outcomes as well as progress reports. It is an expanded version of your poster's content. For Min to be able to grade the project reports in a timely manner, the main body of the project report cannot exceed 20 pages, double spaced, single column, 11-point font.
It does not need to have prefatory material (list of tables and figures, and a table of contents), but does require at least two appendices (one for your evaluation details, and one for your schedule / progress log). Any academic references or websites referred to should also be clearly disclosed. Failure highlight your sources may end up deemed as plagiarism and subject to losing all 40% of the project grade.
To be fair, all teams may not use any other media aside from the poster, video and write-up to present information on their projects. You may create such media to help gain points with your peers in peer grading, but any other sources of information (webpage, demonstration, prototype) will be ignored by Min's official grading.
The project is worth a total of 50% of your grade, of which 5% was already evaluated in your pitches. 40% will be due to Min's evaluation of your poster (and video, if done) and your team's report. The remaining 5% will be due to peer-evaluation that will incorporate similar criteria as listed here.
The peer grading form looks like this:
|Evaluation 1: Comprehensiveness of the first formative evaluation with respect to study design, execution, results and discussion, and documentation.||(15%)|
|Evaluation 2: Comprehensiveness of the second larger-scale evaluation with respect to study design, execution, results and discussion, and documentation. Note the higher weightage for second evaluation.||(20%)|
|Theory / Rationalization: Project's connection and rationalization with respect to HCI theories and phenomena learned in class or self-taught.||(25%)|
|Needfinding, Design: Comprehensiveness and documentation of the non-evaluative parts of the project, including needfinding, designing and prototyping.||(20%)|
|Polish: Project presentation and report presentation, polish and formatting.||(15%)|
|Miscellaneous: Other miscellaneous aspects. Can reward up to five additional points (10 out of 5). Extra evaluation, video presentation, implementation, difficulty, or other differentiating factors.||(5*%)|
Min's grading form looks like this. It is pretty much identical to your form except a bit different emphasis for the poster/video and the report. For space, I've compressed both the poster and video form in the left column and the report in the right column (Note this is not finalized, grading criteria and marks subject to change).
|Description||Poster and Video Percentage||Report Percentage|
|Evaluation 1: Comprehensiveness of the first formative evaluation with respect to study design, execution, results and discussion, and documentation.||(10%)||(15%)|
|Evaluation 2: Comprehensiveness of the second larger-scale evaluation with respect to study design, execution, results and discussion, and documentation. Note the higher weightage for second evaluation.||(15%)||(20%)|
|Evaluations - Report Comprehensiveness: Does the report contain all the necessary details to recreate the evaluations? Data (both raw and interpreted) are well-organized into main body materials and/or appendices?||--||(15%)|
|Theory / Rationalization: Project's connection and rationalization with respect to HCI theories and phenomena learned in class or self-taught.||(20%)||(20%)|
|Needfinding, Design: Comprehensiveness and documentation of the non-evaluative parts of the project, including needfinding, designing and prototyping.||(20%)||(15%)|
|Polish: Project presentation and report presentation, polish and formatting. Includes timeliness of presentation, (video) scenario/roleplay||(30%)||(10%)|
|Miscellaneous: Other miscellaneous aspects. Can reward up to five additional points (10 out of 5). Extra evaluation, video presentation, implementation, difficulty, or other differentiating factors.||(5*%)||(5*%)|