Design Team

1 researcher & designer, 1 teacher


Fulbright Commission,

Technovation Challenge Chile


1 week of camp from Fulbright


Santiago, Chile

Computer science card game

Since I’ve come to Chile, I’ve taught a number of introductory Scratch workshops. And in all of them, I’ve taught students to build the same, simple video game. It works. It’s fun. The students build a game in which the user is a fish, trying to escape from a shark.

Although Chilean public schools are relatively well-equipped—almost all have computer labs—I was interested in designing an activity for even lower resource communities. I formulated my design challenge: create an unplugged (no computers needed) activity that gets students writing their first lines of code.


I designed a card game that teaches computer programming concepts.



I was inspired by Scratch, the application developed by MIT to introduce students to computer programming. Scratch is particularly effective because students can experiment, play, and explore without much instruction on the part of the teacher. I loved the Lego approach—students had a given set of “code blocks” to choose from, but they had the freedom to build whatever they could imagine.

But there’s a big problem with Scratch. It requires computers. Ideally, one for every student. And even though most public schools in Chile have computer labs, no one is using them.

The problem in Chile isn’t access to technology, it’s that many teachers don’t feel confident enough to incorporate technology into their classes. I set out to design do something a little paradoxical. I set out to teach programming without computers.


Armed with my design challenge, I started prototyping and testing activities. I wanted to design an activity that required only paper. The goal was to create something universally accessible and feasible.

During testing, I took notes on both students’ and teachers’ reactions. One insightful moment came after the failure of the first prototype. I had students writing code, but they were frequently consulting me: they depended on me, the teacher, to read and interpret their code. I realized that a good “unplugged” activity would need to have a clear set of rules that the students themselves could interpret. I wanted to remove the teacher as the interpretter, so that the game could be used by even the most tech-allergic educators.

Method Spotlight

Rapid Iteration

Scratch blocks.

I started by trying to re-create Scratch, without computers.  I wanted to print out the Scratch blocks on paper, and see how effective this was. On a computer, the Scratch application has a library of pre-made, ready-to-use code snippets. They fit together like puzzle pieces with other pieces, allowing students to start building quickly.

I tested my paper programming concept with students. The idea was for students to combine pieces of paper, each containing a written snippet of code,  to build a program. There was one big, glaring problem. Students couldn’t see the outcome of their program. They couldn’t run their code, so there was no way for them to see if what they’d written would work. In my new prototype, I had eliminated the part I liked most about Scratch: the experimentation.

Prototype No. 1

I created another prototype using only paper. This time, the code was written on poster-size pieces of paper, and the entire class would have to work together to build a program. The objective of their program, also constructed with paper “code blocks,” was to navigate me, the teacher, through a maze. I would act as the compiler, periodically, stopping to show students the output of their code.

I also deemed this activity unsuccessful. I could still see that students felt some disconnect between their code and its output. I also didn’t like that this activity was inherently limited. I could come up with lots of different configurations of mazes, but it was still just mazes. I needed something more dynamic.

For my third iteration, I pushed myself to think of something that could be played over and over again. I started thinking about a card game. A card game takes a totally different approach to introducing programming. In a card game, students aren’t writing code, they are the ones interpreting it. The game that I developed begins relatively simply. But as the students advance, they’ll have to obey an increasingly complex set of rules and algorithms, which will teach them the basics of how computers read code.

I like the card game approach for a couple reasons.

One. Students know the output of the code. The activity no longer relies on a teacher to interpret and debug the student’s programs. Once the students understand the rules, they are ready to go.

Two. It’s dynamic. The rules of the game change as the players play. Anyone can use this activity again and again to get students thinking like a computer.