This is the third article in a series (1, 2) about using design thinking in practice in our school. This year, I convened a study group to examine what computer science course offerings we might include in our course of study. In the past, the school offered an elective programming class when student enrollment demanded it, and a part-time faculty member could be found to teach the single section course. The study group included teachers, parents, students, and administrators.
I decided to use the design thinking process to organize our study group’s work. Design thinking matched our question well, because previous approaches to teaching programming did not stick in the curriculum. A user-centric approach might reveal some of the system conditions that prevented success in the past. Student feelings about computer science would feature strongly in our process. The ideation phase would facilitate consideration of new approaches to teaching computer science.
Facilitating design thinking activities with a school committee has been very different from working with participants at a summer workshop! People who attend summer workshops are chiefly there to learn something new. People who join a committee, while open to learning something new, are primarily there to help make a school decision. Starting with active inquiry activities helped build support for the use of design thinking methods. We were quickly able to see productive results emerge from our early work. Also, while some participants came ready to propose solutions right from the beginning, I expressly acknowledged that we would need to exercise patience and wait to share ideas until after we had distilled user interviews into themes.
Design thinking workshops focus on a hypothetical scenario such as designing a better chair, wallet, or playground. Designing a computer science course focused on a real scenario that is also more abstract in nature. Interview questions were pretty similar. “Tell me about your experiences with programming?” The process for identifying themes in user interviews was also fairly similar. Ideation was very different, relying more on existing models in use at other schools than on original inventions and new ideas. Prototyping was also very different, since we crafted statements about educational themes rather than building models out of paper and blue tape. Testing our prototypes would have felt similar, as we assigned study group members to play the roles of fictitious user characters, embodying the top themes from user interviews.
External input had great value during the ideation phase. Not only did our study group members bring in their own experiences from beyond our school, but we also tapped into the power of independent school electronic networks. Coincidentally, the topic of teaching computer science was actively discussed on the ISED listserv, and we benefitted from a summary of the input of 70 schools that Chris Bigenho compiled. This document was invaluable in broadening our view and providing perspective on the range of conceptual approaches available to us.
As it so happened, we departed from the design thinking script during the prototyping and testing phases. However, the spirit of design thinking remained fully embedded in our work, even though we fell into whole-group discussion of a single proposal. Throughout, we kept a user-centric focus, considered idealistic possibilities, and tinkered with our proposal on the fly. The result was a clear consensus for a well-defined, innovative proposal for course changes to reintroduce computer science in the school curriculum.
Our empathy map after we practiced interviews on each other. We added three times as many stickies after conducting user interviews, and then arranged the stickies by similar content to identify themes.
I found the d.school mixtapes very helpful to use for talking points and slides when describing the design process to study group members.
(links from d.school website)