Free Course on Wireframing with Balsamiq Mockups on Udemy

We now offer a free course on Udemy called Wireframing with Balsamiq Mockups. It's designed to cover the basics of what Balsamiq Mockups is and how to get started with it. It will walk you through the primary features and show you how to create a simple project.

The course contains 8 video lectures that build on each other to get you feeling comfortable and confident with Balsamiq Mockups in less than one hour. It's designed for anyone who is just getting started with Balsamiq or wants to learn how to use it more effectively.

All you need for the course is the free 30-day trial of our desktop version (or a registered version if you already have it).

Head on over to Udemy and start learning now. :)

— Leon Our New Static Documentation Site, Powered by Hugo

    Last month we released a brand new web site for our documentation - We also updated our support site with a new design and layout. This post describes what we did and why we did it.

    docs.balsamiq.comThe new


    Early last year we wrote about how we updated our support website for a better user experience. This included customizing our support center template to make it easier to browse and navigate, and putting more focus on tutorials and step-by-step guides. We also put in place some systems for writing documentation to streamline the process internally.

    Since then a few events led us to want to improve our support and documentation site even more.

    1. Moving our site from WordPress to a static site
    2. I started using Markdown for blog posts and documentation (and then converting it to HTML for publishing)
    3. Increasing frustration with our existing knowledge base system, which made changes live as soon as they were saved and had a clunky editing experience
    4. Search wasn't very good, making it hard for people to find what they were looking for.

    Each of these factors alone probably wouldn't have led us to create a new support site, but combined they provided enough impetus to justify the work to move our content over to a new system.

    Making a Plan

    Before diving in, we made a list of requirements for our as-yet-undecided solution. They included:

    • Versioning so that we can review history and work on updates before publishing them
    • Ability to automatically generate a list of articles in a given category (for creating a table of contents)
    • Customizable templates for different page types (article, TOC, main index, etc.)
    • Support for Markdown
    • Support for in-page anchors (automatically generated would be nice!)
    • Next and previous buttons/links to articles within a category

    A few of us researched options and we discussed the merits of each. Around that time a few other events led us converge on a plan.

    Mike blogged about converting his personal site to Hugo

    These three things gave us the confidence to start a project to convert our existing documentation to a static site built on Hugo.

    Designing the Experience

    We started a myBalsamiq project for the site and created some wireframes for the layout, navigation, and content.

    Our primary design goals were to make it easy to navigate and to remove as much unnecessary stuff as possible.

    An early layout. We eventually decided to combine the sub-section navigation and in-page navigation areas.

    After some discussion, we decided to separate our documentation articles from our support articles. This would allow us to have one dedicated site for our user guides, which are there to help our users learn the product. Our support site, on the other hand, is where people can go when they need help or have a specific question.

    This also allowed us to make the transition faster, since only the documentation site would be built on Hugo.

    These designs show our concept right before implementation.

    Along the way, Mike took an opportunity to work on updating our existing support site design.

    The updated

    Implementation and Go-Live

    Because several tasks had to be coordinated, Mike, Peldi, and I blocked off two days last month for the "launch-a-palooza" where we updated articles on the support site, switched to the new template, added the redirects, and a bunch of other behind-the-scenes stuff.

    For the finishing touch, Peldi implemented a new search engine, Swiftype, across all our sites (not just our documentation and support sites). This was awesome, since it helped bridge the gap between our two separate help sites.

    Finally, we decided to open source our documentation site code.

    We are now working on converting our existing support site to Hugo, which, thanks to the work we've already done, shouldn't be too much work.


    As the primary documentation writer, I was the person here who wanted this project the most and the one who has benefitted most from it. But I was also the most resistant, because it seemed like a lot of work, and I was concerned about all the old links, worried that many customers would be seeing our Sad Robot instead of getting the help they needed.

    But Peldi and Mike's experience with large web projects made it happen and they knew how to handle all the details and loose ends to make sure the transition was by-and-large incredibly smooth. On top of that, Mike's excellent design work and Peldi's implementation of our new search capabilities made the end product better than I could have imagined.

    I'm not sure what the rest of our company learned from this, but I learned that having the right team on a project can produce great results. I don't think I'll be so intimidated the next time I'm faced with an idea for a large project.

    I think it's also important to note that, while much of the work on this project involved using new technologies, we did a lot of work up front to define the problem and write down what we expected from our solution. This project wasn't just a show of our technical capabilities, but our effort to improve our products and processes by making documentation easier for our writers and better for our customers.

    Thoughts? Feedback? Feel free to share in the comments!

    - Leon

      Free Course on Rapid Wireframing with Balsamiq Mockups on Skillshare

      We published a free course for Balsamiq users on Skillshare. The course, Rapid Wireframing: Finding the Right Product Design, is designed for those new to Balsamiq Mockups, but also features some demonstration of new features like Quick Draw and Alternates. If you're a veteran user, you may be interested in checking that out, and updating to the latest version to take advantage of these useful new ways of working on projects.

      Here's a trailer to give you an idea of what to expect.

      You'll learn how to successfully create wireframes for early stage product design as I show how to use Balsamiq Mockups to design interfaces with product teams, using the example requirements from UX Apprentice.

      In the 51 minute course, you'll see how concept selection can be tackled with low-fidelity wireframes, learn to create rough sketches to explore ideas, and then transform them into interaction design solutions that can be refined quickly, and polished for presentation.

      The class is perfect for product managers, developers, and those new to designing with wireframes. No prior knowledge or experience with interface design is required. By the end, you'll be able to present wireframes for a finished product idea and demonstrate a clickable prototype.

      Start taking the free course at Skillshare now!

        Tips for Presenting Your Wireframes

        Now that they're done, what do you do with them?

        I recently wrote an article for the Treehouse Blog called "3 Steps to Better UI Wireframes" that provides some wireframing tricks that I've learned in my career as a UX designer.

        The three steps I outlined were:

        1. Get into the Wireframing Mindset
        2. Take Your Time
        3. Build a Bridge from MVP to 3.0 (or the Other Way Around)

        In this post I'll be following up on those steps by describing some techniques for being prepared when the time comes to present your wireframes to clients and stakeholders.

        The Other Customer

        As a designer (or temporary wearer of a designer hat), you need to jump into the mind and world of the end user. The user is the ultimate customer of your wireframes, and your job as the designer is to create something that solves their problem in a way that makes sense to them. But the end user is not your only customer. In the vast majority of cases (unless you are a one person operation) your designs will need approval from someone else (possibly many other people) to proceed. It could be the developer who will be writing the code, the Product Manager who owns the project, or the clients who may (or may not) be buying your product.

        ST042: Figure 15.13

        Image credit: "Storytelling for User Experience", ©Rosenfeld Media

        In one form or another, you need to get "buy-in" on your designs. Many young designers often incorrectly assume that getting the go-ahead on their work is achieved by creating the best design possible. Great design should be obvious to everyone, right?

        Not so fast.

        Tom Greever, author of the book "Articulating Design Decisions", states:

        Your ability to be thoughtful about a problem and articulate any solution is more important than your ability to design the perfect solution every time.
        - Tom Greever

        My experience backs this up. Read on for some tips for presenting effectively once your wireframes are done.

        1. Be Open to Changes

        After working hard on an awesome set of wireframes, the last thing you want is a critique of them. But you have to learn to be ready for your "presentation" to be more like a conversation. Your design might be very good, but accepting input from others can make it even better. Being in the right mindset will make it feel less like criticism and more like consensus-building.

        If you go in being open to suggestions you'll come out with a better final product.

        Here are a few ways that you can lead the inevitable feedback you'll receive.

        Admit your uncertainty - Just like with any presentation, being humble helps get the audience on your side. You may be presenting to subject matter experts and if you come off seeming to know absolutely everything you can sound smug or cocky. Talking about some areas of your design that you're unsure about or, better yet, inviting suggestions from the audience, can build a collaborative atmosphere. Incorporating another person's idea will give them an investment in the design and turn them into an advocate for it.

        Have alternates prepared - If you expect that people might not like some part of your design, have some alternates ready to show. It's better to show that you've considered other ideas than to let people think that you threw something together casually. If you've taken your time, then you should have some alternate or abandoned ideas to show. Don't be afraid to show something incomplete (including paths you gave up on). Describing why you chose your primary design over an alternate will help justify it.

        Showing this evolution — what designs died and which ones survived — helps substantiate the final result. It shows you have explored options, not just executed on the first whim.
        - Todd Moy

        Try making some changes live - If you've got a really lively crowd, stop the presentation and have a mini design session. Open up Balsamiq and make some edits to your wireframes directly!

        2. Provide Context via a Timeline

        In the vast majority of the cases, there is something that led up to what you're presenting. A previous version, an existing tool, or prior work on the same project. Start there before showing your designs. Give a "recap" of the project to date.

        Show the audience how what you're about to present fits into the context of the project as an evolution toward a final goal (even if it's part of a much larger goal).

        This can include fast-forwarding to what you'll be working on next. If you've taken the approach of building a bridge to or from your "3.0" vision, then you can even show a glimpse into the future to help show how your design brings the product closer to the end goal.

        Doing this will show how what you've designed fits with the previous work, or is an improvement over it, and how it connects to the next steps or lays the foundation for them. Show your design as a stepping stone on the path that everyone wants to be on.

        By doing this you are incorporating a few established UX techniques together:

        1. Telling a story
        2. Answering the question: "Why are we doing this?" - what the PM or CEO cares about
        3. Clarifying that you understand the interests of everyone involved.

        3. Be Ready to Talk About Your Design Choices

        Finally, be prepared for some push-back on your work. Sometimes it's because you missed something, that there was something you hadn't thought about (in which case you can ask for help from the audience, as described above), but resistance also arises because good UX challenges assumptions. The best design is frequently not exactly what the customer asked for. If you've done your job and studied the problems that customers have, rather than only the features they ask for, you may be proposing something unexpected. In any case, be ready to defend, or at least discuss, the design decisions you made.

        Returning to Tom Greever's work on articulating design decisions, he suggests a list of common explanations, or justifications, for why design decisions are made. They are:

        • Facilitates a primary use case
        • Follows a common design pattern
        • Meets a particular goal
        • Data supports it
        • Complies with a standard
        • Limited by technology
        • Draws the user’s attention
        • Creates a flow for the user
        • Establishes branding

        I have found the first two in particular - "facilitates a primary use case" and "follows a common design pattern" - to be especially compelling.

        You first need to get in the habit of justifying design decisions to yourself. Returning to the primary use cases (you do have these, right?) and following established UI patterns are excellent guiding principles. If you've followed these during the design phase, you should definitely mention them during the presentation. Depending on the project, product, or audience, the other explanations may be even more effective.


        If you've done your design work correctly you've taken the time to step into the shoes of the end user. Presenting your wireframes is the time to step into the shoes of your intermediate customers, your presentation audience. You may care about how it looks and how it works, but your audience may care more about how long it will take to build, whether it can be built using their tools and frameworks, or whether it can be marketed successfully.

        So, once your wireframes are done, take some time to review the assumptions you've made along the way, go back to your notes from meetings before you started designing, try to anticipate how your audience might respond, and review the tips above.

        Good luck!

          UX Apprentice - now in multiple languages!

          Part of our mission at Balsamiq is to spread the knowledge of User Experience. Recently we have been tweeting more about it (both at our @balsamiq and @uxapprentice accounts), sharing useful resources via our social channels, writing blog posts and interviewing Balsamiq Champions to inspire you with their awesome work.

          Today we're adding another piece to the puzzle.

          UX Apprentice

          In 2013, we worked on a project with Theresa Neil. She has a depth of teaching experience as an author and as a consultant who educates companies about UX Design. Together we developed a learning resource to help people who want to begin a learning path in User Experience.

          This led to UX Apprentice, a web site that covers some of the basics of the practice, teaches you the basics with an easy process to follow, and provides links for digging deeper and perfecting the craft.


          Now in 3 languages!

          Making UX Apprentice available in multiple languages is a natural next step to help people all over the world take advantage of it. We even heard that the site is being used in schools to teach the basics UX, we want to make sure that all kids around the world can understand it fully!

          We have translated UX Apprentice into Portuguese - with the help of Thiago Tomasi - and Italian - with the help of my degree in Italian Linguistics ;).

          Click on the world icon at and you'll find 3 languages under the World icon: English, Italiano, and Português.

          UX_Apprentice Menu

          German, Spanish and Persian are already on their way!

          We need your help!

          We are looking for volunteers to translate the UX Apprentice in as many languages as possible.

          If you want to be part of this UX educational project, just follow these simple instructions.

          It's not a huge amount of effort, and you'll truly be making a difference in helping rid the world of bad software. You'll probably learn a thing or two in the process, and will forever be enshrined on the UX Apprentice Credits page. :)

          We're looking forward to working with you!

            Creating Polished Wireframes

            You land on one of those "12 examples of beautiful interface design" articles and admire the screens of polished wireframes. In some photos you see monitors shot at an angle with screens askew, receding into the distance, and a slight vignette burning away the edges. Perhaps you think to yourself, "Maybe I should make my UI design look like that?"

            It's easy to get seduced by these creatively presented shots of user interface deliverables. If making clean wireframes does cross your mind, we think you can do so successfully provided that you don't put aesthetics before the goals and purpose of wireframing. There are valid reasons for not using sketchy wireframes. Sometimes low-fi aesthetics gets in the way, whether its due to the baggage of hand-drawn fonts or confusion over sketchy lines. That's why we made the wireframe skin, and its minimalist aesthetic is right for these occasions.

            We advise caution. I know, I may be preaching to the choir, but humor me. It bears repeating because people new to wireframes may not know this.

            Wireframing is not meant to be doing visual design, and this is why people make their wireframes as devoid of designed elements as possible.

            Overly "designed" wireframes may ultimately lead to having to provide disclaimers as you deliver them. So get comfortable with this phrase: "Disclaimer: This is a wireframe and is not meant to convey visual design." You may even put that in your wireframes. We've seen that done plenty of times.

            Stepping off the soapbox. Let's get started. We'll be working with Balsamiq Mockups Version 3.


            Just because you're working on wireframes and not visual design, doesn't mean you have to throw your design sensibilities out the window. If you're already steeped in design principles, it'd be hard to make a wireframe without that knowledge influencing where and how you place elements on the canvas.

            Let's start with a few examples of what you might do with wireframes and basic diagrams.

            Desktop App Wireframe

            Mobile App Storyboard

            Journey Map Diagram

            You can download all of these examples in this Project file.

            These examples eschew sketchiness and the hand drawn look. They're mostly grayscale with an accent color. There's obviously a little bit of alignment, arrangement, hierarchy, and repetition there.

            The features in Balsamiq Mockups for non-sketchy aesthetics are easily accessible once you know what to look for. Let's dig into how to create wireframes like this.

            Basic Tips

            The Wireframe Skin and Font

            We start by switching to the Wireframe skin. To do this, select the Project Information panel from the menu, "View > Project Information" or by pressing CTRL+, on Windows or CMD+, on the Mac.

            At the bottom of the panel, select Wireframe Skin and choose a different font. A solid sans-serif font like Helvetica works well on the Mac, for instance.

            Think Minimalist

            Flat design is a nice trend for people who do wireframes because our work has traditionally been devoid of surface decoration. If we look closer at how that first wireframe is created above, we see how the shape control and some subtle use of color can go a long way in organizing elements and suggesting hierarchy.

            Here are some design principles and techniques that help when doing minimalist wireframes.

            Favor Minimalism
            Keep colors at a minimum. Consider using flat areas of color rather than boxing everything and putting noisy borders adjacent to each other. Stick to a monochromatic palette of mostly white, black and grays with an accent color.

            Use Contrast Wisely
            Use contrasting font sizes to denote hierarchy. When elements are distracting, consider reducing contrast in visual elements to reduce their importance. Elements like separators, HRs and border boxes are good examples that sometimes draw attention away from more important parts.

            Use Proximity and Alignment for Visual Organization
            You may not need to box every element and add a strong HR between everything. As above, use contrasting font sizes or color. Put like things close together and add white space to separate groups. As a general rule, look to align almost everything with something else in the canvas.

            Employ Functional White Space
            Again this goes with the previous technique. White space helps to separate, to help direct the eye, to suggest the order of scanning and reading the page, and to help make text legible. The eyes like to have space to rest as they move between blobs of objects.

            To get a little meta, I made a wireframe of our wireframing tool in order to show you these tips. (Hopefully that recursion doesn't make your head explode.)

            The Shape Control

            The most common control you'll use for simply blocking out areas with solid grays will be the Rectangle. But also consider the Shape control as one of your tools for polished wireframes.

            The Shape control is a Swiss Army knife of an object. It was originally meant for quick and dirty flow diagramming, but in reality it's more often put to use for general-purposes. We'll look at some examples, but first let's discuss how shapes can be useful.

            Consider how drawings are made to understand how to use the Shape Control. This fun video shows how manga illustrator Mark Crilley uses the basic shapes of circles, triangles, arcs and straight lines to build up the anatomy of a face.

            The good news is that in Mockups you don't have to know how to draw a circle. You can, however, layer shapes in a similar way to make other objects. Making design elements with the shape control is something that many experienced Balsamiq users do when they want to create an object that doesn't exist, or make a control that looks different from what we provide in the UI Library.

            Let's look at an example created by Balsamiq user Georges Raad. Georges created a great symbol library using the Shape control extensively to make some interesting elements like ribbons. Let's break down his controls to see how he made them.

            The basic idea is to look at the overall form of a thing, then try to break it down into simpler geometric shapes. This is what Mark Crilley demonstrates above when he draws a face. You can do lots of interesting things with just the Shape control. Here are just a few examples of the kind of thing we see people doing using the simple technique of layering shapes that we show above.

            [Common Controls by Georges Raad; Doughnut Chart by Henning; Apple Watch by Ben Norris, Map Controls by Michael Gaigg; Margarita Recipe by Jim; Bootstrap, TR808, TV Remote, and Moockups Cow by me]

            You can see more useful examples of what people have built by getting creative with shapes at Mockups to Go.

            Must You?

            Most people who use Balsamiq don't have to create polished wireframes. Low fidelity keeps the conversation centered on figuring out the problem and communicating the functional solution.

            A wireframes vs. high-fidelity prototype vs. visual design debate is not what we're after here. We're interested in giving suggestions for making clean, minimalist wireframes if you must, whether it be for client presentation or other reasons. I admit that we occasionally do this at Balsamiq when we're working on an existing feature, or if I'm going to be doing visual design work using the design language we're already using in our products.

            As you make polished wireframes, the slope becomes slippery as visual design decisions creep in. Be sure to stick to the same rules you've always known for wireframing with Balsamiq.

            • Focus on Function over Form
              Focus on communicating functionality; wireframes are not for visual design.
            • Illustrate Flow
              A minimalist approach does not mean that you should drop elements that communicate your ideas. Arrows and annotation are great ways to indicate flow, and you should still use them.
            • Don't Neglect Content
              Lorem ipsum only gets you so far. In Sketchy or Wireframe style, you may want to make it reflect real content when you can. It will help to know how your rules will work with real content.
            • Use Graphic Design Principles
              This is a broad suggestion, but it's more important when you're not doing the lowest fidelity work. The Sketchy skin, by design, is meant to be forgiving when it comes to details like alignment and precision. When you start using the finer shapes and lines of the Wireframe skin, hastiness in laying things out may come across as being sloppy and be a distraction in your wireframe. Even though you aren't doing visual design, design principles always help communicate ideas. Contrast, alignment, repetition, etc. are tools for creating hierarchy, organization, and flow in your interface. If you're new to design principles, a book like Robin Williams' very short Non Designers Design Book is a great primer.

            A last reminder is not to let aesthetics get in the way of rapid idea generation. If it does, maybe you should be sticking to the Sketch skin. For the majority of our customers and for us, it is still a tried and true way of focusing on what's important.

            There's no single "right way" to wireframe. What you should deliver depends on your circumstances. In the end, ask yourself, "Does this help or hurt me in trying to explore, find, and communicate the problem and solution I'm presented with?" If it helps, use it, but do it carefully. Hopefully this gives you another way to go out and make something awesome.

              How We Got Here: The Road to Balsamiq Mockups 3

              The release of Balsamiq Mockups 3 was the biggest release in our history since the original product launch in 2008.

              For this release we took a leap of faith and went nearly an entire year without releasing any real product updates (in comparison we released about once a month in 2013). At our annual retreat last year after not releasing any feature updates in nearly six months Peldi had to reassure us that we were still doing the right thing and to stay the course.

              And fortunately people were still buying our product.

              We also made up for the lack of Mockups for Desktop updates with big improvements to Mockups for Google Drive (yay, Sax!), and lots of updates to myBalsamiq and our website, documentation, and blogs.

              This post is all about how we got to Balsamiq Mockups 3. It was a windy, bumpy road, full of changes in direction, fits and starts, delays, and uncertainty about the final product. (So, in other words, a pretty typical software development project.) But when we neared the end it all came together rather beautifully in a way that validated our organic and intuition (rather than market)-driven approach.

              2011-2013: Mockups “Pro”

              Long before any planning or design started we referred to the next generation of our product internally as “Mockups Pro.” This was convenient because we all agreed that our next major version would be Pro, even though we had different ideas about what “Pro” actually meant. Pro was either an abbreviation for Projects (bundling multiple files and assets into a single project file) or Professional (a separate, more feature-rich version of our product for heavy users) depending on who you talked to.

              In late 2013 Peldi decided Balsamiq Mockups version 2 was stable and feature-rich enough to start something new.

              Mike had already been working on a UI overhaul as a side project and kicked things off with a comp to give us some inspiration.

              The “Pro” idea and Mike’s vision of improving the appearance and standardizing the interaction provided the fertile ground for us to start our next adventure.

              We knew that the next version was not just about adding features or a fresh coat of paint.

              But we knew that the next version was not just about adding features or a fresh coat of paint. So we began with some important questions that kept us focused throughout the project.

              From a wiki page created in 2013:

              1. How we can evolve it [Mockups] without breaking from what’s become “the ethos of Mockups?” There is a definite character we want to hold on to, while maturing it. People want that.
              2. What things should not change on the surface?
              3. What things should not change about the experience?
              4. What things are so effective that they create “Flow” when using the app?
              5. What are the things that contribute to a sense of effortless and ease (and effortless effort), as if “the wireframes just make themselves?”

              These questions and some heavy discussions lead us to a set of design principles and the following guidelines for our next project:

              1. Stick to our basic identity (that had made Mockups successful in the first place)
              2. Make it easier to use (especially by reducing friction around pain points)
              3. Introduce professional and power-user features without overwhelming the UI

              And, with that, we moved on to…

              2013-2014: Mockups 2.5

              We knew that before we got any further we had to settle the “Pro” debate once and for all. Should we create two separate versions of our product, one for occasional users and another with more bells and whistles for “professional” users?

              We started out thinking that we would. For a long time we maintained a separate feature tracking project for only “Pro” features. It contained every “wouldn’t it be cool if…” big idea that customers and employees had suggested over the years.

              But something was holding us back. I think it was more a gut feeling than anything else, largely coming from Peldi and Mike. On a wiki page called “Future of Mockups User Experience” Mike summarized Peldi’s concerns as follows:

              Peldi had a simple vision for Standard [the non-Pro version] that he was excited about. He isn’t excited about a tool that essentially comes close in appearance and function to graphic design tools like Photoshop or prototyping tools like Axure.

              Clearly a more powerful tool could be both useful and profitable, but was it something we were excited about building? Fortunately, our decision to remain small and independent allowed us to ask this question rather than just thinking about what would bring in the most money.

              Then there was this action item further down the page:

              Go back from the start and ask “why did we think of doing a Pro version in the first place? What are the things that just don’t belong in Standard? What problem are we trying to solve with Pro?

              This question of “what problem are we trying to solve?” has frequently shown us the way in times of indecision. And this time it reminded us that Peldi’s original vision hadn’t really changed - to help rid the world of bad software by allowing anyone to quickly and easily visualize their product ideas.

              This question of “what problem are we trying to solve?” has frequently shown us the way in times of indecision.

              So we decided to channel our efforts into building an update to Balsamiq Mockups that retained the current core functionality and ease but alleviated pain points and cruft that had accumulated as the product had grown.

              The Pro label disappeared and the project was dubbed “Mockups 2.5” (the current version was 2.2) since it felt like a big, but not HUGE (e.g., full of new power-user features) update.

              Mike created some quick comps that didn’t look radically different from the existing version at the time, Mockups 2.2.

              Our focus narrowed to a few specific targets addressing our customer’s biggest frustrations:

              • Support for bundled project files instead of separate files for each mockup
              • Improve the usability of Symbols
              • Redesign the UI layout for a better editing experience (including figuring out what to do with the floating “property inspector” window/widget/thingy that bugged everyone so much)

              We made a list of additional features that we'd then work on in "follow up releases."

              After many rounds of iteration we started building it and had a working build ready in a relatively short time.

              Here’s an early demo from a test build.

              Mockups 2.5 was nearly ready.

              But were we?

              2014: "Panels" + "BMPR" = "B3"

              Indecision returned as we reviewed our concepts and requirements. What should this release include? We discovered that there were so many things that we were excited about building into the product. Auto-save? Yes! Project notes? Yes! Preferences dialog? Still no. JSON instead of XML? Yes! Default font settings? Yes! Trash? You get the picture...

              It was starting to sound like a pretty big project. Too big for a “minor” (a.k.a. “dot”) update…?

              We left that question alone and went back to something more certain. We knew that we wanted the UI layout to have the mockups on the left, the canvas in the center, and the UI Library and Properties on the right. So we just started calling what we were working on Panels because of the UI “panels” on the left and right.

              Our high-fidelity "vision" comps gave way to detailed high- and low-level wireframes describing interactions, flows, and layout as we fleshed out more details.

              Peldi created a video walkthrough of some of his mockups for the Panels UI.

              Notice how effective a simple click-through wireframe deck can be when accompanied by someone walking you through it? This is an example of the design workflow we promote. We generally don't see the need to create high-fidelity, fully interactive prototypes to convey our ideas and this project was no exception.

              We generally don't see the need to create high-fidelity, fully interactive prototypes to convey our ideas and this project was no exception.

              Peldi, Andrea and Michele were also deep into cleaning up the code at this point, looking at everything we had written in the last 7 years. They consolidated, removed and beautified code until it was actually readable and much more efficient. The clean slate gave us the energy to think more ambitiously about both the back end and front end.

              This included a rewrite of our file format to accommodate the exciting new things we wanted to add. Marco and Paolo were borrowed from other projects to help. This spawned architecture diagrams, flow charts, and developer mini-retreats. Meanwhile, the UX team was discussing the toolbars, menus, icons, etc...

              Finally, near the end of 2014 we started playing with test builds and trying it out internally. We called it "B3" (for Balsamiq 3). We'd talked about dropping "Mockups" from the product name for a while, since nearly all of our customers just called it "Balsamiq." Plus, what it creates are more accurately called wireframes than mockups. But it turned out to be a pain to change the name for a variety of reasons, so we called it Balsamiq Mockups 3. Although now we were more relaxed about just calling it Balsamiq in conversation. ;-)

              Late 2014: Ready for Feedback

              We all felt that we had built something that was both more powerful and more elegant than the current version of Mockups. But we had no clue if our customers would feel the same way. It wasn't only a question of would they like it, but would they like it enough to switch, which would include learning some new things and, not insignificantly, converting their old files by importing them to the new format.

              As we had done in the past we reached out to some of our long-time champions and friends for a closed beta test. We also conducted a formal usability test with help from Mike Heraghty at User Journeys. This uncovered a lot of technical and usability bugs and gave us some great qualitative feedback, including what to expect from people’s first impressions.

              After a few more rounds of fixes and tweaks we felt like it was ready for a bigger test. On February 2nd, 2015 we announced the public beta and opened up our new community forums to talk about it.

              While it was hard to take some of the tough feedback, the overall feeling of connecting and communicating directly with customers was energizing. For the old-timers at Balsamiq it took us back to the early days in the GetSatisfaction forums around version 1.

              And the public beta lead to some great improvements in a short amount of time.

              For example, the UI Library and Properties panel sharing the same space that we thought was so clever? It turned out that our customers didn’t agree. So we moved the UI Library back to the top.

              Other notable additions during the public beta were Font Awesome icons and the Project Information panel, which included highly-requested settings for changing the default font and selection color.

              Releasing without beta testing first would have been a disaster.

              We are so grateful to all of our beta testers for their time and patience. Releasing without beta testing first would have been a disaster and we feel so fortunate to have customers who wanted to help us make our product better.


              March 10th, 2015: Release day! There were some hiccups, as expected, but it generally went very smoothly. And we had all-hands on deck to respond to issues that showed up upon releasing to a broader group of users. Two weeks later we released an update addressing most of them, followed by three more updates over the next few weeks.

              Less than two months after the official release, we don’t know whether Balsamiq Mockups 3 will be a success for us. We know that we enjoy using it ourselves and that many of our customers do too. But we are hopeful because we followed a process that has worked for us in the past: a mix of passion, focus and openness that feels intuitively right to us.

              If I had to distill from this entire process a few lessons we’ve learned from building this and other products it would be these:

              1. Build something you’re excited about
              2. Define the problem you’re trying to solve early on
              3. Involve your customers in a meaningful way at some point in the process

              We’ve come a long way since 2.0. Thanks SO MUCH to all of our loyal (and new!) customers. We want Balsamiq Mockups to be a product that you love to use, so please let us know what we can do to make it even better!

              - Leon for the Balsamiq Team

                Mockups To Go, Ready To Use: Captcha, Password Strength, Calendar

                One of the most popular things about our little tool is how quickly you can create meaningful wireframes with it.

                But there are ways to go even faster with Mockups. Symbols, for example. Symbols let you create reusable common elements across different mockups. Useful, right?

                Another way to speed up the process of creating your wireframes is to browse mockups, symbols and UI controls from our community on Mockups To Go. They are free and ready for you! You can contribute, too. :) Find more information here.

                If you are looking for some UI Controls that aren't included in the standard set of Mockups controls, here are some symbols that could save you time.


                ...who doesn't need a Captcha??

                Form Captcha inspired by Google Keyword Tool. Contributed by Dima Semensky.
                Download Image and BMML here

                Password Strength

                No need to recreate these ever again!

                Password strength indicator controls. Contributed by Alain.
                Password Strength
                Download Image and BMML here


                A calendar with a monthly view, ready to use in a sidebar or wherever you need it to be shown.

                Contributed by Piet.
                Download Image and BMML here

                If you haven't used Mockups To Go before, read these instructions first. Then find the controls above and more on Mockups To Go!

                  The first wireframes are "version 3"

                  Over time, I have learned to consider the first wireframes of any new idea to be "version 3", meaning that, because of how our brain works, we usually tend to put way too many details in them.

                  So, once the wireframes are done, I scale them back once (version 2), and then do it again, to get to what should be released in version 1.

                  I wrote about this little trick as part of a Reddit "Ask Me Anything" session I did last year, and forgot all about it...until I received a CRAZY email a few days ago.

                  Here it is in all its glory:

                  From: Chase Reeves <>
                  Date: Tue, Dec 16, 2014 at 5:42 PM
                  Subject: You inspired this quick post (+ a few gifs)
                  There was a bit in your Reddit AMA where I was, all, like this:
                  Cuz, before that bit my ideas were, like, this:
                  I couldn't nail the MVP, just wasn't capable:
                  Then you were, all, like this:
                  And now i'm, all, this and this:
                  So I wrote up this post.
                  Been sitting on this one since all the way back to your reddit AMA.
                  Big fan, fellow speaker and bootstrapper.
                  Cheers, Peldi! You're a magic man.
                  Chase Reeves

                  Chase, you made my day. :)

                  The post Chase wrote is really interesting, it elaborates on the Version 3 idea quite nicely. Check it out, and check out his startup Fizzle, too!


                    Using Balsamiq Mockups with Pattern Libraries and Frameworks

                    People often wonder how much visual detail to put into their wireframes. There's an attractive elegance to a simple black and white sketch, but it can sometimes lead to gaps in the shared understanding of what the final product will really look like.

                    Wireframes shine during the early phases of product development when ideation and rapid iteration are most valued. But what makes them ideal for this phase also hinders them in the next phase, when pixel precision and visual details are called upon for implementation. Despite this, many people (I'm guilty of this as well) try to incorporate these fine-grained and aesthetic details into the wireframe itself by tuning fonts and adding colors and other visual effects.

                    This can often lead to confusion when these high-fidelity wireframes are used as implementation specifications and sent "over the wall" to the development team. Most wireframing tools are not optimized for creating artifacts that look and feel like a finished product. Yet creating polished renditions of every screen using a tool like Photoshop is time consuming and may not translate well to the final product anyway.

                    There is another way. The only requirement is good communication within the team.

                    Separation of Concerns

                    An alternative to pushing wireframes beyond their limits is to keep them low fidelity and let another tool do the work of specifying the look and feel. Tools for this purpose are already well established, in fact, especially for web applications and sites. Sketchy, (mostly) black and white wireframes pair very nicely with pattern libraries (and, to a lesser extent, style guides). Before diving in, let's define what they are.

                    Sketchy, black and white wireframes pair nicely with pattern libraries.

                    Like their younger sibling, style guides, pattern libraries contain definitions for a particular look and feel. They go one step farther though, in that they often define behavior and are backed by working code. Large companies have been using pattern libraries for a long time but until recently they were too labor intensive for smaller companies, often requiring dedicated designers and developers working outside of the primary product teams.

                    This changed when the Twitter Bootstrap (now just called Bootstrap) framework was released a few years ago. It was (and is) a free starter kit for web development that provides compliant, robust HTML templates and generally good-looking CSS styles (which can be customized to suit your brand). It comes with its own grid and typography definitions as well as styles for buttons and forms. In short, it takes a lot of the hard work out of starting a web project and making sure that it will work across browsers. A framework like Bootstrap can be used as a good foundation for a pattern library.

                    Pattern Libraries + Mockups in Practice

                    The main advantage of pairing a pattern library with Balsamiq Mockups is that it can free you from worrying about look, feel, and behavior when designing yet provide pixel-perfect renditions of the final product components.

                    If you already know what a button (or tab, menu, etc.) is going to look like and what its state transitions will be when you click it, you don't have to style it in your wireframe. Black and white and Balsamiq Sans is just fine. Having a pattern library can allow you to jump straight from wireframes to code without leaving the final vision undefined.

                    Having a pattern library can allow you to jump straight from wireframes to code without leaving the final vision undefined.

                    Here's how you can introduce them to Balsamiq Mockups. You'll find that they get along quite well together!

                    If you have the resources you can create your own pattern library or you can start with a customized download of Bootstrap or Foundation (more examples at the end of this post). The next step is to create a mapping between it and the controls in Balsamiq Mockups. This essentially amounts to developing a shared agreement of "(this) means (this)." You can do this by creating a document showing these mappings or by having a meeting with the design and development teams around a screen to work it out.

                    Here's an example of how you might map some Balsamiq Mockups controls to Bootstrap components (you could also start with our Bootstrap Mockups To Go library).

                    Mockups and Bootstrap

                    (Note: It's ok to use some color, but it should only be used as much as necessary to indicate states and selections, for example.)

                    Having this kind of mapping means that developers no longer have to wonder whether the colors in the wireframe are supposed to be used in their code. They can just translate in their head that a blue button in the wireframe actually means a green button in the UI (if that's the color you use) and that breadcrumbs separated by the '>' character should actually be separated by the '/' character in the app, for example.

                    Having this kind of mapping means that developers no longer have to wonder whether the colors in the wireframe are supposed to be used in their code.

                    You can also extend your pattern library by creating your own Balsamiq Mockups controls as Symbols to map to other components in your library.

                    Mockups and Bootstrap

                    This mapping can evolve and grow over time as needs and design language change in your organization.

                    Here's a simple example showing what a completed wireframe could end up looking like when built using a pattern library (note that blue in the wireframe doesn't have to mean blue in the finished product).

                    Mockups Email

                    Bootstrap Email

                    Wireframe to working code with no additional design artifacts in between!

                    Having a pattern library also means that you're reusing the same code across all parts of your application so that different developers produce the same UIs, which leads to better standards and consistency. And designers can rely more on the stock controls rather than spending hours trying to replicate the look of their own, so both the design and development cycles are shortened.

                    Summary / YMMV

                    This approach won't work for all projects or organizations.

                    It is better suited to in-house teams, for example. Clients outside your organization are more likely to want to see a high-fidelity mockup or comp. Also, many of the existing pattern libraries are for web-based products. Desktop and mobile application pattern library templates and examples are less abundant. Additionally, you should have good communication between design and development teams for this approach to work. Waterfall and remote teams might struggle with this.

                    That said, it does offer many advantages in certain setups, such as:

                    • Saves time when wireframing
                    • No mismatch between mockup and reality
                    • Good for Lean/Agile methodologies where deliverables don't need to be so formal
                    • Good for small teams and startups without many resources (especially when using frameworks)
                    • Different skillsets can be applied to different design areas (e.g., visual designers and developers for the pattern library, interaction designers for the wireframes)
                    • Design processes (wireframes vs. pattern library creation) can be done independently resulting in fewer bottlenecks
                    • More UI consistency across the product

                    Pattern Library Examples and Variants

                    Some resources to help you develop your own pattern library:

                    What do you think? Have you had luck using wireframes in conjunction with pattern libraries? Feel free to leave a comment below!

                      Next Page »