The scope of this project was to work with a 7th grade Social Studies teacher using Participatory Design (PD), in order to assist him in teaching part of the class curriculum using some manifestation of computational thinking. An important premise of the PD process is the development of meaningful and productive relations between those charged with technology design and those who must live with its consequences (end users). Throughout the whole process, I kept a design journal and practiced reflection in action, i.e., reflectively participating in the design process. The journey started by being proactively exposed to classroom practices and ways of teaching/learning, participating as an observer in a few classes such as Math and Social Studies (ethnographic approach). My task was to observe classroom interactions and identify opportunities for designing a solution, based on setting, teacher, and/or student behavior. My general observation was that most students were struggling to complete the assignments in the allotted time, mostly using strategies out of the top of their head. There was definitely an opportunity there for improving instruction through (software) design.

An excerpt from the design/reflection journal.

We held weekly meetings with the teacher, initially trying to identify a common pain point in his teaching experience and later on discussing the proposed solution and defining the software system requirements. Communication of design ideas was achieved mainly through sketching. After multiple sessions, we converged into using computational thinking (CT) to enhance existing compare-and-contrasting practices in Social Studies instruction. This was deemed appropriate since CT is believed to “magnify people’s intelligence through automation and problem solving, as well as managing complexity.” Inspired by an online activity (from the DocsTeach website) I proposed a gamified version (see figure) in which students were pre-selecting the side they wanted to support and had to find the documents that counter the system’s argument. To make the activity more engaging I gave it a goal: to be a good debater and fight your way to a destination, dependent on the subject matter, by arguing on the way against the opposing side’s supporters.

Our initial design idea was formulated and adapted to the demands of the teacher and the school curriculum. During the coming months, we followed a rapid prototyping approach and conducted two pilot studies in the classroom, before evaluating the final product. In the first one, I used a low-fidelity paper prototype and employed a Wizard-of-Oz technique to simulate the functionality of the application with dyads of students. Although the game seemed unimpressive to students, due to being stripped down from its game elements, it gave us the opportunity to experiment and test alternative ways of interaction on the fly. The lessons learned from the first pilot allowed us to develop the wireframes for the first functional prototype, using a combination of sketches and digital assets, which was then brought to life programmatically. The purpose of our second pilot with a fully-functional prototype was twofold: to see the use of the tool from the teacher in action and to gauge children’s acceptability (i.e., ease of use, ease of learning, etc.) of the program in an authentic context. Both sessions were videotaped and observations were used to inform the final design.

One of the first iterations of the prototype based on wireframes.

The summary screen of the final prototype used for evaluation.

The final prototype, called ArguApp, was used for a formative evaluation a couple of weeks later inside the classroom with pairs of students working on a laptop. Most of the students completed the activity by picking both sides of the argument (i.e., robber barons vs. captains of industry), which was really encouraging about the ease of use and learning how to use the software. The teacher thought that ArguApp was very effective in teaching both the use of primary source documents and helping students hone their argumentation skills, through higher-level thinking. Through this iterative participatory design process with a teacher and other stakeholders, I became exposed to how things work in such a complex environment with multiple interests and intents. I realized first hand that "establishing appropriate relations with other organizational members increases the likelihood that the influence of the project on technological and organizational change extends beyond the immediate project group and endures after the researchers leave."¹

¹ Kensing, F., Blomberg, J. (1998). Participatory Design: Issues and Concerns, Computer Supported Cooperative Work, v.7 n.3-4, p.167-185.