[MUSIC] In the first video, we learned that prototypes can serve as tools for communication and tools for learning. And I also talked about design as a kind of a mash-up of science and evolution, only the evolution gets dramatically accelerated by realizing ideas as prototypes, testing them and iterating. Iteration is key. Most prototypes should never be built with the expectation that they are in some sense a rough draft of the final product. Instead, most prototypes should be built with the expectation that they will help you learn. Not just learn, but learn as fast as possible. Eric Reis in his book, The Lean Startup, goes so far as to claim that the principle metric for a new venture is learning for unit time. So as you set out to prototype, you need to ask yourself and your team, what do we need to learn? And what is the prototype that will let us learn that in the least amount of time? I just want to note that in the context of our organization, this isn't all that easy to do. Many people just won't see the sense in building intentionally crude or under-featured prototypes. Guiding them in this way is an important element of leadership in the context of innovation. You are fortunate to live in a time when many types of rapid prototyping are possible for physical objects, for electronics, for software, for interfaces And even for complex experiences. While I sincerely hope that you avail yourself of these amazing resources, I also want to point out that less exotic resources can often prove quite valuable. I'm speaking about really simple and ordinary stuff, like paper, scissors, and glue, or one of the product designer's best friends, foam core. To illustrate this, let me tell you a little story from my own past experience. A number of years ago, I had the opportunity to work with a team of engineers and physical therapists to develop a new product. We had the idea that robotic technology could be used to assist the therapist. It's important to understand that at the time, efforts were being made elsewhere to develop robots that would replace the physical therapist. But we spent time in the field observing how physical therapy is actually done and realized that it is in no way, a routine or repetitive activity. Physical therapists or PT's Combined assessing patients with delivering therapy and they're constantly finding ways to keep the patients engaged and challenged. The human element is essential. So didn't make any sense for us to eliminate that. The same time therapy is physically very demanding. This is especially true in gait and balance therapy when the patient is at risk of falling. Sometimes two or three PTs will gather around a patient just to ensure safety. So we realized that gravity was the therapist's enemy, and we set out to defeat it. One idea was to lean the patient back to reduce gravity. That somehow allow normal motion of the body. We thought that a robot might make this possible, but we wanted to test the idea really fast and really cheap. Here's a picture of the first prototype. It was made from a kid's bike that was just laying around, a board of rollers that someone else had laying around from another project, and some planks of wood. The idea was that someone could lie on the planks and the rollers would allow somewhat natural side to side motion. In addition, the person could put his or her feet on the pedals. It was obviously a pedaling motion, not a walking motion, but it was close enough that we could ask if there was any value to the concept. Moreover, it got the idea out of our heads and into a form where we could all look at it and talk and even laugh together. And let me tell you, from experience, PTs and engineers don't necessarily speak the same language. So this was really helpful. In this case we saw enough value and decided to build a better prototype. Keep in mind that what we really wanted was a robot that would somehow allow a titled back patient to walk. Not a trivial thing to develop. And we still didn't know whether the concept really had value. So what to do? Well here's what we did. We used a tilting treadmill to allow a more natural gait. And two of our lead engineers are here simulating the robot. This is sometimes called Wizard of Oz prototyping. Pay no attention to the two men behind the back rest. Again, the idea is not to do rev one of the final product. But instead to learn a lot, and learn fast. Within a few days of the time that this video was shot, we had abandoned the tilting idea. We showed it to PTs and they hated it. They told us that patients need to be upright because the visual field is of great importance. But they liked the notion of protecting the patient from falling. And they agreed that any device should allow natural motion. So despite the failure of the tilt gate concept, we had actually gained a lot. Very quickly, that led to the idea of a harness mechanism that would allow really natural motion. Some brainstorming, a lot of sketching, and some creative insight led to the idea of a mechanism that could support from the hip region, allowing very natural rotations of the pelvis to occur. Here's a picture of an early prototype. In this case, we really wanted it to be at full scale to test out how it felt. But, we didn't worry about it being able to support full body weight or even allow forward walking. So it's bench mounted. Again, however we learned enough to take it the next step. While this was happening other sub systems like gravity compensation, motorized omnidirectional cart were also being developed. So here is a video of one of the first four prototypes. Emphasizing the natural, well maybe exaggerated hip motion. And here it is a generation or two later, being used as intended. The PT is working with the stroke survivor engaging him in a really challenging activity, dance. If you want to see the commercial offering that eventually came out, there's a link in the module. But for now, I'd like to close by emphasizing again, learning per unit time. Prototypes, especially in the critical early phases, should be rough and ready. Not precise, just able to communicate ideas and allow the team and other stakeholders to evaluate those ideas in as fast and as natural way as it's possible. [MUSIC]
