Skip to content
ENT208TC Industry Readiness

Week 7: Frequently Asked Questions


πŸ’¬ β€œ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.

Was this clear?
Was this already on your mind before reading?
βœ“ 謝謝 Β· Thanks
πŸ˜•
πŸ’‘

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 β†’

Was this clear?
Was this already on your mind before reading?
βœ“ 謝謝 Β· Thanks
πŸ˜•
πŸ’‘

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.

Was this clear?
Was this already on your mind before reading?
βœ“ 謝謝 Β· Thanks
πŸ˜•
πŸ’‘

πŸ’¬ β€œ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.

Was this clear?
Was this already on your mind before reading?
βœ“ 謝謝 Β· Thanks
πŸ˜•
πŸ’‘

πŸ’¬ β€œ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 clear?
Was this already on your mind before reading?
βœ“ 謝謝 Β· Thanks
πŸ˜•
πŸ’‘

This site uses anonymous analytics (Microsoft Clarity) to improve course content. No personal data is collected.
Current page
πŸ€–