Week 8: Frequently Asked Questions
Assessment
Section titled βAssessmentβHow do I do well in ENT208TC?
Section titled βHow do I do well in ENT208TC?βπ¬ βHow to get 100 in ENT?β β²11
Show your thinking, not just your output. The pattern is the same across every deliverable: say what you did, and say why.
Some deliverables are group work β your team writes one shared Validation Report and one Technical Documentation. The quality of the reasoning in those documents reflects the whole team.
Some deliverables are individual β your Dev Log entry is yours alone. Write what you personally did this week. One paragraph, in your own words. If two people worked on the same task, describe your specific part β not the task itself.
Validation Report: Describe what happened in your sessions. βWe moved the button after three users could not find it β in the next session they found it immediatelyβ is stronger than βusers found it easy to use.β
Technical Documentation: Explain why you chose each tool. βWe chose Supabase because it generates a full API from our database β the frontend can read and write data directly from the browser without any server codeβ is stronger than βwe chose Supabase because it is a modern backend.β
Demo Day: Be ready to explain every decision you made β not just what you built.
My product is not finished. Can I still present at Demo Day?
Section titled βMy product is not finished. Can I still present at Demo Day?βπ¬ βCan I demonstrate partial functionality at Demo Day?β β²1
Yes. Your validation evidence and Dev Log matter as much as the live demo. A product that is honest about what is missing β with clear reasoning β is a strong presentation.
When one part cannot be demonstrated live:
Some components may not be ready in time. A water pump that is not yet connected. Data from an external system like Learning Mall that you cannot access during the demo. You do not have to skip that part entirely.
Instead, you can simulate the component (this is called a mockup) β show how it would work using stand-in data or an alternative demonstration. The key condition: the rest of the product must still work end-to-end. You are substituting one specific part, not replacing the whole demo with slides.
Examples of acceptable simulation:
- Data you cannot access: Hardcode realistic sample data in your app so the interface works from start to finish β the user can see exactly what would happen with real data.
- Hardware that is not yet connected: Demonstrate the component working in isolation (the motor turns, the sensor gives a reading), then explain live how it fits into the full system.
This requires Pathfinder approval.
What counts as an acceptable substitution depends on your specific product and assessment criteria. Discuss your plan with your Pathfinder before Demo Day. If your Pathfinder is unsure, your group and Pathfinder should approach the Module Leader together.
View the assessment brief on Learning Mall β
Our finished product has changed from what we described in the project brief. Is that a problem?
Section titled βOur finished product has changed from what we described in the project brief. Is that a problem?βπ¬ βAre we required to make the finished work completely identical to the project brief, including all listed functions?β
No β deviations from the brief are normal and expected. Iteration is the point. If you built exactly what you planned in Week 4 without changing anything, that would suggest you did not learn anything from user testing.
A deviation only becomes a problem if the end product is completely unrelated to what you originally proposed β a different problem, a different user, a fundamentally different solution. Small changes in scope, dropped features, redesigned flows, and pivots within the same problem space are all fine.
In your Demo Day presentation: if you dropped or changed a planned feature, say so and explain why. βWe originally planned X, but testing showed users never used it β so we cut it and focused on Y.β That is a stronger answer than pretending the change did not happen.
Which matters more for assessment β the user pain point or the iteration process?
Section titled βWhich matters more for assessment β the user pain point or the iteration process?βπ¬ βCould you please advise which part should be prioritised, the user pain points or the iteration process?β
Both matter, and they work together β you cannot score well on one while ignoring the other.
The pain point establishes that the problem is real. Without it, assessors have no reason to care about your solution. Show evidence that real users have this problem: a quote, an observation, a finding from your early research.
The iteration process shows that you responded to what you learned. A pain point without iteration looks like you assumed the solution was correct from day one. Iteration without a clear pain point looks like building for the sake of building.
The strongest presentations do both: βWe found that [specific users] struggled with [specific problem] β here is our evidence. We built a solution, tested it, found [specific finding], and changed [specific thing]. Here is the result.β
If you have to prioritise one in the time you have left: make sure your pain point evidence is specific and real, and show at least one before/after change driven by user feedback.
Dev Log
Section titled βDev LogβWe shared tasks this week. How do we each write a Dev Log entry?
Section titled βWe shared tasks this week. How do we each write a Dev Log entry?βπ¬ βOur tasks were shared across roles β how do we write individual Dev Log entries?β β²2
The Dev Log has two parts. The group summary is written by your group leader β one entry for the whole team. Your individual entry is yours alone.
Write what you personally did β not what the team did. If you ran a session, write about that. If you designed a screen, write about that. If two people worked on the same task, describe your specific part. One paragraph, in your own words.
How are validation notes stored in the Dev Log? Should I add a link?
Section titled βHow are validation notes stored in the Dev Log? Should I add a link?βπ¬ βHow are the validation notes stored in the Dev Log? Should Link or something else be placed at the beginning of this weekβs Dev Log?β β²4
Yes β a link is the right approach, and it is required for a strong Dev Log score.
Recommended setup: Create a shared folder on XJTLU OneDrive for your group. Store your validation session notes there (one document or one file per session). Paste the sharing link into your Dev Log entry for that week.
For example:
- Create
Group4_ValidationNoteson XJTLU OneDrive - Each session: add a new section or file with who you tested, what you showed, what they did, and what you changed
- In your Dev Log entry: βValidation session β [link to notes] β participant could not find the submit button, we moved it to the top of the formβ
What the assessors look for: The assessment brief says βlinks must be functional and demonstrate actual progress.β A sentence like βwe ran a user sessionβ with no link scores poorly. A link to a shared document with session notes scores well.
Other accepted evidence formats:
- Screen recording of the session (WeChat video, cloud storage link)
- Photos of a paper prototype being tested
- Screenshots showing a before/after UI change
- A note document in your teamβs GitHub repository
The key requirement is that the link works and the content shows what actually happened in the session β who participated, what you showed, what they did, and what you changed as a result.
Architecture and AI Agents
Section titled βArchitecture and AI AgentsβHow do I use AI agents effectively for building?
Section titled βHow do I use AI agents effectively for building?βπ¬ βWeek 7 β Architecture + AI Agentsβ β²4
The teams that get the most from AI agents are not the ones who write the biggest prompts. They are the ones who break work into small tasks and test each result before moving on.
The structured prompt that actually works:
βI am building [one sentence about your product]. Stack: [your frontend] + [your database/backend]. Here is the user story I am implementing: [paste the user story]. Acceptance criteria: [the 2β4 bullets β the things that must be true for this to count as finished]. Generate the [screen / feature / form] for this. Do not add features beyond these acceptance criteria.β
Without this structure, the AI guesses what you want. When it guesses wrong, you spend an hour starting over.
Use your existing documents as context. Paste your user story, acceptance criteria, and stack description into every prompt. If you have a spec folder (from the Week 7 guide), the agent reads these files automatically β you only write a one-line prompt.
One task at a time:
- Pick one task from Kanban
- Write the structured prompt
- Generate output
- Test it against the acceptance criteria
- If it passes β save and commit. If not β paste the result back in and ask for a fix.
Demo Day
Section titled βDemo DayβDoes our product need to be hosted or deployed for Demo Day?
Section titled βDoes our product need to be hosted or deployed for Demo Day?βπ¬ βDo we need to deploy our product to a server before Demo Day?β
No β you are not required to deploy to a public server. If your product runs on a laptop, that is fine.
What you must do: demo it live. The assessors want to see the core use case working in real time.
Make sure it works on more than one machine. Before Demo Day, test your product on at least two different laptops β not just your own. Library dependencies, database paths, and environment variables that work on your machine often break on another. Running on the presentation laptop should not be the first time you find this out.
Fallback hierarchy β in this order:
- Live demo β this is what you aim for. Test it on the machine you will present from, the morning of Demo Day.
- Live demo, second attempt β if something minor goes wrong (lost connection, slow load), calmly fix it and try again. One brief recovery is normal in professional demos.
- Pre-recorded video β if the live demo truly cannot run on the day, have a short screen recording of the working core use case ready. Narrate it as if it were live. Do not open with an apology.
Hardware prototypes: test your setup in the room before your slot if possible. Charge everything. Know which cable you need. You are responsible for bringing your own hardware β spare devices will not be provided.
The one thing that does not score: βit worked yesterday.β Assessors hear this every year. A confident video fallback scores better than a frozen screen and an explanation.
Our product requires on-site setup that takes a long time. Can we use a pre-recorded video for that part?
Section titled βOur product requires on-site setup that takes a long time. Can we use a pre-recorded video for that part?βπ¬ βSince on-site operation will take a relatively long time, can some of our product demonstrations use pre-recorded videos on demo day?β
Yes β with an important condition. The live demo is still required for the core use case. A pre-recorded video can cover the parts that are genuinely impractical to run live: a long physical setup, a process that takes hours, hardware that cannot safely be operated in a classroom.
What this looks like in practice:
- Acceptable: Show a pre-recorded clip of the 20-minute setup process, then switch to a live demo of the product working end-to-end.
- Not acceptable: Replace the entire demo with a video because it is more convenient or because the product is not ready.
The distinction assessors make is whether the live portion still demonstrates that the product works. If you show a video of setup and then the live product runs the core user journey in real time, that is a strong demo. If the video substitutes for showing a working product, that is a fallback β and will be assessed as one.
Discuss your specific plan with your Pathfinder before Demo Day if you are unsure what counts as a reasonable live portion for your product.
Kanban and GitHub
Section titled βKanban and GitHubβIs Kanban graded? Do GitHub commits count?
Section titled βIs Kanban graded? Do GitHub commits count?βπ¬ βIs Kanban mandatory? Is GitHub in the final score?β β²5
Neither is a separate graded item. Your pathfinder checks your Kanban board at Checkpoint 1 (Week 6) and Checkpoint 2 (Week 9) to understand how your team is working. What you put on your board should match what you describe in your Dev Log.
Your Dev Log should show your contribution. A commit link, session note, design file, or document update all count β use whichever fits your role. For developers, commits are the clearest record of what you built.
Design and prototyping
Section titled βDesign and prototypingβHow does design work count as a task?
Section titled βHow does design work count as a task?βπ¬ βHow to get a valid task from one Figma mockup?β
The task is the work that produces a design β not the design itself. Create one Kanban card per screen or user flow. In your Dev Log, describe what you made and why the layout choices match your user story.
A design is enough to run a Stage 2 Concept Testing session β show it to one person outside your team and watch what they do without explaining it. Any tool works: Pixcso, Gemdesign, Figma, or a hand-drawn sketch.
Was this page helpful?