There 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 actually more of a sketching tool, partly because the artifacts generated from the tool don’t try to fool viewers that it’s a representation of the real thing. Some prototyping tools, particularly the higher end editions, pride themselves in being able to mimic the user experience of the actual application. Unless that simulation really truly mimics the actual user experience of the not-yet-built production version of the application, the feedback you get from users may actually be completely irrelevant. For that reason, I really like the Balsamiq approach of being overtly sketch-like, a constant reminder that this is an idea in progress, and an invitation to tear it apart as necessary.

Overall

Like McCain might’ve said, “the fundamentals of Balsamiq are sound.” No, but seriously, I think the fundamental concept of a light-weight tool with ready-made sketch-like widgets can be a very effective model for quickly roughing out and sharing ideas. Overall, I think Balsamiq is a tool with a lot of potential, and certainly a worthy competitor to Gliffy (or a complement, since Gliffy seems to focus more on diagramming.) In its current form (I was trying version 1.5), I think I’d definitely add it to my toolbox, but for reasons I list below, the times when it would make sense for me to use it would likely be narrow.

Access/Setup

Having to download an application like this feels a little old-skool. Seems like it should be possible to use the tool directly within a browser (and I’m guessing that’s something we’ll see in a future version.)

User Interface

Somewhat ironically, one area that really could use improvement is the user interface of the tool itself. The need to scroll horizontally to access widgets, for example, is simply not great. Additionally, a lot of basic UI issues, such as the affordances of the widget categories (both in terms of text size and “I’m-clickable” quality) really could use some work. The good news is that this is probably something that wouldn’t be that hard to fix. Here is quick mockup I created with Balsamiq of one possible idea for a redesign:

My proposed redesign of Balsamiq (click image for larger view)

The main change I am making here: Applying a more standard application structure. Let’s keep the experimentation on the art board, and not force users to figure out the UI of the application itself. Additionally, I think the look and feel of the application UI should be obviously different from user-created sketch widgets – currently, it’s all a bit of a blur.

Actual Drawing/Sketching

Not being able to just draw freeform is almost a show-stopper for me. This just seems so fundamental to the idea of sketching, and becomes particularly critical for a tool like this, in which (as I discussed in my earlier post about prototyping tools) you will inevitably and possibly quite commonly need to add something for which there simply is not a good ready-made widget.

Sharing/Embedding

I wasn’t able to try sharing or embedding the tool, but from my experience using Gliffy with Confluence, if Balsamiq is anything like that, I think that definitely adds value to the tool.

Widget Library

I found the organization of widgets confusing, seeming to always be clicking between the Layout and Containers categories or whatever, hunting for the right widget. I think the ability to toggle a full-screen gallery of widgets might be the way to go. Also, despite being at the top of the page, the widget search feature is not obvious (possibly an affordance issue due to the lack of a search button.)

Paper Prototyping Template Maker?

One great use for this tool would be to create paper prototyping foundations. In other words, one would perhaps produce an application wrapper, and then print multiple copies of that to then physically draw application sketches.

Feature Wishlist

Some things I’d like see in Balsamiq (aside from freeform drawing) is the ability to define my own favorite widgets. Additionally, I’d like to be able to upload widgets I’ve created in other tools and not only add them to my library, but also post them to a community library, in which I would be able to browse widgets created by others. I also think the sketch pad background is cute, but not very practical. Would want to be able to turn it off, or create my own sharable background, such as a browser window shell.

Overall, I think Peldi and the Balsamiq team have done great work. Keep it up!

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’ve got a new article at Boxes and Arrows called Prototyping with XHTML. The article really came about because, time after time, I’ve found myself in conversation with a fellow UXer, and we’ll be discussing design methodologies, and I’ll tell them I’ve relegated wireframes to just being refined sketches, while instead specifying my design with XHTML. And inevitably, they’re curious and want to learn more. Problem is, there isn’t a lot written about this way of working, which is why I decided to write the article. That, however, is not to say that this is some methodology that I conceived of. On the contrary, I’m aware of many many others who work this way.

The first time I heard about designing with XHTML was in 2005 at an IA retreat in Asilomar, where Christina Wodtke bluntly proclaimed that we should “stop doing wireframes.” I was both skeptical and enticed. I had been doing wireframes for years, and was pushing the practice to an extreme with excruciatingly detailed designs defining every last element on the page, and annotating them in tome-sized specifications documents.

