CodingCUSP

A web-based learning tool that scaffolds middle school students' transition from block-based to text-based programming, using side-by-side worked examples and generative practice.

CodingCUSP icon

The Problem

Many learners start programming with block-based environments like Scratch, where code is assembled visually and errors are rare. Moving to text-based languages like Python breaks that flow entirely. Students suddenly face cryptic syntax errors, strict formatting rules, and no visual scaffolding to fall back on.

"It takes too long to write and any little mistake can mess up the whole thing." Alice, a middle school student, on transitioning from Scratch to Python

The transition involves more than learning new syntax. It requires a shift in how students think about code: from snapping blocks to composing statements, from seeing execution visually to reasoning about it abstractly.

My role: Instructional design intern (one quarter, Stanford). I joined Nathan Lin and Raycelle Garcia's capstone project to support the learning design work: contributing to the theory of change, the learning mechanics framework, and prototype testing.
3 prototype rounds
3 learning theories applied
Stanford capstone project

My Process

Discovery

Understanding where learners get stuck

We interviewed middle school students and identified the specific pain points that made text-based coding feel hostile: syntax errors, forgetting command names, and struggling with control structures like if statements and for loops. Typos that silently break programs were especially demoralizing.

The pattern pointed to a clear design principle: learners needed to build confidence through small, frequent wins before tackling open-ended coding challenges.

Compiler error output showing common syntax errors
CodingCUSP Theory of Change diagram

Learning Design

Grounding the tool in learning theory

We built CodingCUSP around three frameworks. Self-efficacy theory shaped our emphasis on scaffolded practice and immediate feedback, since confidence in coding grows through mastery experiences, not just exposure. Constructionist learning informed the trial-and-error philosophy: students understand code better when they can tinker and observe the results. Socio-cultural theory motivated our use of task-specific contexts like art and design to make coding feel personally relevant.

The Theory of Change tied these together: the right combination of structure, context, and feedback would move learners from block-based familiarity to genuine Python competence.

Design

Two core mechanics: worked examples and generation

We chose two learning mechanics grounded in cognitive science. Worked examples with block-based equivalents let students see how familiar concepts map to Python syntax, reducing cognitive load during the hardest part of the transition. Generation, where students complete partial code rather than copying it whole, strengthens retrieval and builds the mental models needed for independent coding.

Students could step through code line by line to observe how each command changed the Turtle's behavior, making execution visible rather than abstract.

Interactive worked examples in CodingCUSP
Scaffolded coding practice with fill-in-the-blank tasks

Fill-in-the-blank problems gave students early mastery experiences without the blank-page anxiety of writing from scratch. Targeted error messages helped them identify and fix bugs instead of feeling lost in the output.

Prototyping

Three rounds of testing

We started with paper prototypes to test one core question: would learners be willing to self-report their confidence alongside their answers? Moving to digital prototypes, we explored how intuitive it was for learners to refer back to worked examples while actively coding. A final click-through prototype tested whether users could navigate the notebook interface independently and discover its features without guidance.

Paper prototype worksheets
Click-through prototype screens
Early digital prototype screenshots

Key Insight

Testers appreciated the simplicity and clarity of the scaffolding. But one piece of feedback stuck: "I wonder how you can make it more playful." The tool was readable and logical, but it felt more like a worksheet than an experience learners would seek out. Scaffolding that reduces cognitive load does not automatically create intrinsic motivation. Those are two separate design problems.

Outcome & Reflections

CodingCUSP addressed a gap that no existing competitor fully covered: a side-by-side block/text editor with scaffolded progression and annotated worked examples, all in a contextualized task environment.

Feature CodingCUSP Code.org MakeCode Teaspoon
Side-by-side blocks and text Yes
Built-in scaffolded progression Yes Yes
Step-by-step annotated breakdown Yes Yes Yes
Contextualized topics Yes Yes Yes Yes

If I were building it again, I would invest more in the motivational layer from the start: a clearer sense of progression, a project students could feel proud of completing, and feedback that feels encouraging rather than corrective. The cognitive scaffolding was solid. The emotional design was where more work remained.

CodingCUSP interface showing side-by-side block and text editor

Want to see the product?

The project has been archived.

Visit CodingCUSP ↗