Assessment FAQs

These are questions about the assignments that have come up on the forum in 2025 and 2026, with the shape of the answer.

Answers marked Factual have a set answer in the specification. The rest are design decisions: there is no single right answer, and the answer given here is about how to approach the decision rather than what to choose. See Making Choices in a Design Project for how to make and defend those decisions yourself.

If your question isn’t here and isn’t answered by the specification, ask on the forum.

Any assignment

• My user’s habitat or body rules out the hardware I would normally reach for. Can I assume that away? Ignoring the constraint weakens the rationale, and changing the scenario is not available, so engaging with the constraint is part of what makes the design interesting. Say how in the rationale.
• Is a task that most people never do still an everyday task? Everyday means routine and recurring for the people who do it, not administrative or universal. The decision is then how much context of use to establish for a marker who may never have seen the task.
• Does the design need to be physically possible? It does not need to be a product today, but the physics is unchanged. A speculative technology is a stronger idea when grounded in what is actually known about the user and the technology, with gaps acknowledged as a limitation. A “magical” technology that makes the design problem disappear leaves you nothing to design.
• Is my idea too simple? A tutor said they would prefer something more complex. Complexity is not a marking criterion; quality is. A simple, compelling, well-executed idea beats a complicated one you cannot prototype or test properly. If the idea meets the specification, the decision about how far to push it is yours.
• Can I use Excel / a different tool / a method not taught in the course? Nothing is banned, but the course teaches defaults (Python with pandas and seaborn for analysis, paper prototyping for prototypes) and everyone has practised these defaults in tutorials. Using alternatives is your call: it is fine if it genuinely improves the work and you can support the choice, and a risk if it produces something you cannot analyse or test.
• Can I put the details in the materials folder, or link to an external site, and keep the main document short? Factual: the main document (and in A3, the video) is what gets marked. Materials exist so the marker can verify your work, not discover it. External links are not followed. If a figure, quote, or result matters, it goes in the main document.
• Can I reuse references from an earlier assignment? Factual: yes, as in any research project. Reframe the justification for the new context.
• How should I acknowledge generative AI use? Factual: a short list in the Acknowledgements section of what you used it for is appropriate. Full prompts are not needed. Undeclared use, and references that do not exist, fall under the N category.
• Should I use Generative AI to help with my assignment? We don’t penalise declared AI use in this class through academic integrity, but you should consider the problems with depending overly on assistive tools. Submitting a rationale, findings and discussion that are generic, or not tied well to your prototype and your participants is likely to score poorly in the assessment. Similarly, when deciding on a direction for an open-ended design task, an assistant asked what to build tends to give everyone the same common answer and will not show your individual capacity. The marker is looking for evidence of your process, and generic AI-generated ideas and text don’t show that.

Assignment 2: needs finding

• Can I narrow my study to one specific task or feature of the AI tool, rather than the whole tool? Yes, and you should. The specification asks for one context. One well-observed task gives you depth; many tasks give you breadth and thin data from 3–5 people. Explain why the context you chose is worth studying.
• Is X too small or too niche to count as an AI use context? If it fits the specification (students using AI in a specific situation in their lives) it is allowed. Whether it is a good choice is your decision and part of what is marked in the study plan: a well-justified narrow context is stronger than a vague broad one.
• Should my needs-finding study be designed around a statistical test? No. Design it to answer the research question. With three to five participants, descriptive statistics and clear plots are the appropriate analysis. Run a test only if a meaningful comparison arises, and be honest about its power.
• Can I use a validated instrument (SUS, NASA-TLX), adapt one, or add a small task or experiment? You can borrow from existing instruments and include a task, if the framing stays needs finding and you still gather participants’ own accounts of what they need. Adapting an instrument (changing its scale, dropping items) is acceptable if you say what you changed and why. Remember that the research question is given; you are answering it, not pursuing your own interests.
• Can my qualitative data come from open-ended survey questions instead of interviews? It can. Consider what you lose: needs finding depends on participants’ own accounts, and a survey box rarely gives you the follow-up that reveals a need. If you go this way, plan for it in your analysis.
• Should I ask the same questions before and after a task? A reasonable design, and one of many. The choice depends on your context and what you want to learn. Explain the procedure and why you chose it.
• My data does not split cleanly into quantitative and qualitative. Which section does it go in? Organise by the analysis you did, not by how the data looked when you collected it. Quantitative analysis in the quantitative section, qualitative analysis in the qualitative section. This maps to the rubric.
• How many themes should I have? How many quotes? There is no number but follow Charles’ rule of four (probably no more than four themes, each theme should probably have four or more words). Three well-supported themes that say something important beats eight that are really categories. A theme is a finding: it needs quotes, an argument, and a statement of why it matters for the research question. Codes and affinity diagrams are evidence of process; they are not the result.
• Is a photo of the interview enough evidence, or do I need transcripts? Factual: raw data goes in the materials folder. Transcripts or recordings, survey exports, photos of handwritten notes. A summary is not raw data. The marker needs to be convinced the findings came from the data.
• My numbers are all in the report. Why is the quantitative section marked as thin? Numbers are not findings. A mean or a plot indicates a finding that you then have to explain: what it says about the participants, the context, and the research question. Restating a table in prose is not analysis.
• Can I recruit participants from outside the class? Factual: no. All participants must be current COMP3900/6390 students, listed by uid. If recruiting goes wrong, talk to staff early; a small honest study beats a fabricated one.

