This form does not yet contain any fields.
    « New Directions - Live, hands-on LUXr Lean UX Workshops | Main | Touch UI: Gestural and mobile prototyping »

    Inspired: D3 Talk - Tom Chi

    A little more than 2 weeks have passed and I'm still reflecting on and playing out Tom Chi's D3 Rapid Prototyping X talk. It was a really wonderful way to start this year's D3 conference.

    When he started speaking, Tom seemed a tad distracted. It seems that he was still thinking about what Jennifer and Jody had talked about in their opening remarks. "Local - social - mobile aren't fads. Things have always been that way, we're just getting technology that allows us to explore that." And then he was back to telling about rapid prototyping - Google X style. As the experience lead of Google X, the R&D team at Google that has brought us intriguing prototypes such as the self-driving car and Google Goggles, Tom showed us how his team works.


    "How long do you think it would take to create a physical prototype for Google Goggles?" The crowd guessed a few days, weeks, months. Throwing an image up on the screen - he comments, "1 hour." Then he showed how his prototype, created from a Netbook, Pico projector, coat hanger, and screen from a sheet projector actually does provide the EXPERIENCE of seeing additions to reality through a layover lens. This is not about the final form and version. This is about creating an experience that can then be tested and tweaked - as quickly as possible. The rest of the day was used for multiple experiments in software and input to the system. Could they create a finger mouse? Could they use any surface to control the interface?

    Then he moved to an image of Tom Cruise in front of the gestural interface from Minority Report. Throwing a slide up on-screen which shows a coat hanger above a whiteboard, with an input he created out of chopsticks, a binder clip, pen and presentation clicker. Using this 45-minute prototype he was off and experimenting with gestures and software that changes its response to how you move your hands - pointing to select, grabbing an email. By fast prototyping in this way you're learning things that you can't learn any other way. As the creator of the prototype you experiment and use it in the ways that make sense to you. You create new rules and gestures.

    Then when you invite others in to play, you learn even more as you watch them interacting. See how they do a small flick when you thought a grand gesture was a better way to move through pictures. Watch them as they begin to slow down and rub their shoulders. Ask them what's going on - their shoulders are sore. Eventually the team figured out that if you keep gestures below the heart and in the "batting box" that you can use them all day. Above the heart creates soreness and fatigue to the muscles. All this from a 45-minute prototype and tons of experiments with it over a single day.

    The main point of this - get to as real an experience as you can as soon as possible. You're going to learn the lesson at some point anyway, so why not learn it now?

    Moving back to Google Goggles he showed pictures of some of the multitude of different forms that others had created for this type of device. As they began looking at the final form of the product the team followed the same process and created a single line of modeling wire that would hold the experiments to the face. Then they carefully cut and measured pieces of clay to match the exact weight of some of the components they were thinking of using for the device. This allowed them to wrap the pieces around the wire in as many ways and combinations as they could come up with. They discovered when testing weight, balance and comfort of wear that putting the heaviest weight behind the ear allowed the highest comfort because it used the ear as a fulcrum rather than the bridge of the nose.

    "And we were already aware of how strong the ears are...<small grin> but that was a different experiment."

    "Don't get dazzled by technological frameworks. Ask yourself what is the most basic question we're trying to answer. What are you trying to learn? How can I get to something to test that in an hour or less?"


    Moving on to the theory behind the practice he showed how bringing down the time to create your prototypes maximizes the rate of learning. He points out that increasing the total number of experiments you do, increases your overall chance at success. Since we tend to fill the time we expect a task to take - think it'll take 4 months, takes 4 months - we can work toward high-speed prototypes by unhooking ourselves from fit and finish expectations. His team uses rate-based goals to maximize and constrain this process.

    Don't guess. Learn.

    He points out that while we're really good at the actual development of our products, we really aren't very practiced at the entry to the process - the research phase. So often we jump to the end point - the possible outcomes of "what our product could be" - talking and guessing as to what it could be. Then the most senior person in the room chooses what they think the best option will be and we go and start prototyping.

    We're physical beings. So work in that medium.

    This is backwards. Outcome-based goals assume that you already know what you're making. Don't spend time talking, sketching or creating words to describe the possibilities. It's about building - and learning from that. With fast prototyping research phase at the front of your process you can explore a much larger range of possibility, much more quickly, with a more accurate read of the market that the product will launch into or disrupt. It's important to note that this is not about what it looks like, it really is about getting the correct FEEL as quickly as we can.

    On Google Goggles, rate-based goal was to produce 15 hardware prototypes a week for 10 weeks.

    Don't fail. Learn.

    He feels that the idea of "failing faster" isn't the point. You can fail without learning and learn without failing. Rather than shaming each other for supposed failures, tell the team about the tiny percentage that did work so that we can learn together and move forward with that knowledge. Know what directions that you aren't going to pursue but keep doing variants on the prototypes that are heading in good directions. This is not a free-for-all. It's important to discriminate and determine which of the experiments are answering your questions and providing the learning you need.

    On the Google X team, each Friday they show what worked and what didn't from the 15 experiments. Magical or "that has to be in the product" moments were starred. Then they planned for what experiments would be continued or new directions they wanted to try. Some weeks this would produce 40 or more stars. At the end of the 10 weeks there were hundreds of stars or important learnings from the process. The team then begins "constellating" by creating groupings or constellations of features and experiences that would make for a coherent, desirable product. Stepping back to look at the constellations, a decision is made on which to pursue and the development phase begins.

    Benefits of Rate-based goals

    1. Simple way to measure progress
    2. Immediately actionable - no more waiting
    3. Allows you evaluate experiments faster
    4. When you can evaluate faster, you can experiment faster

    Try ludicrous things. Don't need to spending time arguing about what "shouldn't" do. Since we've lowered the cost in terms of time, let's do it and experience it together. Can lead to happy accidents and new directions, or at least a few more possible outcomes that won't be used.

    Definitely need to set a limit on when you will stop this process because of the nature of this type of creativity. Each pass only increases the creativity and speed of the team. At some point you need to stop and get to the next phase - getting your product produced and out into the world.

    A question from the audience was about what he was looking for in the people on his team when he was working to accomplish things like 15 prototypes a week. He said he likes to look for Pi shaped people who have good generalist tendencies but also have a deeper knowledge of at least one right-brain and one left-brain skillset. This way they could pull on both sides to do some of the work needed in balancing creativity with real-world editing of their efforts. Nice to have people that can do that internally rather than needing to get that kind of validation from outside via committee. He's also seen partnerships of people to form this kind of a type of loop work really well.

    Another question was about documentation. He felt that you needed to stay with communicating the "feel" of the feature and product rather than the specs of what it should be. Just as a composer creates, putting notes on the page to help recall the path that was traveled, so a prototype is the communication of what needs to be built. If there is guessing as to the intention in that process then it becomes something else. There's a disconnect in learning from one stage to the next. Better to let the person listen to the composer playing the piece - communicating via experience "this is what I want." We want to do the same. "This works, do it like this."

    Personal shifts

    This was a timely talk for me. As I struggle to find work that fits, there's an obvious "problem" that requires experimentation and doing in my life. Tom was quick to point out that this type of process works across everything in our lives. i agree. Currently, I'm in the midst of a 3 week design portfolio research process. I plan on using my learning from creating 5 or more prototypes a week to create a class that allows others to prototype their own portfolios. This is perfect for a hybrid Skillshare class and I look forward to learning together. Did you notice the amazing amount of energy and focus in that little waterfall of doing? So powerful.

    Already this process is shaking out tons of bad habits. I've become a thinker rather than a doer in the past few years. It feels amazing to simply move back into trying things and seeing what happens. I promise to report back on my learning in a future post.

    Rapid Prototyping X by Tom Chi from Kicker Studio on Vimeo.


    Reader Comments

    There are no comments for this journal entry. To create a new comment, use the form below.

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    All HTML will be escaped. Hyperlinks will be created for URLs automatically.