On 6/3/08, Oleg Krupnov <[EMAIL PROTECTED]> wrote: > > > I called the guy's attention to this point, but he said that there's never > anything so greatly innovative that is capable of making the entire hi-fi > prototype invalid, and the minor corrections can be made directly in the > hi-fi prototype. They do inject new stuff and give old stuff refreshed > look, > but after years of practice, they developed typical solutions for most of > things. So actually they skip the "early-stage" prototyping entirely.
Ah. Well, that changes things. You've got a hi-fi prototype already, and apparently someone to manage it. : ) I don't know if this is a good practice or bad practice, but it sounds > reasonable and I wonder how many people do exactly like this. Can you give > an example when early stage prototyping is required? My situation is that I'm an external consultant who works on a lot of from-scratch or wreck-and-rebuild projects. So for me, if there is any hint of interactivity on a system I'll prototype it first. But even on very simple content sites where paper prototype testing would be fine, I do interactive prototyping. It's just easier for me. Also, many of our clients have a user base that is spread out throughout the country (and in some cases the world). It's MUCH easier to do remote testing with an interactive prototype than, say, a clickable PDF. But in your case, I think your colleague nailed it. You do early stage prototyping when you've got something that's so innovative you don't have any way to judge how effective it will be. On one project, I came up with this map-based interaction that was intended to help people find vacation property and encourage them to start planning to purchase it. I had no idea if it would work. I did a rough prototype, tested *just that interaction*, learned that mostly it worked well but that it shouldn't be the *only* way to search. Just a thought: Paradoxically, the more innovative an interaction is, the > more rapid prototyping is needed, but the less the rapid tools are capable, > because they are based on predefined widgets. And in reverse, the more > standard an interaction is, the less is the need to do rapid prototyping of > it, and the more readily the ability to do so is available in the rapid > tools. Yes! And that's why I taught a workshop on prototyping RIAs in Axure at the 2007 IA Summit. : ) The tools are very basic, but with a bit of creativity & hacking, you can really go a long way. The only interaction I've had trouble prototyping is drag & drop. But I do have good ways of faking it in Axure. I agree exactly. Here Axure makes a good point. Perhaps the best of all its > points. However, isn't it somewhat lacking the freedom of drawing, like in > Visio or Omnigraffle, not to mention pixel-perfect tools like Photoshop? Photoshop it is not, but it has all but replaced Visio for me. I can get any shape I need except, strangely, for circles. : ) What my friend obviously means is that once they have a special guy for > building hi-fi HTML prototypes, he doesn't want to spend his own precious > time to implement interactivity in the prototypes. He is done with just > annotated wireframes in Visio. Yes, in your situation that is true. You're lucky to have a dedicated prototyper! Take care, F. ________________________________________________________________ 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
