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 been asked to teach 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. You can download it here, but here’s a sneak peak of what’s inside.



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. There just aren’t that many teachers who feel confident enough to integrate programming and 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. I wanted to remove the teacher from the equation, 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 create a paper cutout version of Scratch. 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 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.