Announcing A Prototyping Bootcamp: Spreading EDesign Methods


New year, new targets.  As we reflect on one of our original hunches, that there are creative technologists and teachers in every locality who can co-imagine, co-problem solve and co-design the next generation of of digital learning experiences and change the eco-system, this belief now seems to have penetrated the mainstream.  EDesign’s intention has always been to foster this culture and package our methods as a framework such that other networks can adopt our techniques to reach a larger number of teachers, technologists, and students.

This spring, we’ve teamed up with 4.0 Schools to do just that and build a 12 week Prototyping Bootcamp.  How can we re-imagine education so that it actually prepares students for a world we can’t predict?  There is no one right answer, we are looking for people crazy enough to test their ideas for the future of education, one piece at a time.  Over a series of lab sessions and field testing opportunities, a community of educators and technologists will concept and prototype digital learning experiences that can be put to the test in diverse learning environments.  To learn more or apply click here.


Into iTunes App Store and Google Apps Marketplace


A round of cheers to Ryan Raffa, Anna Pinkas, and Eric Allata for publishing a first version of Breadcrumbs.   Co-developed by teachers and technologists, the iPad app records and visualizes a person’s math problem solving process and enables retracings for reflection.   It’s now available for free and easy download from the App Store.   You can also watch a walkthrough video and thumb through its Learning Guide for examples on how to apply it on the Breadcrumbs Page.

EDesign Lab engages its members in small group inquiry; we hope to expand that circle.  As a working prototype, leaving Breadcrumbs distribution to individual requests and manual permissions for downloading via TestFlight limited the number of teachers who could simply access it.   The intention with putting a basic version of Breadcrumbs out into a marketplace, aside from it hopefully being immediately useful, is to encourage peer exchanges about how math teachers might apply it, how students might use it, and what works.  The team will be continuing the development of Breadcrumbs in the future after this initial launch, and welcome feedback.

Another recently developed project, Because, is in the process of being approved by the Google Apps Marketplace.   While it can already be accessed by visiting a URL, making the effort to list recognizes the need to facilitate find-ability amongst a wider community.   A ready plug-in for schools and educators using Google Accounts, Because works like group writing on Google Docs, but instead of a word-based document, learners jointly contribute to adding Markers to a image or graph to collaboratively investigate cause and effects.  All individuals contributions and changes to the group document is reflected in real-time.  You can check out more details on the Because Page.


Hackathons as Community

A huge Thanks! to everyone who joined us at The Center for Social Innovation this past weekend for our first public hackathon.  We’re so happy to now know you all!  If you missed it (or want to relive the glorious memories), here’a bit of our Twitter trail and here’s some playful poses by the newest members of our community who braved our Gif Myself Station.

We aimed for a different vibe at our hackathon; one primarily about community that can continue beyond the weekend. Over 100 people engaged with the tough question we posed: “How do we design learning for a future of computational thinkers, effective storytellers, and empathetic inventors?”  At our “Dating Wall”, new found collaborators teamed up around our Tracks and the Challenge Briefs EDesign Lab created to facilitate creative energies along. Our Learner Personas Wall gave participants insight into the range of minds, interests, and learning styles to help inform their designs.

A set of adult and youth judges joined us on the second day for the sharing of the 11 projects that emerged.   Team “Wave Pool” an interactive application (gestural interface) to teach students about wave properties (lengths, frequencies, and amplitude) through embodiment and sound (kinect hack) was voted to the top. Runner-up was a tie between “If, Then, What”, a collaborative time line for student-generated current event stories, and “Data Crunch”, a web-app where students interpret data through questions and polls and which links classes into a larger database to see more global patterns.   The “Youth Favorite” prize went to  “Mini Stories” an iPad app where students create characters, images, and  a collaborative story to practice language skills and engage in creative writing.

The weekend was also full of stories of personal journeys.  One person came all the way from Canada.  And to our delight, we discovered that Mini Stories was actually a husband/wife/friend team where the wife had asked to spend her birthday weekend at this hackathon.   We snuck in a lit up cupcake as a surprise and everyone sang happy birthday at the closing of the hackathon – pretty much reflecting the group spirit over the weekend.

We had a blast and are looking forward to the next one. Stay tuned!

Peer-Testing: The Quickest Way to Insights

It’s the critical moment Lab teams work towards every session.  Intense energy builds as facilitators call out the 15 minute warning. Teams work feverishly to cut out another button or draw out a paper screen.  “Okaayyyy!  Time’s up!”  Teams gather round a large table to begin our peer-testing process.

Peer-testing is an essential element of our process and iterative ethos.  Often we find that some of our ideas don’t necessarily translate to the people who will be using them.  We overlook a step in the process, misplace a button, or forget to include another form of feedback or prompt.  Through internal peer-testing, we can make these gaps visible.  “Eating our own dog food” allows teams to receive quick feedback around what is and is not working within the prototype during initial development.  These data points allow teams to reflect and refine their ideas as they create iterative versions of their apps.

When we peer-test a prototype, we focus on three criteria: the interface, the interaction, and the learning. Here are just a few of the questions we ask ourselves to evaluate them:

  • Can users navigate around it to execute a task?
  • Is the mechanic, or main action, effective and engaging?
  • How does the interface/interaction support and align with the learning goals?
  • What types of content can live in the app?
  • How will learners enter and exit out of the experience?
  • Do learners understand why they are using it?

Reflecting on all of these questions prepares us for the second stage of learner field testing – but that’s a whole other blog post!


A simultaneous evaluation of the interface and the learning is one of the unique challenges of our process.  We have found that an explicit focus on both is essential from the beginning.  During the concepting phase, we speak mainly of the learning experience and goal.  In initial paper prototyping, we test for basic interactions and interface.  Towards the end of paper prototyping, we revisit the learning to question if it is working.  Once we go digital, teachers and technologists focus on their realms of expertise, but solicit feedback from each other often.  By the time we reach the second stage of learner field testing, teams have a solid prototype.

Here are some guiding principles to get you started:

Assign a human computer if you are working on a lower fidelity prototype.  This person acts as “wizard behind the screen” who responds to the actions of the tester.  If you are playing the human computer, remember to stay in character.  It can be tempting to guide your tester if you see them doing something wrong.  Chances are, however, you will learn less than if you let them continue until the end.

Think aloud.   An important part of peer testing is to make invisible cognitive processes visible so its creators can refine what isn’t working.  Testers should verbally walk through each part of the process, reading aloud any content and reasoning aloud about specific choices.  The more detailed you are about what’s running through your mind, the better!

Reflect and discuss as a group.   Teachers will see things that technologists won’t and vice versa.  Everyone should have a chance to give insight and offer constructive feedback.  Be sure to video document and/or to have one team member serve as a scribe!