in Prototyping

Three Reasons Why I Don’t Use Prototyping Tools

I remember when I first started using prototyping tools, i.e. software designed specifically for prototyping. The idea of a tool where I could quickly create a simulation of my design idea and present it to users without needing to write a line of code just seemed too good to be true. I was convinced it would be the salvation to all my design challenges. What I instead discovered, after several years of using most of the major tools on the market at the time, was that a prototyping tool, in most situations, in fact is not a great approach to accomplish the goal of designing a great user experience. Sure, there are definitely are situations where using these tools make sense. But if you’re thinking of incorporating prototyping tools into your practice, these are some things to consider.

1 – Prototyping Tools are Inherently Based on the Old; Design is Inherently about the New

Some years ago, I was working on a prototype for a web-desktop hybrid application. One key scenario I needed to simulate was the ability to display an alert on the user’s desktop and then allow the user to click on the alert, which would open a browser window and display a page where the user could take action on the alert. Seems pretty straightforward right? As it turned out, because web-desktop hybrid apps were just coming into vogue at the time, this top-of-the-line prototyping tool did not support the ability to open a new browser window and then have the prototyping experience continue in that window. Sure, they may have added that ability by now, but that sort of makes my point. Prototyping tools are in a continual state of playing catch-up with the rapidly evolving state of the art of user experience paradigms. And in their current form, they will always be playing catch-up, always containing a set of widgets and features that are either a little or (more likely) very outdated. This effectively means that they create an artificial design constraint, limiting you to what the prototype can accomplish rather than what truly can be accomplished by the production technology.

2 – Prototyping Tools are Inherently Technology-specific

The technology used to implement an application will have a significant impact on user experience. Something, for example, built with Flex/Flash will feel very different from something built with XHTML, CSS, and JavaScript. Since the point in your project when you are prototyping is before you have started building the actual application, that also means that you may not have chosen an implementation technology. But a prototyping tool is inherently going to use a specific technology to generate the prototype, and if it is not the same as the production technology, stakeholders that have been using your prototype will be in for a surprise when they see the real thing.

3 – Prototyping Tools Only Create the Illusion of Validating a Design Solution

A prototype may give you a sense of if your design solution has merit, but it won’t actually confirm if its the right solution. For example, the prototyping tool will almost certainly not generate the interface in the same way that it would when built with the actual technology.

On a project that I worked on, I created a prototype with a tabbed interface. In my prototype, one could go from tab to tab without a page refresh. This prototype went through several team and user reviews and we were all happy with it. But then, when time came to build the actual thing, it turned out that it would not be possible to go from tab to tab without a page refresh, making the feature far less palatable.

The impact of that discovery was so significant that we had to abandon the whole tab concept and undergo the costly effort of redesigning an application that already was in production. The prototyping tool had created an illusion of a good solution, delaying the point when we discovered a problem with our idea.

In other words, this means that—ultimately—you will always have to vet the solution using the actual technology, which is another key reason for prototyping your idea using the production technology, or else risk not discovering design issues related to the technology until you go into production.

So what’s the alternative?

My recommendation, when it comes to prototyping, is to either be technology-agnostic or technology-specific. In other words, either use something that doesn’t dictate a specific technology, such as paper prototypes or wireframes, in the early stages of design. Then, once the design has matured, use the actual production technology. In my experience, the benefits of that approach far exceed any drawbacks.

  1. Philip – I completely agree with you that one should focus first on design solutions that work for people, but I think I might differ with you a bit on how that is accomplished.

    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.

  2. I think you’re a bit too concerned with the technical implementation, rather than the design solution.

    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

  3. Interesting post and I’m inclined to agree strongly with what you’re saying about the tools playing catch-up. It can be hard to describe asynchronous interactions, for example.

    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!

  4. Hi Peldi – Balsamiq has actually been on my list of tools to check out (thanks to Victor pointing it out to me a while back.) Would be happy to review it.

  5. Todd-

    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.

  6. Hi Anders, I agree with you. A lot of prototyping tools try to do too much, trying to get you as close as possible to what the final implementation will look and behave like. Not only this makes them very complex to use, but forces them to be tied to a specific implementation technology, which they’ll never be able to mimic fully.

    When Building Balsamiq 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.

  7. My biggest beef with “prototyping tools” is the first one you highlight. Since most of them leverage pre-canned solutions, you’re inherently not going to innovate. Can you? Sure. But they promote a certain laziness to innovation. You’re given a set of prescriptive solutions and are not pushed to try something new.

    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.

Comments are closed.


  • Some Thoughts About the Balsamiq Mockup Tool — Anders October 29, 2008

    […] is, of course, a slight irony in that only a few days ago, I was writing about why I don’t use prototyping tools, and here I am writing a review of a prototyping tool. Well, not quite. I think Balsamiq is […]

  • Three Reasons Not to Use Prototyping Tools | October 29, 2008

    […] Ramsay has a great post on why he doesn’t use prototyping tools. His biggest problem with prototyping tools […]