One of the advantages of prototyping is the ability to work through a design concept. A team at Ford discuss the design thinking behind their Verve concept car. Pay attention around 1:25 left. You’ll see a guy prototyping rims for the car. It’s an interesting look at combining sketching and prototyping.
What can apply from this to software prototyping?
This highly detailed, practical, and hands on workshop will provide a framework for creating and testing paper prototypes. When you leave this workshop, you’ll be equipped to create and use paper prototypes for your own projects.
We’ll discuss what paper prototyping is, when to use it, when not to use other methods, and what to expect. We’ll explore different techniques for paper prototyping, including methods for handling challenges with simulating interactivity, representing transitions with paper prototypes, and what to do when something unexpected happens.
Two common reasons for prototyping are to get internal buy-in and to gauge technical feasibility. But one of the best reason to prototype is to work through a design.
This little insight came through an interview I did earlier this week with Jed Wood. Jed mentioned that for him, the way product designers use sketching to work through a design, he sees prototyping as a way to work through a design.
That got me thinking about something I saw earlier this week during First Friday’s here in center city Philadelphia. One of the artists was throwing pottery (shaping it) outside his studio. The interesting thing about throwing pottery is that if something goes wrong during the process, you can simply scrap the piece you’re working on, collapse it onto itself, and start over again from scratch.
The same concept follows for prototyping. Prototypes are not meant to be a final product – they’re typically meant to be a throw away. So, don’t get too attached to your prototype – you need to be willing to throw it out.
I’ve often been asked what’s my tool of choice for prototyping and my answer is always the same – it depends. It depends on what I’m trying to do, what the business is trying to accomplish, and what we need to test or show. The goals of the prototype drive what tool I’ll choose or recommend.
If all we need to do is test a few scenarios with little functionality, then a basic Flash prototype or series of images stitched together with HTML and some image maps will do the trick just fine. If we’re testing high-level concepts and have an existing set of wireframes, then I might recommend doing paper – if I’m confident we can simulate any interactivity that is critical to the goals.
Right now, my tools of choice are paper (with my little toolkit of UI widgets), HTML/CSS, and Flash. However, I’m really excited about trying out Fireworks to see how it does. In fact, I’ve got a prototype project coming up next week that I might try using Fireworks for.
What about you? What are your tools of choice and why?
I’ve been doing a great deal of protoyping and prototype testing lately – surprise.
Last fall, I got to test an extremely high-fidelity rich AJAX app for IntraLinks. This prototype was highly interactive and used to test a number of new design concepts, get internal buy-in, show what could be done, and gauge technical feasibility.
Not too long before that, we built a Flash prototype for a company who wanted to showcase their RFID tracking software. This prototype was used to get internal buy-in and show the concept at trade shows as a marketing tool.
Currently, we’re testing a number of prototypes for the LA Times. Some are paper, some are HTML. They too have a number of goals and uses from getting buy-in, to testing design concepts, to seeing if the technology team can build it (or how they will build it).
I’ve had a number of discussions with people since the announcement of the book. And a few things are very clear:
- People are really excited about the book
- People have a lot of questions about prototyping
Many of the questions I’m getting so far relate to recommendations on tools and methods (there’s an entire section devoted to this in the book). Other questions are around when to prototype, or where it fits into the design/development process. And still others are around how to trim down the entire process, finding a way to use prototyping to reduce the cycles.
So, let me ask you a couple of questions:
- What do you hope to see in this book, or get out of this book?
- What do you hope is not in this book?
- What questions do hope this book will answer for you?
- What would make this book a waist of your time?
I’ve been asked a number of times where prototyping fits into the design/development process. A number of years ago I would have said after you do some design. At this year’s IA Summit, Gene Smith was discussing the process they went through for designing a product for nForm. He talked about how he had prototyped some of the screens and then went back and did wireframes.
That’s when I had one of those dejavu moments. That’s exactly what I had done for a new product/service we’re building for my company, Messagefirst. We had started talking about the design, then sketched out some screens. In the interest of getting things done (GTD), I decided to just prototype out some screens in HTML. Shortly after, I realized that some of the ideas in the sketches wouldn’t work that well. So, I did some more prototyping and then went back in to flesh out some of the details with wireframes afterwards.
Where does prototyping fit into your design/development process?