But the big problem with these tools is that they create a very sophisticated illusion of something that does not exist, meaning that while customers think everything they see will work just the way it works in the prototype, the actual experience built with real code may be very different. For that reason, it’s critical not to assume that a prototype is a validation of your idea, and that you actually have to build it to know if and how your solution really will work.

I’m the sole UX designer in my development shop, and while we have developers who understand markup and CSS, the largest portion of XHTML, JavaScript, and CSS work usually falls to me. Because of having to wear multiple hats of designer, lead, and trench-coder, I find that prototyping in XHTML helps me combine project phases and alleviate bottlenecks (not to mention that there isn’t a graphic design department to hand my sketches to).

The best two aspects for me would definitely be code reuse and catching “gotchas”. Having the actual markup ready by the time the prototype gets the “OK”, with maybe a few small tweaks, has increased our team’s efficiency. I’ve been able to pass the prototype on to other developers, with very little training or question answering after the fact. I don’t want to say that it enables “cut and paste” development, but there is definitely a lower learning curve for everyone.

Also, getting to see how realistic a design is in a browser, rather than Illustrator, is a huge benefit and helps us get out in front of possible issues much earlier in the development cycle. I shudder to think at how many pie-in-the-sky faux interfaces were approved in my department a few years ago, only to find that parts of them would take an inordinate amount of hours to pull off. On the flip side, having a realistic prototype that people can actually “click on” has given prototypes more of a “wow” factor than before–an idea that challenges my former love for the static graphic prototype.

In other words, if I have an idea for a design solution, I will only be able to simulate it with a prototyping tool if whatever widget or behavior I want to use is supported by that tool. (For example, if I want to prototype drag and drop behavior, but my tool does not support that, this is an artificial constraint that has nothing to do with the real-world solution.) A Google search, however, would reveal what the latest and greatest ideas are out there relating to that idea, essentially what the state of the art is. And I might be giving Google too much credit in being able to show that, but the larger point is to simply to use the web itself to see what the limits are of what has been accomplished so far. And, more importantly, to be able to *build on those ideas* rather than being constrained by a certain prototyping technology.

In my experience, there are major problems with HTML prototypes:

1. HTML + CSS need to be well formed to look/work properly, requiring too much time + effort to build the prototype, time that should be spent designing and refining your concepts.

2. Design refinements are painful and time consuming because you have to re-engineer your code.

3. Re-engineering makes you reluctant to make significant changes, so you end up exploring fewer alternatives (the main purpose of prototyping).

4. There is a natural inclination to build on top of the prototype code, as the starting point for the production code. Prototype code, by it’s definition, is a hack. That’s an awful starting point for production code.

I find Flash to be the ideal prototyping tool.

Flash is a drawing tool – you just draw your design, no coding whatsoever, so significant changes take no time at all. Plus, it’s 100% compatible in ALL browsers.

If you want to make an interactive prototype then Flash can be coded with one basic line of Actionscript: onRelease.gotoAndStop(frame).

If you want to build more complex functionality with drag-and-drop then you can, and it requires less expertise than Javascript. Again, it’s 100% compatible in ALL browsers.

Flash prototypes won’t be completely identical to the final experience, but no prototype is. Flash prototypes can be as lo-fi or as hi-fi as you want. With Flash there is no limitation to the concepts and feature ideas that you can simulate – it’s an unlimited toolbox.

With Flash you explore more ideas, more quickly, producing better solutions. It’s as simple as that.

Philip Fierlinger
http://skyrize.com

The points you raise above seem to tell me that I may have not done such a good job of communicating a fundamental aspect of the methodology I described in the article. In the iterative development methodology, after having done some sketching and prototyping, using everything from pen and paper to Flash or whatever, you then actually *fully implement* that unit of the application. In other words, you are at that point *not* prototyping, you are actually building. Then, for later iterations, you can take the XHTML/CSS/JS production files and use them as a starting point for prototypes for other application units or updates to that unit. I’ve done this many times, and it is incredibly efficient and powerful. I realize that, particularly since the article is titled “Prototyping with…” that this may be a bit confusing. And the fact that iterative development is a completely different paradigm compared to traditional waterfall probably doesn’t help much either.