Fail early, fail often: my first experience with rapid prototyping

This summer, I’m interning at Dubberly Design Office, an interaction design studio in San Francisco. My first week consisted mostly of 10-hour days manning the copier in preparation for a week-long interaction design workshop we were putting together for Samsung’s design group. The next week, I got the incredible opportunity to assist with and sit in on the week’s lectures; manning the copier paid off. I heard Alan Cooper on user profiles, Rick Robinson on ethnographic research, and Shelley Evenson on making models out of research data. It was an educational smorgasbord. I’m still digesting it all, but what stuck with me was the concept of rapid prototyping.

The basic process goes like this: research, think, prototype, think prototype (repeat as many times as you can afford to,) then create! The idea is to learn as much as you can in the beginning of a project by “front loading” it with research, prototypes, and conversation among the parties involved.

After the workshop, my next project was to generate several very simple working demos of how poetry could be enhanced via the interactivity of the web. These would be shown to clients and other designers to stoke their creativity, leading to the generation of more ideas.

My first instinct was to learn Javascript to create a demo of the effects I had in mind. I have decent HTML and CSS skills, and had been looking forward to learning a little Javascript. So for the first few days, I scoured the web for tutorials, camped at Borders bookstore, and went cross-eyed looking at code. After a few days, I knew I was in over my head, and wasting time quickly.

The situation didn’t call for nerdy-beautiful, standards-compliant web pages. This was a brainstorm, an interactive sketch, not a golden master. I recalled the rapid prototyping credo: “Fail early (when you can still afford to,) fail often (so you can learn as much as possible.)”

I decided to use a tool I knew well, Adobe ImageReady’s rollover effects. My web page mock-ups became screenshots linked with hacky rollovers. Sure, the code was bloated, but I did it in an afternoon and got feedback the same day. I quickly gained new insights into my initial ideas and was able to alter my course of action before investing loads of time and resources learning a scripting language.

This experience taught me:

1. Don’t be perfect, just get it done In early stages of the planning process, get something—-a model, a demo, a prototype—-working as quickly and cheaply as possible.
2. Interate often Test it and do it again and again. This way, you can begin steering a design in the right direction before it becomes too costly to change course.