You’ve heard the old saying is that a picture is worth a thousand words. If you are innovating, what you want to do is supply maybe three hundred or so to prime the picture pump and then listen for the rest. We hound people about prototyping early and often to get great user feedback and focus on the really good ideas. An experience we had this week drove home to me the importance of the just-enough picture imperfect prototype.
The other day we demonstrated a prototype to a group we’ve been working with recently. We’d been through several meetings understanding their process and got to the point where we knew the basic approach people who use it take. We’d been talking, doing some sketches, but the implementation just wasn’t clicking until we—you guessed it—produced a quick and dirty prototype.
We needed to be able to program and control some basic shapes and connections on the screen, show some stuff when you rolled over the connectors and shapes, and we needed a rudimentary database to drive the whole thing. It needed to look like the web application it would eventually become. Lots of times we use Excel for rapid prototyping, and, knowing it has drawing elements, we decided to give it a whirl. Turns out it was perfect. Turn off the grid lines, put some hyperlinks in some of the cells in the first column, freeze the first column so as you scroll it stays in one place and blamo! you have something that looks like a web page. If you’ll pardon the geek speak, one of the great things about Excel is that you can record a macro to do something, say insert a shape and name it, and then go in and copy that code. Rapid coding, it’s all in one file, and it’s easy to distribute. Great for prototyping.
When we showed it, the group instantly got it. They took the picture we could create on the fly and started adding to it, making comments on how it should work, and we ended up with a basic requirements document. It would have taken months to get there by just discussing and I know we would have missed some of the requirements.
A major point is that the prototype was incomplete. On purpose. We left some simple stuff out (e.g., color coding) we knew they’d suggest. Why? Because that gave them a start. Once they added to the picture, they felt comfortable adding more. And that’s really important, because it became everyone’s, not just ours.
That’s why I think it’s important to prototype just enough to get the juices going. If you go too far, it looks to complete and people are afraid to mess with it. With the evolution of applications that allow us to make everything look perfect, we’ve also made it less comfortable for people to think they can make adjustments. You might tinker with an old car or give your kids an old radio to take apart, but no way will you mess with the new shiny one. The presentation gets in the way. Presentation is everything and sometimes everything is way too much.
We really shy away from presenting application prototypes on projectors as well. Flip on the projector and everyone goes into movie mode—they watch, but it doesn’t seem as interactive as everyone huddled around a screen.
The point is that imperfection is the goal in the beginning of innovation. Make a prototype that people feel comfortable working with. Suggest half-baked ideas—if they’re fully baked, you’ll lose the flavor someone else can provide. If you’re brainstorming, don’t worry about spelling. We had a person recently tell us that they’d like a spell checker for our brainstorming product so they could fix the spelling when they entered an idea. If you are worried about spelling, you are focusing on the wrong thing. I want you thinking about the ideas you are contributing, not the spelling. Do you think Google would have passed the spell checker five years ago?
So, if you want to get to the real requirements, if you want people to really contribute, make the initial pass look like a rough draft. Don’t polish it too much. A picture may be worth a thousand words, but most of those words should come from the people who are going to use the picture.
Comments