Balsamiq Mockups

I’ve never been too fond of a development concept that’s alternately called wireframing, prototyping, or mockups … until now. This blog entry digresses from my usual fare. It’s a chatty testimonial for some software that I think is kinda cool, and I think it will be of great use to anyone who develops GUI screens.

Nope, I’ve generally avoided wireframing. I honestly never really knew for sure what it was until recently, and then with the little that I understood I thought people were just wasting their time.

But I kept seeing this word on websites. It’s like the terms AJAX or "social networking". It’s one of those viral concepts that after a while all web developers seemed to understand except me. I felt like I had missed missed another wave of technology. It wouldn’t be the first wave I’ve missed. I didn’t like Perl for years, and by the time I decided to get on the bandwagon it was already virtually dead and replaced by PHP. I still haven’t bought into Ruby, and I’m not alone as some still refer to it as the fad of the moment. Who knows if that was a good or bad call. I think I called it right with Java. While it has had immense popularity since its introduction, I’ve always seen holes in the language and framework. Sun Microsystems has tried hard for years to make it more attractive, add features, and do whatever they can to make Java the "gotta have it" standard for developers, but they keep missing the mark. Well, now that Oracle owns Java we’ll see what happens.

(I guess I’ve alienated about 80% of the people who started to read this article. I’ll get the rest of you soon.  )

You see, that’s the way it is with some of these fads. You can avoid some of them and not feel like you missed anything. You can avoid them for a little while and then decide maybe it’s time to catch up. I did that with .NET, and even though some people peg me for a Microsoft fan I was actually quite late to join the .NET party. And then you can avoid a fad, feel good because you didn’t waste your time with it, and then suddenly find out that maybe you should have been on the bandwagon from the start.

Well, that’s the way I’m feeling about wireframing.

What the heck is a wireframe (he asks in paragaph 7)? In short, rather than doing up a prototype web page using real web development tools, and then showing it to your client/prospect, you can use wireframe software to do the mockup, get opinions, and when you get final confirmation you can use the real tools to do the real site.

That’s not so tough, we’ve all used napkins or the pads of paper left on the doorstep from realtors to spec-out what a web page might look like. Heck, I used to just get clients in a GoToMeeting session, open up the Windows Paint utility, and draw controls with boxes and circle tools. Once I thought I "got" the concept of a wireframe I thought it was silly – everyone does that in one way or another. Why is this all of a sudden something that people even need to discuss – and what’s the deal with software to do the job?

But over the last year or so I started to notice that there were software utilities that did wireframing, associated with GUI development. Adobe has another one of their industrial strength, enterprise-scale packages that does wireframing and I honestly thought to myself "how stupid is that?" (Just lost another 5%, the Adobe fans who were reading.) If you’re going to use a tool for wireframing then you might as well just do prototypes with your development tool. Over the years I’ve used Visual Studio, Dreamweaver, or some other development tool as my prototype tool. If I’m comfortable with that, and I already have it on my desktop, why would I buy another tool, learn how it works (or doesn’t) (and many of us know Adobe developer products are not simple) and then after designing a website there, go back and re-do the whole thing in a "real" tool?

Then Kevin Powick introduced me to Balsamiq Mockup. Here is the transcript from our Skype chat (another one of those fad/phenomenon things that many people haven’t caught onto yet) exactly as I learned about it.

