Teaching Statement
Be curious, achieve small wins, and learn together. This is the core of my philosophy of teaching and learning, and it matters more, not less, now that a chat window will hand a student a plausible answer to almost anything on request. Curiosity has to be deliberately cultivated when the easy path is to stop at the first answer instead of asking whether it is the right one. Small wins are the antidote to a tool that makes the first ninety percent of a project feel free and the last ten feel like someone else’s problem — each real success, earned rather than generated, builds the judgment that lets a student tell good work from convincing work. And learning together matters because that judgment is not something a model can currently give back to a student; it comes from peers pressure-testing each other’s decisions.
At SUTD my teaching now centres on two courses closest to my research: 60.005 HCI and AI, which I designed and lead (2022–present), and 50.006 User Interface Design and Implementation, which I lead (2021, 2025–present). I also teach further up and down the pipeline — foundational computing, design-facing programming for non-CS majors, a human-centred AI module within SUTD’s Global Exploration Opportunities programme, and year-long Capstone supervision — but 60.005 and 50.006 are where my approach to teaching AI and design together is most deliberate.
In both courses I treat AI as a design material with real limits, not a feature to bolt on. The clearest example is a 60.005 assignment where I deliberately handicap students with small local language models instead of letting them build on a frontier model’s capability. Cut off from a model that can smooth over a mediocre interface with fluent, mostly-correct output, students have to do the work themselves: set honest expectations for what the system can do, make its failures visible and recoverable, and keep the person in control when the AI is wrong. That constraint is the point — it is far easier to see the boundary between good interaction design and borrowed model capability when the model is weak enough to expose it. 50.006 applies the same discipline at the level of interface craft: even a well-designed interaction fails if the interface itself doesn’t make the system’s uncertainty legible to the person using it.
Elsewhere in the pipeline the same “be curious, achieve small wins” frame takes a different shape. For foundational and technical content, where the material is closer to facts and procedures, I lean on frequent, low-stakes formative assessment: short exercises with fast feedback that let slower learners catch up and stronger learners keep testing themselves, reserving class time for the harder conceptual leaps rather than material students can absorb on their own. Capstone extends the open-ended, critique-driven mode of 60.005 and 50.006 furthest: over a full year, students work with genuine external stakeholders on projects with real uncertainty, and my role is closer to advisor than instructor.
I see my role as an educator as more of a facilitator than one who transfers knowledge — engineering the learning experience, putting students in the driver’s seat, then getting out of the way. That is easiest to do in project-based courses, and I try to bring the same disposition — asking rather than telling, letting students sit with the discomfort of an unresolved design or debugging problem before I step in — into more structured courses as well. It matters more now that a model will happily supply both the question and the answer if a student lets it: I know I have succeeded as an educator when my students go on to pursue questions I did not set for them, and help each other learn along the way.
