Chris Bland on Life Before Balsamiq

Chris BlandChris Bland is another Mockups customer we met at the Atlassian Summit last year. He is the CEO of Business Data Quality (BDQ). He was excited to tell us his Balsamiq story, which is a very typical example from our early users.

Here's how Chris describes his workflow before Balsamiq:

I'm old enough to remember DOS, Command line UIs, and even used to write Smalltalk. Things have moved on a lot, not least the ability to create rich, responsive UIs. Products like Delphi made programming Windows UIs almost a pleasure. However, one thing seemed to remain in the dark ages, and that was our ability to create UI mockups.

Instead, there were four main options:

  • Pencil, paper, scan. Easy and natural to create, capture not great, subsequent editing and revision - forget it.
  • Use an inappropriate tool like PowerPoint or Visio. The "when I've got a hammer, everything looks like a nail" approach.
  • Just press ahead into a prototype. "This is fun - I'm building stuff, and the users will surely love what I'm creating. Eventually!"
  • Write a huge functional description, users sign off on it, and UI creation is done downstream by an engineer who is tasked with mind reading what the user wanted - the "exercise for the developer" approach.

(Editor's note: I can vouch for this, as a UX designer who did all of these in the days before Balsamiq.)

One thing seemed to remain in the dark ages... our ability to create UI mockups.

Chris summarizes the drawbacks of the options above:

  • Visio was great for structured, scaled diagrams. PowerPoint was great for creating slides. But I didn't want to architect a building, or write a presentation. For doing rough sketches, using the wrong tools was just time consuming. Basically, you had to know what you wanted to create, before using them. But creating was what I was trying to do.
  • Writing a prototype was hit or miss. If you had a great UI designer who really had a handle on user requirements (and this was assuming that the users knew their requirements), you might get away with this. To go straight to prototype meant bypassing the initial communication phase - the "Is this roughly what we all had in mind?" phase. And creating a prototype usually started to take on its own momentum. "We'll just throw this away", would turn into "Well, I think we could tweak this", and then possibly, "This is a nightmare to maintain - we should have written the product from scratch". Basically, creating a prototype, meant that ownership has been created. We had now started implementation, by accident.
  • The huge functional description and sign-off approach - this can often be found in very large projects. The ones where a huge amount of money and effort is at stake, and where communication is utterly vital, often seem to have the least communication.


Chris uses Balsamiq for his product documentation as well as for wireframing his UI designs.

When Chris discovered Balsamiq Mockups, he said he was "hooked." Our early marketing was mostly word-of-mouth and we're grateful to Chris for helping us spread the word. Here's how he described introducing Balsamiq to a friend:

Friend: "They've given us this huge functional spec document that we are meant to review and sign off"

Chris: "Do you understand what you and your users are actually getting in terms of what they will see?"

Friend: "Erm, no."

Chris: "Otherwise the engineers will just have to interpret what's on the agreed spec, pretty much in an ivory tower and you run the risk of getting a UI that is heavily oriented around the way it is built, but which may be horrible to use".

Friend: "Oh yes, we've got another system like that! I wondered how that had happened. It's just dreadful, but it was too late to change once it was given to us to test"

Chris: "Have they explained that they could create very lightweight sketches, often called wireframes, to help everyone understand the goal in terms you can understand?"

Friend: "I was under the impression that this was very difficult, it would involve building prototypes, and could only happen after sign-off."

Chris: "Hm. Let me show you a product called Balsamiq..."

We love that story, even after hearing many, many like it.

Do you understand what you and your users are actually getting in terms of what they will see?

I followed up with Chris to answer a few more questions about his background and business.

Q&A with Chris Bland

What industry do you work in, and what is your title or job description?

We are an Atlassian Partner, but we have a background in software product development. I’m the CEO.

What kinds of things are you excited about in your industry?

The ability to collaborate, automate and scale complex processes. This applies to areas such as applying the Atlassian product stack plus integrations to the software development domain, or their business processes. This can make companies so much more productive than trying to manage things with emails and spreadsheets.

What suggestions do you have for someone looking to succeed in your role or industry?

Have an open mind. Always be learning, and think about how new techniques can solve existing business problems. Don’t change for change’s sake, but don’t keep using the same techniques just because that is what you are used to.

Don’t change for change’s sake, but don’t keep using the same techniques just because that is what you are used to.

Why and how do you use Balsamiq Mockups?

We use it to quickly sketch out UI prototypes. It is an important part of the collaboration process, and prevents ideas getting “set” too early in the process.

One of Chris's wireframes (above) alongside the implemented version (below).

Balsamiq prevents ideas getting “set” too early in the process.

Although this sounds obvious, we think it is crucial to have the UI understood as part of the spec. When writing a UI spec, you are defining the problem space. When writing code, you are solving the problem defined by the spec. It is a crucial tool in communicating between user, designer and engineer. And if the designer and engineer roles are being performed by the same people, it still helps - they can focus on solving the correct problem at the right stage in the process.

Do you have any feature ideas or suggestions for how we can improve our product(s)?

I’d like to be able to do screen shots from within Mockups, a bit like Evernote or PowerPoint, so I can quickly capture arbitrary things and drop them in when appropriate.


Thank you, Chris!

Do you have a story to share about the awesome things you do with Balsamiq? Send an email to champions@balsamiq.com with your stories or blog posts!


Get the Inside Scoop

We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.

We'll never share your email address or spam you.

Leave a Comment

Your email is never published nor shared.