Prototyping in a Digital Age

I attended my first RefreshDC event this past Thursday. Pretty interesting I must say. For those unaware of the procedure; the venue is a room with projectors, seats, and a podium. Dude stands at the front and talks while taking questions. Clean, simple, and if kept to the timeframe…engaging.

Todd Warfel was the man presenting and his topic was prototyping. I’m a fan. I have to say he had some really interesting suggestions and ways to grab feedback. From using paper and colored cellophane to a miniature layout in html, he had a plethora of ideas. In my opinion that was where the most value came. His presentation talked of seven steps to take when prototyping for someone which were very generic and sounded like marketing babble, but when he started to talk between the points he provided a great deal of information.

The first think I want to make note of, because I feel it holds a great deal of relevance to what I do, is when to prototype. Todd mentioned that you should prototype early and often…I believe that he has this right. Early prototypes, especially when you are trying to gain requirements, is pivotal in a good product. You need to put something in front of people and find out what they like and dislike about something you plan to put time, sweat, and money into. Doing it any other way just doesn’t seem to make a lot of sense to me. Why build the requirements for a system when you haven’t thrown it at a user yet? You’ll spend significantly more to fix it later on in both branding and development work. Also, prototyping often allow you to focus your effort. You can parallelize the work of the next feature with the development of the last. And as with anything, the more you do it the better you get.

The next thing that I felt was a great takeaway was his mention of bringing in a good mediator. I don’t believe this was a point in his presentation but he mentioned it between points. In essence he mentioned that a mediator for user testing and prototyping should not try to help or suggest the answers to people. It’s generally very difficult to not help users when they are struggling, especially when you built the thing they are trying to use. However, if you really want good feedback on what does and does not work, you need to keep your mouth closed and let the user show you how they would interact with the thing you are building.

The last point I want to touch on is something that many of us in the computer industry struggle with. Everyone at one time or another find themselves discussing this topic or doing it. This is over-engineering or building too much for what you need. Joel on software recently posted in relation to a project at Microsoft related to this. The idea here is that you only prototype what you need…keep in mind this directly relates to your audience. In other words, if you are prototyping a proof-of-concept for your boss you may want to have a slightly more polished demo of your work than if you call your buddy down the street and say “he dude, check this out…” Back to the topic, supposing you are supposed to create auto-completion behavior in text boxes on a website, a good prototype would involve creating some text boxes and showing the behavior of the auto-complete. Not, developing the entire page, putting that in a form, and then building the submission controls. Narrow the scope of your prototype. The other reason to do this is because you will only be able to get so much in any testing session. Don’t build the house if you only need to show a door.