T127 Course Capstone: Generative UI for Education
A proof-of-concept learning product that uses generative UI to personalize scaffolding, checks for understanding, and shared vocabulary-building for Harvard's data fluency initiative.
This capstone is a product and learning-design prototype for Harvard’s data fluency initiative. I built it after a semester working with Harvard’s Teaching and Learning Lab on a university-wide effort to help staff across schools build practical data literacy skills.
The core idea is simple: data fluency does not look the same for every staff member. A GSAS admissions officer, a GSE career consultant, and an HBS administrator may all need “data fluency,” but the terms, workflows, constraints, and examples that make the learning useful are different. The prototype explores how a learning interface can adapt scaffolding to the learner and collect department-specific language along the way.
Impact
- Cost efficiency: ~$300 estimated for 50,000 unique UI generations
- Live proof-of-concept: Deployed at data-fluency-module.vercel.app
- Open-source: Designed for LXP iframe portability with human-in-the-loop calibration
- Institutional: Built for Harvard’s university-wide Data Fluency Initiative across schools and departments
My Role
Sole builder. Discovery, design, and prototype implementation. Built in partnership with Harvard’s Teaching and Learning Lab.
Snapshot
| Area | Details |
|---|---|
| Role | Learning designer, product designer, prototype builder |
| Context | Harvard GSE T127: Learning Design, Technology & Innovation |
| Partner context | Harvard Teaching and Learning Lab data fluency initiative |
| Audience | Harvard staff learning practical data fluency across different schools and departments |
| Output | Live proof-of-concept module, open-source codebase, capstone analysis, reflections |
| Product bet | Generative UI can provide just-in-time scaffolding while learner-created artifacts improve shared institutional vocabulary |
The Problem
The initial temptation was to treat data fluency as a top-down course: define the concepts, sequence the modules, and push the same material to everyone. Discovery work made that feel too blunt.
The staff problems surfaced through the project were more contextual than the assumed problem. People were learning skills on the job, moving across school-specific systems and vocabulary, and working under time constraints that made another generic training module hard to justify. The product challenge became less “how do we explain data concepts?” and more “how do we make the right support appear at the right moment for the right staff context?”
That shift mattered for me personally. I started the semester inclined to reach for AI quickly. The discovery process pushed me toward a more disciplined product posture: sit with the user problem long enough that the prototype solves something real, not just something technically interesting.
Design Goal
The capstone goal was to address two connected needs:
- Scaffold the right information to the right learner just in time, while reducing redundant support for learners who are already competent.
- Let learner-created artifacts help reveal and bridge differences in data vocabulary across Harvard schools.
Instead of a static course page or a conversational AI wrapper, I explored a generative interface: a module that can render more support for novices, then progressively strip that support away as the learner demonstrates understanding.
Product Decisions
Adaptive scaffolding
The interface is designed to show worked examples, guided steps, glossary support, and checks for understanding when a learner needs more structure. As the learner shows competence, the module can reduce visible scaffolding so the experience feels less repetitive.
This matters for adult learners because redundant training is expensive. Staff often build data skills through real work, so the module should respect what they already know while still catching gaps.
Contextual learning
The prototype treats context as part of the learning object. It asks learners to connect concepts to the job stack they actually use, rather than treating data fluency as a single universal script.
The target was not personalization for novelty. It was contextualization: making the same data concept legible to people operating in different institutional environments.
Learnersourced dictionary
Questions inside the module nudge users to enter the terms their school or department actually uses. Those terms can feed a shared data dictionary or wiki, creating a richer content base that future learners and learning designers can reference.
This turns the module from a one-way training artifact into a lightweight institutional listening mechanism. Learners contribute vocabulary as a byproduct of learning.
Human-in-the-loop calibration
The project is designed around learning designers as much as learners. The goal is not to hand the course over to a model. The codebase and content pipeline should be inspectable and calibratable by people responsible for quality, pedagogy, and institutional fit.
At the gallery walk, this became one of the most important points to explain: the prototype is open-source, iframe-portable, and intended to be wired into a learning experience platform with human oversight.
Prototype
The live proof of concept demonstrates a self-paced data fluency module with scaffolding, a dictionary flow, autoplay/demo mode, and visible design decisions.
What I Built
- A live data fluency module prototype for Harvard staff.
- A generative UI concept that adapts the amount of scaffolding shown to the learner.
- Checks for understanding that help route learners through different levels of support.
- A dictionary contribution loop where learner language can inform a shared institutional vocabulary.
- An open-source implementation designed to be portable into a standard LXP iframe or code block.
- A capstone narrative connecting learning theory, discovery work, product decisions, and technical constraints.
What I Learned
The most important lesson was that discovery changes the product. The useful version of this project was not “AI for data fluency.” It was a more specific product question: how might a learning system support staff whose data work, vocabulary, and constraints differ across departments?
I also learned that generative UI is most compelling when it does not replace learning design. Its value is in making scaffolding dynamic, contextual, and easier to calibrate. The learning designer still needs to define the pedagogical logic, quality bar, feedback loops, and acceptable forms of variation.
Finally, the project clarified the kind of product work I want to keep doing: translating messy human and organizational problems into prototypes that are concrete enough to test, critique, and improve.
Evidence From The Process
- In the first reflection, I framed the work around stakeholder engagement, adult learning theory, connectivism, and the possibility of knowledge graphs for contextual learning.
- By the second reflection, the discovery process had expanded my understanding of learning design: focus groups, surveys, stakeholder communication, rolling agendas, and tacit knowledge became part of the product work.
- In the third reflection, the capstone became sharper: just-in-time scaffolding, less redundancy, and learner-created artifacts that bridge vocabulary differences across schools.
- In the gallery walk reflection, feedback centered on the architecture, the dictionary loop, backend feasibility, and cost. My rough calculation put 50,000 unique UI generations at about $300.
- In the final reflection, I named the deeper shift: from solutionist AI enthusiasm toward discovery-led design.