Assignment 3: prototype and evaluation

• Does X count as non-standard interaction? (computer vision, AR, barcode scanning, voice, haptics, a physical device…) Mostly factual: the test is whether the interaction goes beyond a web app operated only by keyboard, mouse, or touchscreen. All of those examples pass. The amount of non-standard interaction is not a marking criterion; it is a design prompt to keep you away from yet another Figma web app. What is marked is the quality of the prototype.
• Can I have more than one focus (energy and waste, say)? You can, but be careful how much you attempt with one prototype and one small evaluation. Making that scoping choice well is part of the assignment.
• I have three research questions. Is that OK? The specification says a research question: one, incorporating your area of interaction, a problem, and a justification. Several questions usually means the study is not yet focused. If you designed the prototype first and are now looking for a question, frame the RQ as the inquiry that led to the design.
• Can I prototype the non-standard interaction as a simulation on a touchscreen or in a game engine? Software or hardware? Paper or code? Any of these can work. The requirement is that the prototype lets you test the interaction you designed with a participant. Figma alone rarely does this for non-standard interaction. Paper prototyping is the safe baseline everyone has practised; code or hardware is fine if you have the skills and it stays testable.
• How much of a Wizard of Oz prototype has to be real? Some of it. The expectation is that not everything works, but the parts that carry the experience you are evaluating should be real enough for a participant to react to. A real spray of scent, a real LED you switch on, a real sound from a phone will elicit better data than a box labelled “aroma dispenser”. Deciding which parts to make real is a prototyping skill and part of the assessment.
• My prototype has light, sound, or touch feedback but is paper-based. How do I test those? Coloured paper, sticky notes, an LED or torch, a sound played from a phone, and a wizard behind the curtain. There is no set answer: designing a prototype that enables testing is the task.
• Do I need to show sketches, iterations, and design process like in A1? Not to the same extent. The prototype criterion rewards a thorough design and prototyping process with consideration of user needs and a clear demonstration of the interaction in video. Show enough process that your design decisions are legible, then spend the time on the prototype and how it is tested. A real photo or video of the built prototype beats a drawing of it.
• My evaluation shows the prototype does not work. Do I need to build a version 2? No. Iteration is out of scope. Null or negative findings are fine if the data collection and analysis are valid. Reflect on whether the prototype and plan were testable in the first place; if they were, report honestly what you found.
• With five participants, should I run independent groups, repeated measures, or just one condition? Repeated measures is normal at this scale and gives you plenty of room to show rigour (counterbalanced ordering, for example). Independent groups with two or three per condition is possible but thin. Comparing against an existing interface is also an acceptable approach. Pick one and justify it.
• Does the evaluation have to be in person? Yes. The evaluation is of a participant actually using (or enacting use of) your testable prototype, and you need a photo or video of that happening. A survey or online form that shows a picture of the prototype is a survey about a design, not an evaluation of an interaction, and it cannot capture the non-standard interaction the brief asks for. If recruiting classmates is a problem, talk to staff early rather than designing around it.
• Can my participants compare my early concepts rather than test the prototype? Comparing concepts is useful design-process work, but it is A1-style ideation, not the A3 evaluation. Your data has to address a research question about the prototype you built, with participants actually using it.
• What counts as “justification from HCI academic research”? Both kinds: sources that describe the method you apply, and sources from similar projects that used it, ideally pointing to a gap your study addresses.
• Where do the conclusions go? Factual: in the first section, “Research Question, Plan, and Conclusions”. That is standard academic practice (introductions state the findings) and it saves you writing a separate conclusion. The headings are not flexible because they map directly to the marking criteria.
• Can I change the headings for better narrative flow? Factual: no. You can shorten them to fit a slide and add sub-headings underneath, but keep the structure.
• My spoken transcript is only 600 words. Is that too short for an 1800-word document? Factual: no. The document is secondary to the video and may be a transcript or slightly different text. The extra words are for captions, tables, and small elaborations, not a second, longer report.
• COMP6390: does the positionality statement go in the video? Factual: yes, and in the document. If it is absent from the video it scores zero.
• Can I show the prototype working during the video, edit multiple takes, or include a demo clip? Factual: yes to all. Everything counts toward the 5-minute limit and must be inside the one submitted video; external videos are not watched.
• Do I also submit my PowerPoint file? Where does the transcript go? Factual: no. Two things are marked: project-presentation.mp4 and project-documentation.md. The written version goes in project-documentation.md under the template headings, not in a separate .docx, .txt or second .md file.
• Can I generate the transcript with AI, or transcribe my recording with a tool? Write the words you will say, read them for the recording, then paste them in. A transcription tool is allowed but pointless. A document generated by AI is not your presentation and must be declared in the Acknowledgements like any other use.
• How many slides? Factual: at least 5, no more than 10. Title slides, personal introductions, tables of contents and reference slides are not required.
• Do citations go on the slides? A reference number on a slide is fine. When you cite in speech, say the authors’ names (“Froehlich et al. 2010”). The full reference list lives only in project-documentation.md; references put anywhere else, such as a materials README, are not found.
• My tables are eating my word count. Factual: the counter stops at the Participants heading, so participants, acknowledgements and references are free, but captions and table text are counted by design. If a table of raw numbers is costing you words, the raw numbers belong in materials and the finding they support belongs in the text.
• COMP6390: the positionality statement uses words I need elsewhere. Factual: the 1800-word limit is the same for everyone, and the positionality statement counts. The plan criterion is worth fewer marks for postgraduates, so be briefer there.
• Do I need to blur my participants’ faces? No. Participants in this course are not anonymous: they are classmates listed by uid, with consent. Blurring loses nothing in marks and gains nothing either.
• The video check fails but the file is right there. Factual: the file must be exactly project-presentation.mp4, lower case, in the top level of the repository, next to project-documentation.md, not in materials. If you renamed it, make sure the rename was actually committed and pushed. The length and resolution jobs only warn; the missing-file job fails.
• My video is too big to push. Factual: under 100MB, no Git LFS. Export from PowerPoint at 1080p and check the size before you commit, because git keeps every version you ever add. Only if it is 100MB or more, re-encode it: the exact ffmpeg command (and the equivalent HandBrake settings) is in the template README, and the whole export-check-compress process was demonstrated live towards the end of the week 11 lecture, Windows command prompt fumbling included. The same limit applies to recordings in materials.
• The markdown check fails. Read the job output: it names the rule and the line. Rules MD004, MD013 and MD041 are off; every other rule applies. Fix the lines it lists rather than guessing.
• The Participants check fails. Factual: one line per participant, exactly - u1234567 Firstname Lastname, 3 to 5 entries, no duplicates, not yourself, and not the example uid from the template.
• CI is slow or hasn’t started and the deadline is minutes away. Everyone pushes at the same time, so the pipeline queues. A queued pipeline is not a submission problem: push, check that your files are on GitLab in the web interface, and go to bed. Do not post the video on the forum or email it; it will not be accepted from there.