Prototype

What ideas are you prototyping? What are the components, goals and activities incorporated in your prototype? 

Can students with limited experience in computer science and coding create a holographic application that is worth sharing with the world and professionals and would doing so change the way they think about themselves in this space? Those were the questions I started with in some ways back in August when the Space Foundation and I started talking in deep ways about collaboration for the 2021-2022 school year. It was a tenuous dance at first, because we needed to have a couple of projects and products the students would make, and that required a completely new type of collaboration, an exciting challenge and one that led to additional questions. How does a non-profit support the work of schools when that non-profit is the client and not the delivery mechanism for content? How does industry support from the private sector deepen the work and what opportunities does that open? Does any of that change the way students think about and believe in their ability to do computer science, user experience design, and leadership? How do the students share their work in an authentic public space that demonstrates transformational learning (or not!)?

Each of those is part of what we are prototyping, and, while in a standard Design Thinking sprint a single or much smaller list of items would typically be prototyped, in our case, our prototype is the evolution of many other prototypes from across the years. We have been doing short design prototypes and sprints across the entire year, with different components of design, and in the playlist below there are over 20 videos documenting parts of our process made by my students and myself. Some of the videos show things working, while some show our process with failed examples that helped us learn new things that we used to iterate our design. Some concepts were built out while others were abandoned. In the end, we are prototyping lots of things in part because we are doing long term prototypes based on much shorter design sprints.

How have you had the “embrace failure” mindset? 

During the project we had to learn when good enough was good enough and when great ideas just couldn’t be completed due to lack of time, lack of training, or lack of resources and sometimes when all of those combined in unique and interesting ways. There was the moment when our user control system for a holographic rover had to be redesigned three different times based on user feedback. There was the moment when we had to convert our idea for an infinite holographic bookshelf because we couldn’t figure out how to hide models that had gone out of view, and we had to come up with a different kind of display for making lots of content available at the same time. There was the moment when we had to research, iterate, and ultimately explain to the client that we couldn’t display everything they wanted in the same space because of hardware limitations and work to figure out a solution that would include enough for the client to be happy while addressing the realities of the devices the experience would be shown on. In each of these challenges, the only path forward was to view each setback as an opportunity for authentic problem solving. Without that mindset, each pain point in the project could have been the point where a student started to believe that they couldn’t do this work, that they weren’t smart enough, or that the belief that this work is only for “some” people was valid, and I don’t want to play into that narrative.