Learning to Wireframe: a Quick Guide

Mobile App Wireframe - Ideation PhaseMobile App Wireframe

Wireframing is becoming more commonplace in the product and design industry for a good reason: it works.

Creating wireframes helps you think and communicate better about the structure of the website, software or mobile app you are building. They are representations of ideas that can be quickly discarded and iterated upon until you find the best solution for your customers.

If you are looking forward to getting started with this important UX technique, keep on reading! ?

1. Learning to Wireframe

Watching videos is a great way to quickly pick up new skills.

Wireframing for Newbies is a 19-minute in-depth introduction to the practice of User Interface Wireframing that will guide you through the main concepts of this technique and how it fits into the design process.

The video covers three main topics:

  1. The role of UX in the software development process
  2. What wireframes are and how they compare to other UX artifacts
  3. The two phases of wireframing

Wireframing is a skill that can be learned and honed. To complement the video tutorial above, this article on Wireframing for Beginners will help you reinforce the basic ideas and start improving right away.

Here are some useful tidbits from the links above:

Successful wireframing makes it easier to solve two problems:

  1. how to help customers accomplish their goals
  2. how to find out if your solution will work

Wireframing addresses these problems in two phases:

  1. the Ideation Phase. To generate as many ideas as possible.
  2. the Validation Phase. To determine whether your proposed solution can be agreed upon by the stakeholders.

The two keys to making progress and designing better wireframes are practice and carefully integrating feedback in your iteration process.

2. Choosing a Wireframing Tool

Wireframes can be created with pen and paper, but "these days, the software available for creating interactive wireframes makes the task quick and easy to do." (from UX Mastery) If you decide to go with software instead of pen and paper, choosing a tool can be daunting.

We've created a resource to ease up this task on you. In How to Choose a Wireframing Tool you will find a set of questions and recommendations to evaluate different software. It includes:

  1. What is the tool's main purpose?
  2. Does the tool fit your preferred workflow?
  3. Is the tool actively developed?
  4. How is the tool supported?
  5. Who’s behind the tool? Will they stay in business?
  6. How much does the tool cost?
  7. What do others think of the tool?
  8. Where can I find a list of wireframing tools?

It's a smart resource that will give you a head start on exploring the landscape of wireframing tools.

3. Diving Deeper Into UX

Wireframing will help you achieve important goals in the initial phase of your projects. However, the UX process is made up of several stages that will require the mastery of a variety of techniques and concepts.

We have partnered with Theresa Neil to develop UX Apprentice, a learning resource for people interested in getting a broader understanding of the basics of UX Design.

Thanks to our awesome community, UX Apprentice is now available in 7 languages. Use it to explore all the resources available to you on your journey as a UX Designer. You might even want to collaborate with us translating it if it's not yet available in your own language.

UX Apprentice

This is it. We hope these resources give you the confidence to start making awesome wireframes!

Let us know what you think once you try this out! What else should we include in this quick guide? Is there any part of the process we can help you improve? What tool did you choose and why?

Tell us here ⬇️ in the comments.

Happy wireframing!

- Jess

UX Apprentice in multiple languages

Part of our mission at Balsamiq is to spread the knowledge of User Experience.

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.

And here is another piece to the puzzle.

UX Apprentice

UX Apprentice is 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.

We developed this learning resource to help people who want to begin a learning path in User Experience working with Theresa Neil, an author and consultant who educates companies about UX Design.
ux-apprentice-home-page

UX Apprentice in Multiple Languages

Making UX Apprentice available in multiple languages was 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 wanted to make sure that all kids around the world can understand it fully!

We've already translated UX Apprentice from English into

  • German
  • Spanish
  • French
  • Italian
  • Portuguese
  • Swedish

Click on the world icon at UXApprentice.com and you'll find all the available languages.

ux-apprentice-languages

Other languages 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!
Francesca

Edit the Balsamiq Docs!

We've made it easy for anyone with a Github account to submit edits to our documentation.

As we've written about before, improving our documentation has been a focus of ours for a while. We've gone from one or two developers writing docs when they found the time to a team of about five people that make sure the docs are updated with each release.

We recently updated our docs site (sites, actually) to be easier for both readers and writers.

This year I attended the Write the Docs 2016 conference in Portland to learn from other writers. I also spoke on a panel discussion there to share what we learned through our documentation overhaul. And our documentation repositories are public so that anyone can use them as a starting template.

Looking at open source software projects we use and talking with other "documentarians" whose docs are on Github, I noticed that many projects invite documentation collaboration from readers via Github "pull requests". Since our docs are on Github, we decided to do it too.

We aren't an open source software project and we don't rely on volunteers for our work, but we often get emails about our documentation; Typos, text that's not clear, or out-of-date information, for example. Now, with a Github account, you can propose those changes directly in our documentation!

Here's how.

At the bottom of each article on docs.balsamiq.com and support.balsamiq.com you'll see a link called "Edit this page".

Clicking that link will take you directly to the Markdown source for that specific page in our repository.

