Yes, if you know Flash really well, it can be great for doing a freeform exploration of ideas. But that to me, however, is just sketching, just trying stuff out. To be clear, my reason for not using tools designed specifically for prototyping (and I would not place Flash in that category, as it is primarily a production tool), goes far beyond performance.

If you were to only prototype a solution in Flash that is going to be implemented with XHMTL/CSS/JS or .NET or whatever, you are going down a risky path indeed. Users may love interacting with the Flash prototype. But that experience is likely to be very different when implemented with a different technology, which means you might be setting yourself up for a lot of disappointed users – and, in my experience, that is not a good thing for repeat business.

More importantly, technological issues that simply can’t be discovered when prototyping with a different technology will be discovered much later in the game. So, the bottom line, IMO is: start your exploration with any tool that you’re comfortable with or can work quickly with, such as Flash. But once the idea has matured, start exploring the solution with the actual production technology. Not prototyping using the actual production technology at that point, I think would be big mistake.

I agree that performance has a big impact on usability. But unless you’re testing with live data in a live environment under real conditions you’re never going to get an accurate sense of performance. You still get many false positives and even a few false negatives.

In my experience, when performance problems emerge as a result of my original solution then there’s almost always an alternative that’s a slight-of-hand variant that can deliver essentially the same functionality without the performance hit.

To me, it’s more important to focus on design solutions that work for people first and foremost, even based on ideal conditions, and then creatively engineer an optimal technical solution around that. That has always produced the best results for me.

My prototyping tool of choice is Flash. It’s a great drawing tool, so your prototypes can be as lo-fi or as hi-fi as you want. Plus, you can create very simple or very sophisticated interactivity – that works in any browser.

With Flash there is no limitation to the concepts and feature ideas that you can simulate.

Philip Fierlinger
http://skyrize.com

I’ve reached a point on a few occasions in the recent past at which I’ve thought “I may as well just build this” so complex does the prototype start to become. It can be a hard balance to strike.

I wouldn’t necessarily agree that they’re just for non-technical users, but you do sometimes wonder whether they’re helping or hindering, particularly during the more hectic iterative processes!

Yes, I do agree that many of these prototyping tools are targeted (in part) to non-technical business users, and that it sometimes can be valuable to get a simulation rather than a writeup, but I also think a there is the issue of the marginal benefit of a simulation vs some sketches. In other words, how much more value or information would you, as the designer, gather from an Axure prototype (which, because they are not technically inclined will likely take them a little while to create) compared to just receiving some drawings and a supporting description from the non-technical business analyst (which they would likely be able to produce much faster and which are not constrained by what the prototyping tool can do.) Again, I think your point is valid, but I’m not sure if the marginal benefit would be very high.

When Building Balsamiq Mockups ( http://www.balsamiq.com/products/mockups ), I took a different approach: I don’t try to be high-fidelity – in fact, I try to be as close to pencil and paper as I can – and I don’t offer interaction (it’s a highly requested feature, but I fear heading there for the reasons outlined above). In other words, Mockups is a wireframing app, not a prototyping app.

As for my app being “in a continual state of playing catch-up with the rapidly evolving state of the art of user experience paradigms”, I can’t argue with that. The good thing about my situation is that I can keep adding controls easily (it’s just a matter of my wife drawing them and me coding them in a little bit), and with the upcoming 1.5 release users will be able to import their own images into the mockup.

I’d love to hear your input on my little tool. Send me an email if you’d like a full license to review it properly.

This is one of the reasons all of my designs start out as paper sketches. I create the design on paper first, which knows no boundaries, and then figure out a way to make it happen in either HTML or sometimes Flash.

However, I don’t think these prototyping tools are for people like you and me — they’re for people who can’t code, or choose not to for that particular project. They’re great for a business analyst or product manager who wants to use them to communicate a particular concept visually rather than write a 60 document to describe it.

I’d much rather get a simulated prototype from Axure, Fireworks, Visio, or Powerpoint than a 30-60 page document trying to describe their idea. We’ve actually had pretty good success taking Powerpoint prototype from clients, deconstructing them with a client in a design studio setting, sketching the “real” solution with them, which is based on the prototype they provide, and then building the “real” prototype in our HTML framework we use.