Christina later sent me the slides from her presentation, “First Things First: IA and CSS,” which she gave with Nate Koechley at WebVisions 2004, and which described a method for representing information architecture not with the familiar diagrams but instead with some kind of weird DIV tags and CSS classes and what-not.

Looking back, I think I my reaction to their ideas was like someone riding a horse and buggy for the first time being told about an automobile. I just could not fit the idea of using XHTML markup to communicate a design solution into my wireframe-based mental model of the IA practice. But at the same time, I knew that designing with wireframes is fraught with problems, from the lack of a standardized notation understood not just by stakeholders but, most critically, by developers, who have to build the darn thing based on them, to the confusing overlap between wireframes and design comps, to the abundance of information not inherently communicated in a wireframe that therefore needs to be explicitly explained in droves of labor-intensive annotations, that inevitably become out of date. And on and on.

So I tried to fit Christina and Nate’s XHTML-shaped peg into a wireframe-shaped hole, such as trying to get annotation references to appear ‘on top’ of the XHTML, which in hindsight is akin to early designers of the automobile creating steering mechanisms modeled after horse reins. In both cases, it was an attempt at working in a new paradigm with your mind stuck in the old one. But major forces of change in the last several years, in terms of how websites and related technologies are designed and built, served as the undercurrent that washed away old thinking. Most important of these are the migration among software developers from waterfall-oriented methodologies to agile and iterative methodologies, as well as the increasing predominance of web standards and all the best practices associated with it related to XHTML, CSS, and JavaScript as the pro forma method for building websites.

Today, I could not imagine specifying my design with traditional wireframes. Yes, they are still part of the process, but they function as explorations of an idea and not the instructions of what to build, and are discarded once the design has evolved beyond them. When designing the user experience for standards-based websites and applications, I am instead using the same technology developers use to implement the product—XHTML, CSS, and JavaScript—as both a prototyping and specification platform. So, for an introduction into what that all means, check out the B&A article.

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.

I’m really excited to announce a new course I’ll be teaching at Smart Experience: “Prototyping in Practice.” This will be a two-session course, in which we’ll first lay the groundwork by discussing what prototypes are–focusing on web-related prototypes–and why they matter (as in asking the question “What if we skipped the prototyping part of the design process? What is the cost, risk, etc.) and then explore when the best time is to prototype, what parts of a design to prototype, the level of fidelity that will be sufficient to accomplish the prototyping objective and much more. Finally, we’ll get to the meat of the course, which will be a discussion and hands-on workshop, where we’ll explore various prototyping tools and methodologies. This is a great course for anyone who either is fairly new to web design or has been doing it for while but wants to extend their skill set to include prototyping. Read the full course description here and, if you decide to sign up, as a thank you for stopping by my site, feel free to use the discount code FOSE (“Friends of Smart Experience”) for a 10% discount on the class.

Victor sent me this unofficial sneak peak presentation of Adobe Thermo presented at the MAX 2007 conference in Chicago:

Be sure to also check out parts II and III of the video. What’s truly ground-breaking about this new app is how it allows for transforming what were just layers and objects in Photoshop (and possibly other apps – they only used Photoshop in the demo) into actual functioning interface elements on a web page. In other words, rather than being stuck with whatever ui theme that the framework you are using supports, you can just draw the components and then tell Thermo what part of your drawing should have what functionality. In other words, I can turn a text layer in Photoshop into a text field, or two rectangles into a scroll bar. All of this is functioning within Flex, meaning that Photoshop files effectively are being converted into MXML. Rather than requiring developers to recreate all the designer’s efforts, they can now instead allow the designer to bring their work into their framework, and even continue their design work, prototyping behaviors (Thermo has a bunch of cool prototyping features built in, such as easily being able to add sample content) and exploring interactive versions of the formerly static Photoshop files.

In some ways, I am incredibly excited about Thermo, and can’t wait for the public release. But the devil will, as they say, be in the details, and that couldn’t be more true for an application as complex and powerful as this. The demo looks fantastic, but so did a demo of iRise, which I saw years ago, only to discover that the real application fell far short of its promises. Of course, Thermo goes far beyond iRise (after all, iRise is an application simulator, while Thermo in fact is intended to allow for creating real apps), and is many ways a much smarter model, particularly the use of MXML, which allows for much more control and portability.

So, for now, I’m definitely excited about this tool, but only cautiously so.