[4/13 1:47 PM] Kevin says: You there T?
[4/13 1:47 PM] Tony says: yup – whazzup bro?
[4/13 1:48 PM] Kevin says: Just a quick one. I don’t know if I mentioned this to you before, but I bought it today. It is awesome..
[4/13 1:48 PM] Tony says: (clicked link) hmmm, interesting
[4/13 1:48 PM] Kevin says: If you do a lot of mock-ups.. and you should. It’s great
[4/13 1:49 PM] Tony says: (quote from the site) "Life’s too short for bad software" …how true…
[4/13 1:49 PM] Tony says: thanks for the reference – Adobe has some major crapware for prototyping – the buzzword these days is "wireframes".
[4/13 1:49 PM] Kevin says: Heh.. ya.. I’ve used a few products and this one is just so fast/easy to work with… It’s an Adobe Air application, so you can even demo it on the web
[4/13 1:49 PM] Tony says: I figure if a web developer knows enough to use wireframe software they can sure do a reasonable mockup.
[4/13 1:50 PM] Kevin says: not a buzzword AFAIK. Wireframe protos been popular a looong time
[4/13 1:50 PM] Tony says: hehe – then it’s just one that has eluded me. 🙂
[4/13 1:50 PM] Kevin says: Not just for webist mock-ups. Lots of widgets for apps.. That’s what I’m using it for
[4/13 1:51 PM] Kevin says: Anyway.. if Mock-ups are something you do, then it’s a treat. I used to use a product called Screen Mock-ups (original name eh?), but this is much better
[4/13 1:52 PM] Tony says: funny that I just code skeletons rather than doing mockups but maybe that should change – haven’t taken the time to look for alternatives.
[4/13 1:53 PM] Kevin says: Not fast enough and I never want to give the impression that the client is beyond concept stage. That’s the problem with using "real" tools to create an early prototype. You can create an unrealisitc expectations for the client. They figure it’s "almost done".
[4/13 1:54 PM] Kevin says: wow.. is my typing crappy today
[4/13 1:54 PM] Tony says: yer absolutely right. playing with balsamiq now – I get it.

OK, so in less than 7 minutes I went from not knowing this thing existed, to actually working with it and "I get it". Since then, a little over a month now, I’ve been using the online demo/trialware of Balsamiq to do mockups for a couple clients, and I’m very glad that I am for a few reasons.  

I think Kevin’s note at 1:53 was right on the mark. When you do a prototype for someone using developer tools, in their mind the product is done, and it either works or it doesn’t. If it doesn’t work to their expectations (and remember this is your demo/prototype we’re talking about, and not a finished product that you intend to put on a site) then all of a sudden your facing criticisms for having done the job wrong, and the job hasn’t even been approved yet! Your task now is not to sell them on the idea, but to convince them that you will get it right the next time even though (in their mind) you screwed up this first time (by not reading their mind). Until you can work out a better spec and get a new demo, the discussion is about your broken software or something not meeting expectations. You’re on the defensive before the project has begun. It’s a bad place to start.

Due to the length of this review I probably just lost another 5% of the reading group, so if you’re in the final 10%, let’s take a closer look at Balsamiq.

The general idea is that all applications have common controls like textboxes, dropdown lists, buttons, radio buttons and check boxes, etc. These days more apps have splitters, breadcrumbs, popup calendars, and "accordion"-style panels. All of these controls are available to drop on a mockup screen in Balsamiq. There are over 60 standard controls, plus there are many controls contributed by users and freely available, representing controls that are familiar to users of specific apps. When you’re creating a prototype for a client, you drop controls on the screen, move stuff around, and then get your client/prospect to look at that.

I’ve started doing collaborative development where the user tells me where things should go, we discuss it a bit, and we create a definition of the screen together. This effort makes the user think about exactly why things will be in specific places. It helps to make the future screens more real for them before a line of code has been written. This should save you a lot of back-end "could you move this over there?" effort.

From a business/social perspective it’s also good to involve the user in the development process – we’ve all heard that but many people just pay lip service to the concept. Ultimately I would want to delegate screen formatting to someone at the client company, so that all they need to do is pass me the finished and approved mockup, and we’ll code to that as the spec. Balsamiq isn’t necessarily a developer tool – treat it like a game that anyone can play, and anyone in the office can quickly learn how to move stuff around on the screen, make notes etc. Your client might pass a spec to ten people by the time it gets back to you. Better to do that before the code is written than for the IT manager to have the only set of client-side eyeballs on the spec, and later have ten people complaining that the finished product doesn’t meet their needs.

Before leaving that point someone might say "but we’re the designers and we shouldn’t push that task to the client" or "they don’t know anything about which controls to use and have no idea about UI design". We can make those decisions on a case by case basis. Someone needs to design screens and if the client wants to save money and keep design internal, they’re welcome to do so, but they should also know that UI design is a skill, and doing it wrong could cost them more than the cost of getting someone to help do it right. For any of these points there can be rebuttals and my intent is to focus on Basamiq as a product rather than on Best Practices for Software Development.