To propose a change, click the "edit" icon to "fork" the repository. (You have to be logged into Github to do this. If you don't already have a Github account, learn how to sign up here.)

You can then edit the file. Add a brief explanation of your changes and click the "Propose file change" button to submit it.

Once you do that we'll immediately get notified and, if we agree with the change, we'll merge it into our "master" branch and it'll be live.

Since we added this, we've already had one contributor, Song Li, who fixed a link in one of our Sales FAQs. Thanks, Song Li!

And thanks in advance to our community documentarians who will use this feature. You're helping to make our documentation better for everyone.

Volunteer Opportunities for UX Designers or Developers

code-for-americaPhoto Credits: Code for America

We spend years developing skills and craft to further our careers. That experience becomes a valuable resource that may be put to good work in the form of volunteer time or pro-bono work for nonprofit organizations.

Individually, some of us get opportunities to help others by word of mouth referrals. If you're a UX designer or developer looking for ways to provide your expertise to organizations needing assistance, or a nonprofit in need of some design time, try some of these sites that may help you find the right match.

Conferences

Conferences focussed on matching design/development expertise with nonprofits are a great way to see who's doing what, and talk to a lot of people in one place. There are a handful of well-known events that draw a diverse crowd.

The Feast, for example, inspires with the stories of organizations successfully doing work to improve the world, and then puts immensely talented tech people in the same room with organizations focussed on this meaningful work.

The Nonprofit Technology Conference (NTC) is a conference focussed on Tech projects in the nonprofit sector. The event brings together a large number of organizations in its network, to foster sharing information and collaboration. Networking events at the conference, we're told, are one of the best ways to find out more about a lot of organizations in the nonprofit sector doing work that may interest you.

Searching for Volunteering Opportunities

If you're just starting to do your research about volunteer opportunities, or simply know what type of organizations and work you'd like to contribute to, these sites feature events or listings of volunteer opportunities.

  • Code for America - Organizes and builds open source software to improve government services using volunteers. One page provides specific issues that can be worked on.
  • Community Corps - A skills-based volunteering program that matches technology professionals with schools and nonprofits. Organizations request volunteers and the Community Corps lets volunteers search for specific opportunities related to skill. Mostly technical, but there are some categories like website review, which would be relevant for people who do usability evaluations.
  • Geeklist Hack4Good - Organizes hackathons to build solutions to humanity’s greatest problems.
  • Hackathon for Social Good - Organizes hackathons to build web and mobile applications for nonprofits.
  • Volunteer Match - Volunteering site that lets volunteers search for opportunities by cause and locale. Doesn’t provide any match of ability to need.

If you know of any other resource that would be helpful to include in this list, please email us at support@balsamiq.com! We'll be maintaining an ongoing list of resources for volunteering and finding volunteers for nonprofit work.

Wireframes: A New Tool for Marketers and Content Writers

Let's imagine.

The Marketing Department just created the ultimate inbound strategy; the plan has been handed off, and now it's the copywriter's, designer's, and developer's turn to make their individual contributions and get the best results.

But, how can each member of the team know what's needed to achieve those results? More specifically: How long should the copy be? What goes above the fold? How can we make it more mobile-friendly? The list goes on.

Teams need to put in place a common framework to succeed. One that enables an appropriate information interplay where structure, content and design work together to achieve the expected goals.

Start with wireframes

Landing-page-mockup

Our designer and writer, Leon Barnard, in his latest post for the Atlassian Blogs, addresses this issue and explains how teams can benefit from using wireframing as a common framework to improve collaboration and bridge the gap between content and design. He suggests a couple of techniques:

  1. Wireframing to avoid the design gap: to help designers and writers communicate with each other and work in harmony.
  2. Wireframing to get better feedback: for rapid idea exploration and iteration by trying out visual variations, getting feedback on them, and then make changes.

Adopting visual tools to improve communication is no longer exclusive to designers. Marketing and content professionals are starting to introduce these techniques to enhance their workflows and share their work. In the case of web copywriter Kate Toon, laying out the copy and creating wireframes for clients “transforms the way they see the copywriting process.”

Still, wireframing is a new concept for many. To help get a better grasp on it, check Leon’s interview for the Inbound Unboxed Podcast where he gives a deeper look at the basics, best practices, tools and the benefits for marketing and content professionals.

Inbound-Unboxed-029

Communication and collaboration are essential for our projects to deliver a delightful user experience and be successful. Having the right processes and tools in place can result in better products and more efficient, in-sync teams.

If you’d like to give wireframing a try, we've prepared a quick guide to help you choose the right tool. You can also try Balsamiq Mockups for free on our website, or download a free trial. If you need help, you can reach us in many different ways. We have extensive docs, tutorials, and awesome customer service.

Staying Fresh with Good Old HTML and CSS

I know web design

As the internet keeps evolving at staggering speed, new tools are released constantly, and employers are always looking for the most experienced players. Designers seem to have no choice but to struggle with what to learn next.

Fortunately, our own Leon Barnard has offered his help on how to survive and succeed in this seemingly ever-changing industry. In his most recent article for the Treehouse Blog, he suggests we shouldn't underestimate plain old HTML and CSS to stay at the leading edge, and he gives us 5 reasons why:

  1. HTML and CSS are design tools
  2. HTML is what the browser knows
  3. CSS3 is replacing JavaScript as the language of animation on the Web
  4. Wireframes with CSS are better than a Photoshop Mockup
  5. At the very least, you can customize a web framework

Agree? Disagree? Would you add anything to this list? How do you stay current on your career? Share with us in the comments.

For a deep dive into Leon’s advice, we invite you to read the full article.

Jessica for the Balsamiq Team

Docs.balsamiq.com: Our New Static Documentation Site, Powered by Hugo

Last month we released a brand new web site for our documentation - docs.balsamiq.com. 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 Docs.balsamiq.com

Background

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 balsamiq.com 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 Support.balsamiq.com

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.

Reflection

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

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.

Summary

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!

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.

Aesthetics

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.

Release!

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


Next Page »