A chatbot would have been the easy part. I built the full study platform around it.
Human-AI Interaction · Experimental Software · TypeScript · React · Supabase · Embodied AI
| Context | My role | Study design | Public scope |
|---|---|---|---|
| Course project for Human-AI Interaction at the Technical University of Munich | Technical and product lead | 30-participant comparison of two AI-tutor conditions | Study platform, methodology and de-identified interface views |
How does the experience of learning with an AI tutor change when a familiar chat interface is replaced by an embodied, speaking avatar?
The visible comparison was simple: text tutor or speaking avatar. The actual research problem was harder. Both experiences had to teach the same material, survive real participant sessions and leave enough evidence to compare them honestly.
I turned that question into an end-to-end experimental system rather than a standalone interface demo. The platform guides a participant from consent and baseline measurement through one of two tutor conditions, records interaction and timing telemetry, runs the post-test, validates session quality and produces analysis-ready exports.
The study examined trust, engagement and learning in an AI-literacy task. Across the complete cohort, correct answers to the CFG-scale question increased from 23% before the learning session to 95% afterward. This is a descriptive pre/post result across the study, not evidence that the avatar alone caused the change.
Both conditions used the same learning material and overall study sequence, while the interfaces differed in interaction modality, provider behavior and presentation.
| Text tutor | Embodied-avatar tutor |
|---|---|
| Written interaction with a streaming AI tutor beside the learning material | Spoken interaction with a real-time video avatar, transcript and participant-controlled microphone |
I describe this as text tutor versus embodied-avatar tutor, not as a perfectly isolated test of embodiment. Voice, provider behavior and parts of the interface changed too. Pretending otherwise would make the conclusion cleaner, but not more true.
Putting an LLM behind a chat panel was not the interesting engineering problem. Making the whole study survive real participants was.
- Present study information, informed consent and age eligibility.
- Record demographics and a pre-test baseline.
- Route participants into a text or avatar condition.
- Keep the tutor synchronized with the active learning slide.
- Capture dialogue, answers and time-on-task without storing raw audio or camera video in the study database.
- Run a structured post-test covering experience, knowledge and open feedback.
- Detect incomplete or suspicious sessions and require researcher validation.
- Export filtered CSV, JSON and PDF artifacts for independent analysis.
This created one traceable path from the participant-facing experience to the final research dataset. For critical study writes, moving to the next screen was not treated as proof that data had been saved. The platform uses explicit server operations and a bounded retry path with diagnostic metadata.
| Consent | Baseline | Experience assessment | Knowledge check |
|---|---|---|---|
 |
 |
 |
 |
One continuous study flow: informed consent, baseline measurement, the assigned learning condition, experience ratings and a post-test knowledge check.
- React, TypeScript and Vite implement the participant flow and researcher dashboard.
- Supabase Postgres stores study sessions, answers, timing records, dialogue turns and validation state.
- Supabase Auth and role checks separate participant, researcher, mentor and owner workflows.
- Deno Edge Functions mediate participant-data writes and external AI-service calls.
- An OpenAI-compatible streaming endpoint powers the text tutor.
- Anam AI provides the real-time embodied avatar, speech pipeline and transcript events.
- A separate image-generation service supports an optional prompt playground inside both learning conditions.
The architecture separates study state from service state. If an external tutor or avatar session fails, the experimental record still has an explicit status and the researcher can distinguish a technical interruption from a completed response.
Each session receives a random identifier. The platform records answers, timestamps, page and slide durations, tutor dialogue, completion state and validation decisions. Participant names and email addresses are not part of the study flow.
The researcher dashboard supports:
- completeness checks across demographics, pre-test, learning and post-test;
- timing-based flags for implausibly fast progression;
- inspection of text and avatar transcripts;
- explicit accept or ignore decisions before a session enters analysis;
- condition-level pre/post summaries;
- question-level performance, timing and exploratory correlations;
- filtered exports for independent analysis.
The dashboard view is an aggregate, filter-dependent research snapshot. The validated sample can differ by statistic after completion checks, exclusions and missing-data rules.
That distinction between recorded sessions and the validated sample used for a specific statistic was a core product requirement. It prevents an attractive dashboard number from silently becoming the study's source of truth.
The apparatus supports condition-specific entry links, while a manual condition-selection route also exists. A rigorous deployment must document which route was used and how assignment was controlled.
Time correlations in a small validated subset are exploratory. They can generate hypotheses, but they do not show that session duration or avatar exposure caused a learning outcome. Likewise, the 23% to 95% knowledge result demonstrates learning across the complete experience; it does not identify which interface component produced it.
I kept these limitations explicit because the dashboard is only useful when its numbers remain interpretable.
- no participant names or email addresses are required;
- raw microphone audio and camera video are streamed, not stored by the study database;
- dialogue transcripts and free-text answers are stored for research review;
- participants are instructed not to enter personal information in free text;
- sessions can be withdrawn and excluded from analysis;
- public portfolio media contains no participant records.
As technical and product lead in a five-person student team, I translated the study concept into the system architecture and implemented the platform end to end. My work covered the participant experience, tutor integration, database model, server functions, telemetry, research dashboard, validation workflow, exports, deployment and operational debugging during the study.
The remaining team members focused on research framing, study materials, analysis, reporting and media. This distinction matters: the platform was collaborative research, while my primary ownership was the technical system and its operation.
AI Study Buddy is not a VR application. Its relevance to immersive research lies in the infrastructure behind the interface: controlled participant flows, multimodal integration, instrumentation, failure handling, data provenance and explicit threats to validity. The same concerns determine whether a VR environment is only a convincing demo or a dependable experimental apparatus.
This repository is a portfolio case study. Production source code, backend configuration, service credentials and participant-level data are intentionally not published. The public repository was created as a clean documentation snapshot; it is not a mirror of the private development history.