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!

        Creating Project Templates and Examples for Polished UX and Bootstrap Projects

        We created a tutorial to give you some ideas for how to create project templates that contain elements you commonly use in your projects.

        Along with this tutorial, we created two example templates.

        The UX Template is designed for people working on UX Design projects who typically need to present a polished deck to clients. Here's a preview of what you'll find in this template.

        The Bootstrap Template is designed for people who know they're going to be using Bootstrap, and want to use the text elements, and components common to the Bootstrap framework. Here's a preview of what you'll find in this template:

        You'll find more information, including videos for how to get started in the tutorial. a.thumb {
        display: block;
        position: relative;
        float: left;
        height: 200px;
        width: 200px;
        margin: 0 12px 12px 0;
        border: 3px solid #eee;
        } img.thumb {
        display: block;
        width: 400px;

          Mockups Tips for Getting Unstuck

          It happens to all of us. You get stuck. You're stalled on a design and don't know what to do next. Or you find yourself using the same tired design pattern over and over again, though you know there's gotta be a better way. And then there's the sneakiest form of stuck: reacting to a feature request by whipping up and sending off the first design that comes to mind without diving deeper into the problem.

          These scenarios are frustrating because you know that not only is there a better design out there, there's a better designer inside. You just have to find a way to jar it loose by waking him/her up.

          There's no sure-fire way to do this. Every case is different. And sometimes it just clears up on its own. In this post I list a few techniques we've used to kick-start that process using Balsamiq Mockups. Hopefully you'll find them helpful.

          Technique #1: Embrace Constraints

          There are an infinite number of design solutions for every idea. Yikes! If you think about that it can stop you right in your tracks. But we all know that there's nothing like a deadline or an arbitrary restriction to get things going. Here are some suggestions along those lines:

          1. Limit yourself to 5 minutes (or less!) per mockup. After 5 minutes, create a new one and try to come up with a totally different idea. Repeat. See how many ideas you can create like this.
          2. Try to create 5 mockups in 10 minutes around the same design problem or idea. (Tip: Learn keyboard shortcuts to help you work faster.)
          3. Limit yourself to 10 UI controls. See if you can describe your idea in even fewer; it often doesn't take many to capture it.
          4. A variation on the above: limit yourself to a basic subset of UI controls. Pick the most generic ones (rectangle, button, shape, etc.) and work using only those to focus on the big picture first.
          5. Peldi has said that the first design is often version 3 of the product. Create the wireframe you have in mind then try to remove as many pieces as possible. This will challenge you to think about what's most important and what's not really needed.
          6. Put all the UI controls on the canvas then try to build your mockup. It may help you think of other methods of doing things in the UI (as well as scramble your brain a bit). Move aside the unused ones, but don't delete them right away because you may come up with a use for them later on in the design.

          All The Controls!ALL THE CONTROLS! (download this file)

          Technique #2: Collaborate

          Mockups is great for working together with other people. And most of our products now allow multiple people to work on a single mockup at the same time.

          Here are some suggestions for how to get more out of your design by working on it with someone else:

          1. Work on a design for 5 minutes, then hand it off to someone else. The next person can either build on it or modify it. Repeat until you're both happy with it.
          2. Take turns adding UI controls. (You can easily do this in myBalsamiq and Mockups for Google Drive. In other versions you can sit at the same machine or use Dropbox or a shared folder across machines.)
          3. Swap projects with a designer on another team. Have them do one of your designs while you do one of theirs.
          4. Assign multiple people to work on the same design. Do a "show and tell" with time for discussion about each design. Then allow each person to revise their design based on the ideas from others.
          5. Pair design. Have two people sit together and assign one person to describe the design and the other one to use the mouse and keyboard in Mockups. Even if you have a very specific UI/design in mind it may come out different if someone else is building it, and the process of describing it may help you catch some flaws with it.

          Collaboration in action in Balsamiq Mockups for Google Drive

          Do you have techniques for getting unstuck that you use? Feel free to describe them in the comments!

            Behind the Scenes of Our Documentation Process

            We recently wrote about some of the changes we made to our support site in the last year. Following up on it, this post goes into depth about the details of our process for adding content to our support site.

            As we are a software company, our process for adding documentation is not unlike our process for adding features and fixing bugs. Here's how we do it.

            Recording a need

            Documentation updates can be prompted by several actions. Here are the primary triggers:

            1. A customer contacts us (via phone, email or our forums) and mentions a typo or mistake in our documentation or has a problem that should be explained better on our support site
            2. We add or change something in our product and therefore need to update our documentation
            3. A support employee mentions that lots of people keep asking the same question and asks to create a dedicated FAQ or article about it

            As much as possible we try to track things our customers want to know more about and things they're frustrated by. Our process hinges on frequent communication between our customer-facing staff and our documentation and product people. We also want to make it easy to then record those frustrations as tasks and assign them to the right people. I am responsible for our non-sales related documentation.

            The three main tools we use in our documentation workflow are:

            • Desk - for email support and for managing our documentation knowledge base
            • HipChat - for communication among the team, and
            • Pivotal Tracker - for tracking issues and documentation requests.

            If an issue related to documentation is raised in Desk (our direct customer support channel), it can be assigned to me. We also have a dedicated HipChat room called Docs, where we discuss ideas for new support articles and give feedback on existing ones.

            Some conversation in our HipChat Docs room, including status updates from Pivotal

            To stay in the loop I also monitor the Support HipChat room so I that can see what people are having trouble with.

            Some conversation in our HipChat Support room

            Inside Pivotal

            We use Pivotal Tracker for our product feature requests and bug fixes, so it made sense to use it to track documentation tasks as well. For a long time our documentation issues were filed in a general "Website" project, which was a catch-all for anything affecting our website (documentation, page redesigns, CSS alignment issues, etc.). But we recently created a separate project called "Docs" just for documentation and tutorials and moved our documentation stories into it.

            We also made it easier to add issues to Pivotal by connecting Pivotal to HipChat via Zapier. Now, when a documentation story is created or updated in Pivotal, it is shown in HipChat (you can see this in the first HipChat screenshot above). Conversely, we can create Pivotal documentation issues directly from HipChat by typing: "Pivotal(issue name)". Employees can also create Pivotal stories directly in our Pivotal Docs project.

            Once the documentation tasks are in Pivotal, I can organize them and begin work on them. Organization within Pivotal can be a bit of a challenge though, so I came up with a few additional processes for getting a handle on our documentation stories.


            After we separated our documentation stories from our other website stories I quickly reviewed each of them. I started by labeling those I didn't understand as "to review." Those that appeared to be no longer relevant I labeled "to remove." The people who created those stories pitched in and added their comments or deleted them and we reduced the size of the backlog a bit.

            Next, I tried to think about how to prioritize and group the remaining stories because I didn't have a good way to get a sense of urgency and difficulty. One of the first things I did (perhaps because diving right in was too intimidating) was develop a labeling system.

            After some iteration, I came up with three categories of labels:

            1. The Action label group, describing what kind of task was needed
              • "New" means this is a new article that should be created
              • "Update" means that this is an existing article that needs updating (e.g., out-of-date screenshot, missing feature/function)
              • "Clarify" means that something in this article is not clear and should be reworded or modified for clarity
            2. The Actor label group, describing the type of documentation affected
              • "FAQ" is for any FAQ (product, licensing, installation)
              • "Documentation" is for product user guides (anything in the Mockups for Desktop or myBalsamiq "Documentation" category or any of the plugin User or Admin guides)
              • "Tutorial" is for tutorials
            3. The Category label group, describing the affected product or category within the Actor group (myB, Desktop, GDrive, Licensing, etc.) - this is optional

            When adding the tags I try to place the tags in this order: "Action (Category) Actor" so that they make sense when written out. E.g., "New Installation FAQ", "Update myB Documentation", "Update Tutorial".

            This has worked pretty well, as the labels seem to fit most requests and I'm able to add them easily when a new Pivotal issue is created. It also helps me tackle these issues in bulk more easily. So, for example, one month I made a point of addressing all "Update" stories in order to try to get our documentation up to date with the latest release (I didn't make it all the way through, but I made a big dent!).

            A few stories in the Pivotal Docs project


            To help with planning, I devised a system for estimating the work required for our documentation and tutorials stories. Here's the current version:

            • 0 points - No change needed (e.g., duplicate or no longer applicable)
            • 1 point - Typo or minor wording change
            • 2 points - Updating or adding a screen shot, adding a new section to a document or a major re-write of one or more sections of a document
            • 3 points - Creation of a new article or video

            There is a big jump between 2 and 3 points (writing a long article or creating a video can take a couple of days), so it's not exactly a linear scale, but it's simple and clear enough to do be useful.

            New additions

            A new writing tool

            One of the frustrating things for me when I started writing new documentation was just how long it took. For a simple document it often took a full day. One of the reasons is that our documentation is written in HTML (which is ok, although it adds some time) in a web-based tool (which makes iterations and drafts a bit challenging) and often requires screenshots (which can be a pain to create and upload).

            What I really craved was one tool for everything, preferably that could work offline. After a lot of research, I settled on ScreenSteps Desktop, a tool for writing help guides that has built-in image capture. This was the killer feature for me. It can also automatically resize images to a set width to fit our web template. This saves me from having to edit them after I've captured them. And it outputs HTML with the ability to customize the output template with variables so that it generates the exact HTML that I needed to paste into Desk. My edits to the default template included removing the header and footer, mapping to the correct images directory, and adding specific CSS class names that we use on our site.

            Our ScreenSteps HTML template, stripped down to meet our needs (click to see more of it)

            I haven't used it for our main documentation yet, but it worked great for our "How-To" guides, which are heavy on images.

            The process of publishing images also got easier when we moved to using GitHub to manage uploading our images, meaning that I could drag and drop them from my computer rather than using FTP.

            A Style Guide for docs

            Finally, we wrote a style guide for our documentation (although I haven't gone through the process of updating our old docs with it). It covers topics like rules for HTML and how text should be capitalized and formatted.

            A work in progress...

            One of the big things I was hired to do was improve our documentation and I'm pleased with the new content and processes we've added in the the last year. The process is a lot smoother than when I started and I'm hopeful that our content will take another big leap forward in 2014.

            Still, I know that as a UX designer turned Doc writer I have a lot of room to grow, so I'm focusing on improving my abilities. Although I've been struck by the many similarities between UX design work and writing documentation. For instance, the process of creating something based on a specific need, giving an orderly structure to it and then refining and polishing it seems to activate the same neurons as designing a UI for me.

            It also has many of the same challenges as my UX roles. Much like coming into a company as a new designer, I inherited a "product" (our support site), which had existing content and an underlying technology platform, both of which were limiting in some way. There is a significant cost to shifts in either that can outweigh their advantages. (We have researched other documentation platforms but haven't found one that meets our needs much better than what we have, so I'd love to hear what works for others.)

            Fortunately, I've had help throughout the year. I adopted the good practices that had been established when I arrived. And I started paying a lot more attention to other support websites and made an effort to understand how they were designed. I also attended the Write The Docs conference last year, where I connected with other doc writers and learned about the resources and tools that they use.

            I'm still learning though, so I welcome your advice or feedback in the comments!

              Improving the Experience of Our Support Website

              contact us

              At Balsamiq we've always prided ourselves on our customer service. We have real live humans who stand by the phone and love hearing it ring. And we're blazing fast with email support by providing coverage from our U.S. team during our working hours and passing it off to our European team during theirs.

              We also rely heavily on our web support channel, i.e., our support website ( This site serves as our repository for product documentation and FAQs, helping people learn the product and get help if they run into trouble. Our support site is very important not only for customers wanting to get answers, but for our support staff, who can direct people to specific articles that can answer their questions.

              In 2013, we identified several touch points in our customer journey that we wanted to improve. Support was a primary focus, being an aspect of the company's service that customers can repeatedly return to. A little back story describing the evolution of our support site may help understand what we hoped to improve.

              When Balsamiq started, our documentation was modestly maintained on our servers (a single page per product) and we responded to support primarily using Gmail and GetSatisfaction. As the company and customer count grew, we grew our support team. In 2012 we started using to manage our support system, from email management to publishing our documentation.

              We shipped a very basic site with a searchable set of articles using Desk's base templates. While we continued to write support articles and improve how we responded using the email management capabilities of Desk, the support site was largely unchanged. The questions and feedback we got over that first year helped us become aware of its limitations, and we started to describe the problems internally.

              The predominant issue had to do with difficulty locating content. From our perspective we also identified problems connecting related content, keeping media up to date, and knowing if users were getting the answers they were looking for.

              This was a re-alignment and not a redesign. We set out to improve the site, focusing on aligning the organization of content and the layout of entry pages to address the findability problems, and gardening the current content to reflect user needs.

              A new look + better organization

              Here's a list of the most noticeable changes to our support site, although there were many other, smaller changes we made to both our processes and our site.

              Updates to our support home page

              We wrote up requirements and started wireframing a rough idea that we could use to discuss the problem and explore solutions. We iterated over it a few times until we had a basic understanding and agreement on the direction we wanted to take, and immediately started front end development. We like to make refinements in further iterations in code.

              This screenshot shows our initial wireframe for the support home page.

              Rather than just showing the first 10 articles in each category we wanted to encourage visitors to either search for what they are looking for or choose a category to drill down into for a more approachable index page for that category. This cut down greatly the amount of text on the page and provided better entry points to a refined search. Also, by looking through our logs, we could pick out some of the most popular search terms and place them next to the search box, helping people who didn't necessarily know how to describe what they were looking for. Finally, increased use of icons and images would differentiate the categories and other link targets better.

              Here you can see a comparison of the original support site's main page with the redesigned version.

              Better, no?

              Better sidebar navigation

              Our sidebar (the grey navigation bar to the right on our individual articles) now links to headings within the page so that you can get an overview of the article you're reading without having to scroll all the way through to see if it contains the content you're looking for. We've also tried to save some time and effort by providing links to some related articles below that in case the page you're on doesn't answer your question or you want more information.

              This screenshot shows some of the navigation changes to our sub-pages, as well as updates to our tutorials (discussed below).

              What's new?

              More focus on tutorials

              We got feedback last year saying that many of our articles were too wordy and too focused on describing features rather than on how to actually do stuff with our products. So, we made a concerted effort to step things up in the tutorials department. Here are some of the changes we've made.

              A new index page for tutorials

              We started by creating a new home page for our tutorials. It's grouped into categories for beginners, intermediate users, and people who want to do more with our products once they've learned how to use them.

              We also got feedback from people who said that they just wanted to see the videos, so we've labeled the tutorials that contain videos as well as consolidating all of them into one playlist that's viewable at the bottom of the new index page.

              "How-to" guides

              We also experimented with some different kinds of tutorials. Some people said that many of our articles were too general or that they didn't have many pictures or enough guidance. So, we took some of our most frequently asked "how do I...?" questions and created a few detailed, step-by-step guides showing these processes each step of the way. Our guides on how to create a symbol and how to download from Mockups To Go, for example.

              More "Tips and tricks" videos

              We describe Balsamiq Mockups as "Excruciatingly simple. Filled with hidden powers." The goal of the videos we've added recently has been to reveal some of those hidden powers by showing how you can do things with Mockups that you may not have thought were possible and/or easily accomplished. We relied on our own Mockups experience as well as examples from our customers to create a few short videos, such as "How to Use Show / Hide Markup for Layering" and "How to Create Multiple Header Rows in a Data Grid" that might make you say, "I didn't know you could do that with Balsamiq Mockups!" We hope to create more in the coming year.

              Here's an example of one of them:

              Looking ahead / our hopes for 2014

              Here's a quick list of some things we'd like to add in the next year:

              1. Better, clearer docs, more tailored to specific needs
              2. Better metrics for tracking the usefulness of our articles
              3. A more structured course for learning Mockups
              4. Tagging or labeling for better cross-referencing of articles
              5. Applying the editorial style guide that we finally got around to creating to all of our old articles

              How are we doing? What would you like to see more or less of? Have any tips for us? If so, leave a comment below or email us at We're eager to get better!

              — Leon and Mike

                Ben on the Balsamiq Customer Experience

                Supporting customers is such a huge part of what we do as company. Everyone contributes to customer support in one way or another, and our awesome team keep working to improve that experience.

                Recognizing that we don't just care about support, but live it, GetSatisfaction interviewed Ben for their Customer Experience Series of videos. Our forum powered by GetSatisfaction has been one of the primary resources we've relied on for keeping close to our community. We're huge fans.

                It's a wonderful feeling knowing that our connection to the community is in such good hands.

                  Sketchnotes from Mobile UX Summit 2013

                  · Posted by Ben in design and tagged , · 10 Comments

                  Hi, all. Ben here again with more sketchnotes! (Here is a link to the first set of sketchnotes I posted.) Last week, I had the opportunity to participate in the Mobile UX Summit, put on by Environments for Humans and Rosenfeld Media. It featured a fantastic lineup of speakers, all focused on the nuances of designing for mobile experiences.

                  Industrial-Designers One of the biggest takeaways for me was from Josh Clark's talk. He pointed out that touch devices have fundamentally changed who we are and what we do as interface designers. Whether we are aware of it or not, we are also now industrial designers. Ergonomics is a huge part of what we do, and must be taken into consideration when we craft our designs.

                  Fonts-have-voice Another main point that resonated with me was from Jason Teague. He made it clear that we have to elevate the importance of typography. In many mobile designs, the typography and layout are some of the only design considerations you can impose on an interface to make sure that it convey the proper emotions to your users. "Mobile first" has become a cultural buzz-phrase, but we should perhaps start with typography first before tackling more of the visual design.

                  User-testing Finally, from Theresa Neil's case study, it was clear immediate user testing is an absolute must. This is something that we really care about here at Balsamiq, and want to make as easy as possible. We have recently added some features to make this easier, and have even more planned. I loved hearing about designers getting users to interact with their wireframes before even moving on to visual design. Taking an approach like that will save you incredible amounts of time and money down the road.

                  There was so much more in this conference that I loved, and hopefully my full set of sketchnotes will help you to benefit from it as well.

                  (Click to enlarge; ← and → to move through the images)
                  Mobile-UX-Summit-Sketchnotes-1 Mobile-UX-Summit-Sketchnotes-2 Mobile-UX-Summit-Sketchnotes-3 Mobile-UX-Summit-Sketchnotes-4 Mobile-UX-Summit-Sketchnotes-5 Mobile-UX-Summit-Sketchnotes-6 Mobile-UX-Summit-Sketchnotes-7 Mobile-UX-Summit-Sketchnotes-8 Mobile-UX-Summit-Sketchnotes-9 Mobile-UX-Summit-Sketchnotes-10

                  And here is a PDF with the entire set: Mobile-UX-Summit-Sketchnotes.pdf.

                  How has your design process changed as you have focused more on mobile experiences? Let us know in the comments below.

                    The User Experience Gap

                    Here at Balsamiq, we hear a lot of stories about people using our application to build great user experiences. We are so proud to be a part of the UX revolution that has taken place over the last ten years. There's no doubt that many of the websites and applications that we use regularly are now more tailored to specific user goals and configured around the way actual users work. In keeping with our belief that we love the problem more than the solution and that life's too short for bad software, I wanted to write about some areas where the problem (i.e., hard-to-use software) still exists.

                    Every once in a while I'm reminded that there are still plenty of products out there that are in need of some serious UX love. So many companies "get it", yet there are still stragglers, especially in certain industries whose products are not traditional computing devices. There seems to be a line that divides desktop and mobile experiences from those in the rest of the digital interface world. And once you cross that line things get ugly, fast. I think that these realms represent the next frontier of UX opportunities for those willing to brave the waters.

                    Selling the Sizzle

                    My most recent reminder was at the gym. The elliptical machine I was using had a very modern component to it, the console that tells you how fast you're going, how long you've been going for, etc..
                    Elliptical machineFancy!

                    This machine has an LCD display with a touch screen. Cool, right? As a UX designer, though, I view everything through the lens of user experience. I was struck by what a bad UX this was, despite all the modern technology underneath. There's just way too much going on here. Remember, I'm moving my legs at 4-5 MPH while using it, which has quite an effect on the rest of my body. While it boasts a list of impressive features (a virtual trainer, the option to change the image I see that tracks my progress, etc.), I didn't see anyone around me with anything but the default settings. The screen is washed out and hard to read, and it's very hard to tell at a glance how to do what I want to do.

                    Contrast this with another exercise machine I've used in the past:

                    Older exercise machine
                    More usable

                    This one has quite a bit to it as well, but I would argue that it offers a much better experience.

                    The main problem with the first machine is not with the user interface design. There is an order to the buttons, there is a fair amount of consistency, and the buttons are adequately sized given the constraints of the screen. My guess is that there was a deliberate attempt at user interface design here. But what's missing is the user experience perspective. A user interface designer asks, How do I arrange all of these buttons in a logical way?, whereas a typical question in the user experience designer's toolbox is, Why are each of these buttons here? Are all of them really necessary?

                    For instance, do I really need a "virtual trainer" and the ability to change the wallpaper? And, given that market analysis has determined that the target price point necessitates a cheap LCD screen, how readable will this screen be in various lighting conditions and how well will it respond to touches from sweaty, jostling fingers? Did someone intervene and think about the experience of using this screen?

                    It seems that nobody thought to say, "Just because we can, doesn't mean we should."

                    This is a classic example of technology-driven design and "featuritis." My guess that the design discussion went something like this:

                    Dilbert cartoon© Scott Adams - Original image here

                    This cartoon is from 2001, when this scenario was commonplace. Though it clearly still exists, the frustration this way of thinking caused has led to a user-centered design culture that is now at least represented, if not respected, in many software firms. It is a fundamental paradigm shift that focuses less on individual features and more on holistic tasks and goals. And it typically requires full-time roles dedicated to understanding and designing the "experience" of a product, separate from those who will be actually building the product.

                    Many companies outside of software and web development firms don't yet have these roles. This is problematic because the people who build digital products like the exercise machine screen are often not representative of the people who use them. There is a problem on the purchasing end as well, particularly for items like these. It is frequently the case that the people who buy the products are also not representative of those who use them. Feature lists can be used as the "sizzle" of the steak, though the consumers ultimately care most about the taste. Gym owners aren't savvy enough to pick the machine with fewer features.

                    Looking at this year's model of the same exercise machine, the trend is continuing. Now you can browse the web, play games, and, tweet and update your Facebook status while running (more sizzle). There are also even fewer physical buttons, just a big touch screen. And here's the description of the new "LFconnect™" feature:

                    Easily choose your favorite websites through your LFconnect account and they will be instantly available at login.

                    Do people at the gym really want another login and password to remember? And do they want to spend time configuring the treadmill while at the gym over their lunch break? Will gyms now need to employ technical support staff?

                    Car Interfaces: Unusable at Any Speed

                    Unfortunately, the exercise equipment industry isn't the only category of products that have been left behind in the UX revolution. The feature-laden user interfaces found in car dashboards in the last five years mirror the trajectory of the treadmill UIs described above.

                    I won't dwell on this (as others have covered this topic before), but, suffice it to say, most automotive interface user experiences are just bad. They are still in the early days, akin to the first smartphone era circa 2006, where more and more technology could be crammed into a small space for relatively cheap. And the UI design is there, but, again, it's the UX consideration that's lacking. Here's an image of such a UI:

                    Toyota's Entune SystemToyota's Entune System

                    Another example is a screen that shows a list of traffic incidents nearby. Yes, this is relevant to me as a driver. But what I really care about is: how long is it going to take me to get where I want to go? and is there a better route than the one I'm on now? And extra non-driving related features such as weather, stocks, and sports scores make it harder to find the functions I actually do want.

                    Let's look at some of the reviews of the Toyota Entune mobile app, the companion app for the dashboard experience.

                    Toyota's Entune System
                    Entune app reviews

                    I love everything about this car EXCEPT Entune!

                    I feel ripped off big time.

                    Are these the experiences people should have in a product they just paid tens of thousands of dollars for?

                    More Examples from the Next Frontier

                    Here are just a few more products calling out for help, though there are many more.

                    Kiosks and Self-Checkout Machines

                    The other day I was at a supermarket with Ben Norris and the self-checkout machine didn't recognize the bar code on what he was buying, so he tried typing in the bar code himself, at which point, seeing his frustration, the employee assigned to the self-checkout machines came over and took over, knowing that Ben wasn't going to get where he wanted to go.
                    The employee using the assist modeThe "Assist mode" screen
                    He'd seen this problem before and knew that anyone who hadn't been trained on these machines wouldn't be able to figure it out. It happened a lot he said, quipping, "these are the reasons I still have a job."

                    Smart Watches

                    And now the "smart" watch flood is beginning. Here we're going to see UIs taken from other products applied to a new device, poorly (at least initially). With smartphones we had the infamous "if you see a stylus, they blew it", and now:


                    Why is everyone fixated on Apple building a television? It's because the current experience of watching internet programming on your television is terrible. The UX is awful. I recently spent 2 hours trying to figure out why my parents' "smart" blu-ray player wouldn't play their Netflix movies. The Samsung "smarthub" experience is much like the treadmill: Lots of options for things I don't care about (more options to change the wallpaper) and a lot of steps and difficulty for the things that I do care about. Alan Cooper posed the question: "What do you get when you cross a car with a computer?" (Answer: a computer with a motor and wheels.) Today, crossing a TV with a computer yields a computer with a remote control.

                    Closing the Gap (No Experience Left Behind)

                    Yes, user experience is a buzzword these days, but I would argue that it is far from a fad.

                    Looking a little deeper, what we call user experience design is really just traditional design principles applied to digital products. Good design has always been about thinking about the user of the product and the way they use it. Dieter Rams designed great experiences long before the term "user experience" existed; it's clear that his products are not just pretty, not just useful, but considered. Design is about solving problems, and user experience design is really just a shorthand way of stating that something should be designed around the user's goals and their psychological, physical and contextually-defined limitations.

                    The lesson of the UX revolution has been that the products with the best user experience win. Those industries that are still competing on features alone should be on guard.

                    Why has Apple been so successful? Because they figured out early on that it's not about features as much as it is about solutions. They think about conveniences, like pausing playback when you pull the headphones out of your music player.

                    Inevitably, these user experience gaps will close. It is starting to happen already. Some manufacturers of existing products are catching on and ramping up their UX expertise while smaller, nimbler, and/or more UX-aware companies (Tesla, Square, Roku, to name a few) are emerging to take on the markets that the UX laggards once had a stronghold on.

                    Suggestions for Companies Seeking to Prosper in the UX Economy

                    What if your products are the UX equivalent of a pre-iPhone smartphone? Where should you start?

                    First off, on our own site, you can read Craig Willis's story about being promoted to product manager based on first-hand knowledge of his product's usability problems. Or, read about Yarone Goren's firm which helps companies create a UX vision for their products. You can also build up your UX skills in-house via UX Apprentice and other sites that teach the basics of sound UX methodologies.

                    Then, start wireframing your ideas (using Balsamiq Mockups, or whatever suits you best). Test, iterate, refine them. Work low-fidelity, technology-agnostic first. Only then think about which technologies can help guide you to your solution, and start building. Remember that, though not always true, the best UI is often no UI. Usability does not come from adding a touch screen and UX is not a verb.

                    But, even before that, learn to say no. Many bad experiences come out of not being able to decide on which features are most important and therefore just including them all. This is not what your customers want from you.

                    A Call to Action for UXers

                    These industries represent a huge series of UX opportunities. As members of the UX community, let's not limit ourselves to websites and mobile apps. Does the world really need another photo filter app? If you really want to make a difference as a UX designer, go where UX is lacking. This will also add longevity to your career as you carve out your own niche within UX. Seek out bad experiences in the world and ask yourself, "could I make this better?" Be the Tom Joad of user experience.

                    Do this by approaching companies that don't get UX and convincing them to hire you, even if that makes you a UX team of one. Don't expect it to be easy or for change to happen right away. You may have to start out as a UX guerrilla, and you may spend more time educating your teammates about UX than designing award-winning experiences. But this is how it starts.

                    Many of us got into UX because of our own frustration with poorly-designed technology. Now, each day a new product comes out that has a screen that didn't have one before. There are many UX mountains yet to be ascended, many UX lands yet unexplored, many UX roads still unpaved. Go forth.

                    Do you have examples of products that have been left behind in the UX revolution? Do you have ideas for how some of these products could be improved? We'd love to hear about it in the comments below.

                      Next Page »