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 β
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.
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 β only if the live demo truly cannot run on the day. A short screen recording of the working core use case is accepted as a last resort. 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.
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?