I could provide a lot of details about Balsamiq here but I feel it would be redundant to their own website which has a wealth of information. My goal is to introduce you to a solution – you can get the details from the provider. So rather than putting images and stuff here, I recommend you check out the online video sample. Then try it out for yourself in the online demo.

What’s with the cartoony text? That’s the Comic Sans MS font. On one hand I think it’s a bit unprofessional – we’re more used to Verdana, Arial, Times Roman, Courier… But on the other hand, you’ll never get a prospect thinking that their screen is done when they look at a Balsamiq mockup. That’s important. They need to internalize the concept that this is a spec for future development. And when they sign off on it, that’s what they’re going to get … hopefully with more professional fonts. You can change the default font used, but personally I wouldn’t for most projects. (And I probably just lost another 5% of the reading audience – the Comic Sans MS Font Admiration Society…)


Balsamiq is written in Adobe Flash and therefore requires the Flash plugin for browser usage. Similarly, Adobe Air is used to produce the desktop version. Don’t like plugins? Your loss… (Oops, just lost another 5%.) Seriously, I’ve mentioned plugins a few times in this blog and this is a good example of a truly useful application written with those tools.

If you’re good at math you might realize that I’ve probably alienated 100% of the reading audience by now and that means you’re not really reading this. If you are, then my math is off but that’s OK because we’re talking about software here and not math…

When you drop a control on the screen, XML is being written to declaratively define what the control looks like, where it is, and what features you’ve assigned. A real geek (and I’m getting some ideas as I write this) could design a whole screen in the Balsamiq Mockup Markup Language (BMML) and not even use the UI. But normal human beings don’t need to look at the XML. Then again, if you’re a UI designer, you’re not a normal human being and you’re probably already very familiar with XML markup via XAML, XUL, OpenLaszlo LZX, ASP.NET, or Macromedia Flex Markup Language (curiously named MXML rather than MFML, although now that I think about it I see where that wouldn’t be a good idea). See some of my recent blogs about web development where i explain how those markup languages are similar and different.

Balsamiq Studios

One of the things that has sold me on the software is the company behind it. I really try to avoid companies that don’t have their act together, even if their offering is good. I’ve read a number of the blogs by Giacomo ‘Peldi’ Guilizzoni, Founder and CEO of Balsamiq Studios. This guy has a good head on his shoulders, an excellent attitude, and I think he’s doing a great job to kick off a small company into something much larger. He puts everything online from tax documents that people need to do business with his company, to every contact source possible (IM, Twitter, Skype, Facebook, phone numbers, addresses, etc). And the company uses to get comments and product feedback from people. Why is that a big deal for me? I really appreciate the open business model. We all know where we stand. He even has a very interesting perspective on software piracy – I find it quite refreshing. Too many companies hide public/customer comments, so you never know what’s wrong with the software, what tricks other people are using, what suggestions others have made, or how the software is evolving.

Well, that’s enough raving out of me. I encourage you to check out Balsamiq Mockup, and to look around at what others have said about it. When you’re tired of the limited but highly useful free version on the website, buy it for yourself for only $79. If you don’t buy it, then just tell others about it, like Kevin told me and like I’m telling you. I think this is good software and the company deserves to succeed. With all of the rotten software from lousy companies out there, I think you’d agree that the good ones need every break they can get.

1 thought on “Balsamiq Mockups

    • Tony, You had me at "alienated"; I couldn’t resist further reading in anticipation of the next insult. 😉 I agree with Kevin’s assessment.  To the customer, the user interface is the application and showing them a working prototype will often give them the false impression that the project is much further along than it really is. There are some exceptions and what-ifs that can be applied (i.e. the customer is adamant about having a working prototype), but generally this is the case.

      Sometimes customers don’t want to see a mockup because they don’t perceive it as real work or something they don’t want to pay for. They want you to show them something they can actually use. Look at the customer’s face when you show them a mockup and the difference between that and a prototype they can play with. Sometimes it doesn’t matter how well you explain it or how right you are; they know they are the customer and will demand what they want. Sometimes a mockup is good and has real value, but other times, it can be perceived as a theoretical idea and won’t be applicable.


Leave a Reply