Review: Balsamiq Mockups

In an unrelated post, Jamis Charles asked, “I know this is totally unrelated, but you mentioned some time ago you started using Balsamiq Mockups. I’d like to pitch it to my UI Team. How has it been working for you? How do you incorporate it into your workflow? Has it increased productivity? A post about this would be greatly appreciated. Thanks.”

I’ll let others speak to their own experience, but here’s a quick post on how it worked for me. I was looking for something easy that would help my team focus less on pixels and colors during the planning stage, and just focus on concepts and framework. Balsamiq worked admirably for that purpose. In fact, within weeks of using Balsamiq for our weekly high-level design meetings, team members were themselves articulating the reason to use Balsamiq: “We don’t get bogged down in the details anymore!”

The workflow was something like this:

1. I would review high level requirements, talk with the customer and mock something up quickly in Balsamiq, with sketchy notes in the margins. As promised, the tool is drop-dead simple for most things it supports. Don’t expect a freeform drawing tool, but for dragging and dropping basic UI elements, it’s very easy.
2. Team would meet to discuss.
3. I would take notes directly in Balsamiq, sometimes updating the mockup, but often just leaving a note in the margins for later. Because of the low fidelity of the prototype, the team was able to get past nitpicking the details and focus on the functional requirements and workflow.
4. Once we moved out of planning into iterative development, I would refer to the mockups and the notes recorded there to create higher fidelity prototypes, using Fireworks images or HTML prototypes, depending on the need. I tried to get a cycle or two ahead of the dev team, and was generally successful.
5. As the high fidelity design progressed, we referenced the low fidelity mockups less and less. By the last cycle or two, we were hardly using them at all anymore. I probably haven’t opened the tool in 3 months.

So in terms of productivity, our planning discussions were more productive because we were not bogged down at the pixel level. But in terms of turning the Balsamiq Mockups into production code—that was not really our intent, nor does the tool really support that.

Anybody else have a perspective to share on this or other rapid prototyping tools?

posted by ted on Thursday, Jul 02, 2009

Which is the prototype?

I got a funny request today, one that illustrates how cool our software development process is. The Lead QA on my project (let’s call him Blackbeard) asked me to put a watermark on my prototypes so he can tell at a glance that he’s looking at my prototype and not the actual working software. With multiple tabs open, it’s hard to tell which is which. And that is precisely the point! So I’m adding a watermark.

We’ve also been asked recently to put real data into the prototype to aid in the user feedback loop. My fear is without the tell-tale fake data we put in, our users might run into the same problem!

Our process we’ve developed here at the Church has the Interaction Designer working out all aspects of the user interface and feature set in a high fidelity (XHTML/CSS) prototype before the developers ever see it. This way, stakeholders and users can see what they’re actually going to get, not some bloated bullet list of hard-to-understand functions and use cases.

We then sit and work closely with the developers and QA to make sure what we’ve promised visually is being fulfilled in the working software.

The downside, it seems, is when the actual app is too close to the prototype and everyone gets confused.

posted by jason on Monday, Jan 22, 2007