Todd Warfel, by way of a comment he made on my recent article on B&A, re-introduced me to ProtoNotes. I remember hearing of it a year or so ago and thought it seemed an interesting concept, but then sort of wrote it off because it only worked in IE :(

But apparently ProtoNotes was re-launched a few months back, and now seems to be a far more palatable and potentially useful service. On the plus side, it’s a very simple concept. You essentially register with the website, after which they send you a JavaScript snippet that you can then just drop into the header of your XHTML prototype. Then, when viewing your prototype, you get a nice toolboar on top, where you can add new notes, view current notes, as well is view a list of all notes applied to that template. And maybe most important of all, you can hide the toolbar, so as to not confuse non-technical users who might think that the ProtoNotes toolbar is part of your design. There are also a few customization options, including the ability to store your notes in your MySQL database.

The one huge drawback that I see with the current version of the concept is that it is a hosted service. In other words, let’s say I’m showing my prototype to a client and, for whatever reason, the ProtoNotes site is down, and without warning my annotations aren’t accessible. Not good. For that reason, it seems me that ProtoNotes should optionally be made available as downloadable and locally installable package, eliminating the dependency on the service.

I also think there could be a non-branded version that would be available for purchase. (I.e. that doesn’t have the ProtoNotes logo on it.)

Overall, though, I think it’s a really great concept.

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.