On Feb 28, 2009, at 3:14 PM, Adam Korman wrote:
Tools that are the same or similar to what will be used to build the final product always score the best, and there's a drop-off whether you use more or less sophisticated tools. By this measure, the chart shows that there's never a good reason to create a paper prototype or click-through screenshots. In fact, by choosing the term "Acceptable" as the middle rating, you are suggesting that paper and click-throughs are always unacceptable prototyping methods (because their average rating in all cases is less than "acceptable").
When compared to the other methods for the purpose of making a product prototype, those methods are of lesser value. That's no different in any other design profession for what it's worth, so I'm not sure why there's some value judgement needed in that regard.
Now, are those methods "bad" or "wrong." No. They are merely acceptable. I use them all of the time. Are you suggesting that testing the behavior of a slider control with a paper prototype is better than a fully interactive one done on JavaScript?
I think there are two important criteria that might start to balance things out: (a) degree of specialized skills required to develop the prototype and (b) level of effort to build and maintain the prototype. If you have to hire someone to build prototypes, that may not be an acceptable investment to get "optimal" results.
Why is balance needed? They are just prototyping methods. The methods themselves don't have any need to feel balanced, they are simply tools and means to help design and build products.
And hiring someone to build a prototype is partly the purpose of the chart. If you want to convince your managers and CFOs that you need the budget to hire people to build prototypes to get all those things I've listed, I've given you the tool top do so. If your execs want the things listed in the chart and be able to see and iterate and work faster, then yes, you will absolutely have to hire if you don't have the skills in-house. Why is that bad thing?
More, get the budget to get time to retrain yourself on newer coding methods and whatnot. Again, writing code and making stuff with your own hands is fun. It's why I got into design instead pushing paper at a desk.
That said, I still think there's a bigger problem with the slant in favor of reusability. It's been my experience that the more time and effort you invest in a realistic, reusable prototype, the more of a vested interest you have in believing that you already have the right answer.
That is entirely 180 degrees the opposite of my experience. On all projects I've built and designed where more realistic and accurate prototypes have been part of the process, iteration has far exceeded any other means. The main reason is that very large interaction problems become extremely obvious and are exposed far earlier in the schedule.
In fact, it is without more robust prototypes where teams dig in because they run out of time and decisions have to stick for shipping and everyone just waits and see how the final product tests in the field instead of changing things during the design process.
The reusability metric is how the way I make it palpable to people who pay the checks. I find that means of communicating the value of the prototype (along with time savings and iteration) works well.
In other words, if you've spent a lot of time creating assets (graphics, code, behavior) that you expect to reuse in the final product, the more attached you become to those assets.
Absolutely not. And people who do that tend to do that regardless of prototyping methodology. That's a problem inherent with someone who hasn't been trained properly on how to iterate fast and throw away a lot of design work generally speaking.
When there is no expectation that the assets for the prototype will be reused, development of the prototype is faster and it's easier to toss things out that are wrong or don't work as expected.
See above.
Now if you already know you're right, a hyper-realistic prototype with reusable code and graphic assets may be useful. This brings up an important missing piece from the chart, which is any discussion of the goal of creating the prototype and how different mediums may be more or less appropriate for different goals. If your goal is to test overall concepts, I think this chart is totally misleading. If the goal is to test if your concepts are possible given the technology, the chart seems more reasonable.
Again... 180 degrees from my experience. In fact, this past week we had one of those scenarios where creating a prototype had to be done with real code to get a true sense of the thing we wanted to do. We're designing a new email marketing product for a client. The team had been brainstorming all sorts of models and means to create structural layouts, and on paper, the idea we had wanted to try wasn't reading very well, even to ourselves. So we built a quick JQuery based version of the idea -- something that took all of one afternoon -- so we could try it out. We then showed that to the client, and they could now see the interaction live and in person and see for real what the idea was.
Now we're moving forward with that direction, one that we could never have done with paper prototyping, click-throughs etc. And it's probably going to be a decision that sticks. Given a 16 week schedule to design and build something from scratch that is production ready, that's a very big deal.
One of the things I think tends to happen in this field is people conflate "prototyping" with "sketching." In all of the discussions I've had, it seems to me that paper prototyping is one of those horribly misnamed design activities. It probably should have been called "interactive sketching." I was in fact going to leave it off the diagram for that very reason, in that I think it's a poorly named thing and not a prototype at all. But to do so I imagine I would have gotten more flack.
Further, for a field that calls itself "interaction design" I think it is high time people start to truly embrace the means and methods that will allow you to design... Interaction. Interaction design is not workflow diagrams. And if it ever was, it was only so on websites in the late 90s and now early 00s. Now that all this web and mobile stuff is finally starting to behave with the richness found in desktop clients from the 80s and 90s, it's high time to take back the design of the interaction by using something like JQuery to prototype the idea, not scissors, paper, glue.
-- Andrei Herasimchuk Chief Design Officer, Involution Studios innovating the digital world e. [email protected] c. +1 408 306 6422 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
