Prior to the Christmas break, the boys in Fusion completed their second iteration of a mousetrap vehicle challenge.It was interesting to see how the thought process evolved over the course of that project. It was as much an exploration of the Design Thinking Process as it was a look at the transfer of potential energy into kinetic energy. It was as interesting to see how effective the project addressed the anticipated learning as it was to see what was learned that we did not expect.
Over the course of the project and term, I started to break down our learning into some broad categories. They became Engineering/Making Hard Skills such as designing and building models using 2D and 3D CAD and CAM tools, the use of the Design Thinking Model itself, Communication Skills that focus on how a student clearly articulates their thinking in a number of ways, Analytical Thinking Skills that focus on how a student breaks down a problem in order to solve it, and Collaborative Skills that look at how groups of students work together to accomplish a task.
Generally speaking, the students came to a clear understanding of what the Design Thinking model is and how to leverage it in group problem-solving. Probably the biggest realisation was that the model itself is not linear. While we talk about five stages which do progress in a sequential fashion, there are often times where it is appropriate to move from stage to stage in other orders. Probably the most common issue this way is in the prototyping phase. Many students discovered that as they got a prototype built or partly built and significant issues arose. Those that felt confined by the Design Thinking model didn't go back to the ideation phase or at least the ideas that they'd come up within that phase. They would typically get stuck or obsess about a small issue that might not even be solvable rather than stepping back, looking at the other options that they'd already partly explored and use that thinking to inform their design. Over time, they became more adept at using the model and recognised that each phase was a way of thinking through the problem and that sometimes moving across the model to leverage those different ways of thinking was more effective. Rather than being confined by the model, they used the model to their best advantage.

The hard skills wound up being a real issue with some. We have very much been operating from a philosophy of "just in time learning" where we wait for a real problem to arise before teaching the skills to address it. This makes the learning of these skills more relevant and efficient because the skills have direct application. It is common to teach STEM kids to solder, but if the student doesn't know what a circuit is and why they might want to build one to address a problem, the learning becomes fairly hypothetical. The downside to "just in time learning" is that you don't know what you have to learn before you have to learn it. When students come up with different solutions to a problem, the skills that they need to solve it are different. Some students deal with what they don't know by avoiding learning a skill and finding another way around the problem. Others dig in a get their feet wet. The biggest danger, of course, is that they don't know what they don't know and if they don't know that something is possible, then they won't think to explore it.
A big area of emphasis for me in the second iteration of this project was in the use of communication skills. This is where the blogs were most effective and if you are a regular reader of the student blogs (look to the right of this screen), then you will have noted many conversations where I was pushing the students to clearly articulate their thinking. There were many issues with communication from laziness and bad grammar to simply not having thought through a design or a problem clearly and thus not being able to articulate their ideas. The communication struggles would cause issues with final presentations and reflections, but would also result in miscommunication between team members as they would misunderstand each other and be thinking about their work differently. This is an area that we will continue to push as I truly believe that the clear articulation of an idea is the best evidence of clarity of thinking.
While communicating ideas was important in the way a group was able to work together, there were other aspects of communication that affected how effective a group was in their work. Some groups were very deliberate with how they set up their online communication tools, how they divided responsibilities, and what their expectations of each other were. There was a direct correlation between those groups that took the time to organise themselves in these ways prior to getting down to the work of solving the problem and those that felt that the process was successful. Those that simply started in on the problem and never talked about their group dynamics reported more frustration with how the group progress throughout the challenge. The learnings here have been taken to heart and are being leveraged in the current design challenge.
The final key learning in our mousetrap vehicle project came through our discussion of what it means to be successful in these challenges. Clearly, in the work world, success is completely dependent on the end product. Rarely do companies care how a job gets done (apart from harmful workplace politics or processes that cost too much money). They care more about delivering a product to the customer in a timely fashion that generates a profit for the company. We have the luxury in education about not worrying about the bottom line and this frees us up to care more about the process and less about the product. Having said this, I was curious to know if the students saw things the same way. Do they really on care about making their vehicle going further or faster than the other teams'? Do they care only about getting a better mark than their classmate? If so, then the discussion around what one learns from a "failed" attempt is much less effective. I was encouraged to see that these students were generally able to step back from the product and look at what they had learned from the process. If iteration two didn't grow in some way on iteration one, it was generally seen as a failure. If iteration two took some risks and resulted in new learning, regardless of whether the actual vehicle moved at all, it was generally seen as a success. In my mind, this is exactly as it should be even if it doesn't result in replicating the "real-world" environment. In our business, the product is the learning and everything else is simply a demonstration of that learning. I was quite pleased to read the students' blogs and find out that many of us are on the same page!