Toggle navigation

Why We Aren't Doing Deep Interaction in Mockups

· Posted by Mike in Products · 15 Comments

Opinions matter

Every so often we'll get a request to add features that would change Mockups from a sketchy wireframing tool to a prototyping tool. When these requests bubble up, I take the time to explain to people what Mockups was designed for, and often point them to our Manifesto, which discusses this and other beliefs we hold as a company.

We have a tutorial that illustrates various methods for designing for interaction, and shows where Mockups fits into this picture. It sometimes helps to share this, because occasionally I'll discover that the person asking is not aware of these methods for specifying interaction. More often than not, they're satisfied to have this information.

Mockups is primarily an application for describing interactive behaviors with static pictures, and this statement doesn't always sit well with people who believe that deliverables have to come very close to the real product in order to communicate the design. We have a different opinion.

The debate: sketching vs. prototyping

There are arguments on either side of the debate about whether or not you have to use interactive prototypes to describe interactive behaviors. On the prototyping side, the argument is that you can't communicate interaction without working prototypes that resemble the real thing. But animators and film makers have communicated motion with static drawings for as long as these media have existed, and at least in early-stage ideation, many still do. The same holds true for designing interaction.

Probably the most important reason we stick to this mode of design early on, using sketch-style static documents, is that doing so keeps us focussed on exploring ideas until the right design emerges from the volume of alternatives we consider.

BIll Buxton makes another point about the value of early-stage, low-fidelity design in Sketching the User Experience. Buxton believes that iterative sketching has a dramatic impact on risk, exploration and innovation.

"Jumping in and immediately starting to build the product, even if it does get completed and ship, is almost guaranteed to produce a mediocre product in which there is little innovation or market differentiation. When you have only one kick at the can, the behaviour of the entire team and process is as predictable as it will be pedestrian."

We believe this. Moreover, as a small business, it's of utmost importance to us to find the right design early. Selecting a wrong design that we would need to pivot on later could cost us and our customers in time to ship, in usability, and worse of all, relevance.

There is no silver bullet

I watched and participated in theoretical discussions about what the "ultimate IA/IXD tool" could look like on IA mailing lists. A lot of that discussion ended up with people going in separate directions:

  • sticking to wireframing in graphics tools
  • doing full-on prototyping with heavier graphics tools
  • using some hybrid and manual approach: focus on ideation and then jump to building/prototyping in the medium of intended use (html, flash, etc.)
  • wireframing and prototyping purely with HTML (manually or using an MVC framework)

Mockups undercut the different approaches that evolved out of that time by focussing on one thing, suggesting that you don't need to do it all in one tool. Instead Mockups focuses on sketchy wireframing and at most, static click-throughs. I saw it as a logical evolution of tools like Denim, rather than a continuation of the process past wireframing. Your use of Mockups should end when UI decisions are selected, so you can build.

I was one of those people who clamored for a holy grail UI design and prototyping tool for designers. But looking back, I was the first to jump ship after trying different prototyping tools. They depended more on spending time learning to use the tools and less on producing more ideas.

I felt like there was a possibility of using these tools, but in all of my attempts, what worked for me was to build my own tool from frameworks to do HTML prototyping. That approach seemed fine, but in the end I abandoned it, because I found that I was faster at sketching and wireframing. It was back to pen, paper, and wireframes. Then Mockups came along.

I want to focus on ideas, not design artifacts. Can interactive design be demonstrated more effectively with interaction? That depends on a lot of things. I think the better question is, for exploring design ideas and finding the right solution, is interactive prototyping necessary?

Why we aren't designing Mockups for rich prototyping

We in no way underestimate the value of prototyping. We also do not want to go there with Mockups for now. I'm taking the time to explain why because I take this issue seriously, and I sympathize with the desire for interaction in the app. I also apologize because I know what I say doesn't get you what you're asking for, if you're asking for interaction right now. But I have to tell you, that once I gave up on the idea of being able to both wireframe and prototype in one tool, I felt more free as a designer, and am able to work faster and smarter.

Having used it for a few solid years now, I think we're doing the right thing in keeping rich interaction out for now. I don't think we're precluded from going there some day, but Peldi's vision is clear, I support it, and I agree with the reasoning behind it.

As an early user, I asked for interactive features because I was used to working in separate modes to design, specify, and prototype: sketching, wireframing, and building. I wished for a way to move more fluidly between each mode. What I never stopped to ask was, "why?" Why do I need interaction for exploring design ideas? The answer is that I don't. Now I strongly believe that having it all in one tool comes at a cost in terms of complexity. I don't want to incur that cost, and that's one good reason to keep Mockups from going there.

We believe Mockups is effective as it is because rough and simple sketches are great for generating ideas. We don't want to compromise the application with features outside of that main purpose.

More is less

With each new feature that is added below the surface of our application, the iceberg gets heavier. My main concern having used many complex prototyping tools out there was that if I didn't get it in 10-15 minutes of use, I had to read the manual. Once I had, I thought, "Why would I want to invest myself in doing this?" To me, it's bad enough that I can't just tell someone what to build by just sketching on paper.

Mockups cannot turn into a knob-heavy surface, like an airplane dashboard. Can we design it more elegantly to stick with the zen-like approach of working on one thing at a time that characterizes Mockups now? Probably. But now is not the time for us to even consider going down that path.

I've been told in certain situations, that interaction is the pitch. It depends on who the audience for the design document is. In some cases, I know it's hard to sell what people can't try or can't see. But for many people out there, there are ways to make that pitch creatively without compromising your project.

Will it benefit you for Mockups to become a heavier piece of software rather than a focussed experience? I don't think so. We have a vision to keep it as simple as possible now. We still have a long way to get there. We have bugs to kill, we have problems to fix. These, in my opinion are way higher up the list than demonstrating state changes at this phase of design communication.

This debate will go on, but that's what debates are for. In the end we want to build, and if we get to the end goal of making Mockups what we consider a polished tool and the ideal experience to match with the vision in Peldi's manifesto, I think we'll be in a better position to see where to go next.

Do what works for you

There are many ways to communicate design. There is no right or wrong way. We say, ignore anyone who says that your method is wrong. We've heard arguments on either side of the wireframe vs. prototype argument repeatedly. We won't try to sell you on our side, we'll just tell you what our opinion is, because we believe in it strongly.

We would never make absolute claims about what's right versus what's wrong. There is room in the world for many points of view. We think you need to do what works for you, and if your opinion differs from ours, we'll point you to software that fits with yours. We do have a strong point of view, however, that is based on the belief that early-stage ideation is effective at low-fidelity, and that is represented in our product.

Mike for the Balsamiq Team

Leave a Comment

Comments (15)

  1. Hi Mike
    Thanks for taking the time to explain your views.

    To answer your question. A recurring issue for me, as I partly explained before is that the way that data linkage is shown on screen has changed with drag and drop. It used to be the case that every record in a table had at least one column that was a drop down list from which only one element could be selected. Now we are increasingly dragging a record from one container to another instead of using drop downs.

    Or, I’m sure you remember having two lists side by side with an arrow either way in the middle and you moved things from one list to another by pressing those. That sort of thing we used to represent by design elements (the buttons) but now we use drag and drop we need to explain this in a different way.

    Looking to a solution …

    On paper mockups I agree with you very much but it took me some time to understand how you understood the click-through functionality of your product to work in relation to that. That’s because it appears on the face of it that the click-through prototypes are intended to demonstrate both the mechanism of interaction (i.e. the action of clicking) and the functionality of interaction (e.g. click here and this screen appears). It is finally clear to me that the click-through prototypes are *only* intended to demonstrate the functionality and not the mechanisms.

    Now that I understand I can suggest a way to look at your product that I hope will resolve some of your issues around this area.

    The way a lot of designers I know operate on paper is to take a set of coloured markers and draw the interactions on top of the content layout in front of the customer. In effect, adding the interaction layer on by hand. I used to do that on tracing paper years ago and then place it over the design.

    Conceptually you already have two layers to the mockups – the base layout and then the markup on top. It would help you a lot to think of the interactions as a third layer of visual explanation that you can switch on and off as you can with markup. This is basically what your option “Show linking hints” does in the export to PDF functionality.

    You’ve already got much of this with the ‘link’ property for symbols. If you added the ability to select the type of interaction (click/touch, swipe/drag, etc but not touch or mouse specific) when specifying a link and then represented those differently in the mockup then designers get to explain the interactions while maintaining a static mockup.

  2. Hi, Jay. Thanks so much for the feedback.

    It’s definitely not lost on us that the language of interaction is changing. But I don’t think this means the way one generates and documents an idea on paper changes in ways that drastically affect the medium. We made a conscious decision for this product to be closer to ways of capturing/demonstrating ideas on paper than to doing it in code. The analog for this would be sketching and paper prototyping, which is the point I try to explain, although maybe I failed to do it well enough.

    I think of what touch or kinetic gestures mean to communicating an idea mean if you’re working in paper. Do you need to change the medium to capture the idea? Maybe you come up with a new way of illustrating the language of interaction. I try to keep a list of the notations of interest to me here:

    I think that’s the right direction if the intent is to focus on getting the idea out and iterating on it, and not necessarily on demonstrating/prototyping it. That’s Mockups’ focus right now—low fidelity and speed. I totally understand the need for prototyping, but it’s not the problem we’re trying to solve. That said, we can do a better job of providing tools for annotation. As for the rest, we’ve still got many improvements to make to this product’s core experience.

    My question is, what are the needs you have that speak to the problems you experience wireframing interaction for products, particularly in the products that use touch gestures? It would be good to get detailed about examples like, how should i note “swipe to delete” in a wireframe versus a prototype.

    Related to this, there are a couple of Symbols for gesture notation:

  3. While I understand where you are coming from and support you in keeping a tightly focused product, it does appear that you are missing the fact that the language of interaction is changing. As a result, the way we understand interfaces is changing and the expectations of click-through prototypes are changing as clicking is no longer the only verb in town. For example, for many years the standard way in an interface to delete something was to press the ‘delete’ button. Now we are increasingly swiping the data element off the screen to indicate deletion. Another example is how data is categorised on a screen – for years this was indicated by a drop down list or radio buttons but now we are increasingly dragging the data element from one category area and dropping it into another. If you don’t support this new vocabulary in click-through prototypes then people end up using an old-fashioned vocabulary.

  4. I totally “get it”. I was in immediate need for a mockup tool and after just a bit of online research I settled on Balsamiq…didn’t even to a trial, I just bought it based on online comments. Very fast download and install and I hit the mark of being productive within about 10 minutes! It behaves just as expected. I remember the original Palm Pilot. It didn’t do all that much but what it did, it did very well.

  5. Hi, John. Depends on what you want to do to bridge the two. You could email us at to tell us more about what you’re looking for.

  6. I’m new to this, and just learning the tools, but what about linking use of Balsamic to create wireframes with use of Keynotopia to turn wireframes into high fidelity quasi-prototypes?

  7. @greg valentine: You may be interested in this blog post I wrote about sketching in mockups.

  8. Remember thumbnails. Sketches on paper or napkins to convey the idea or design. The difference with wireframes vs. mockups is content vs functionality.

    Wireframes display the design of content and structure. Prototypes simulate the design (content) via functionality.

    Design is first, presentation is second.

  9. Mike – I absolutely agree with your approach. In fact I believe that one of the reasons it would be so hard to create a single usable sketching and prototyping tool is simply because these are tasks that need to be done by different people.

    I’ve seen many debates on what skills a UI/UX designer should have but my experience has taught me that this is a team effort. Each member brings unique skills and experience. My tool is Mockups but my colleagues use graphics apps or development environments as their primary tools. Each of these people/apps play their part at the appropriate point in the design cycle. A simple tool allows you to focus on your ideas.

  10. @Yarone: Symbols will come eventually. We couldn’t imagine myBalsamiq without it.

    You could present with myBalsamiq using the Prototype view rather than PDF. I think it’s actually easier using that view than the PDF, if what you’re demonstrating is a web app or site, vs. a desktop application. You can also use fullscreen/presentation mode in the editor if that’s what you prefer.

  11. Mike – good to better understand the thinking process.

    I too like the simplicity of mockups. I personally don’t specify any interactions (aside from copying & pasting a mockup, overlaying a mouse pointer, and showing the next state) (P.S. – Wish MyBalsamiq had symbols…)

    I like to export all of the mockups as a single PDF. Then, I can go page-by-page through the PDF and show folks how the system will work. Screen by screen, state-by-state. (P.S. – MyBalsamiq made it really hard to do this.)

  12. @Glen Lipka & @Mike: I love linking my mockups together using links. That way there isn’t only one path to follow when there is more than one valid place to go.

    I also will leave notes when mocking up a particular feature so the person I am presenting to can interact with the mockup (or PDF export) himself while not getting distracted by other portions of the application that are not part of the particular mockup or feature.

  13. @Glen Lipka: Storyboards are easy enough to create, whether they’re created on a single canvas, using links to string together views, or exporting PNGs to present them in presentation software.


    Regarding re-use of components, you might want to try using Symbols.

  14. What about Storyboarding? I use PowerPoint to flow the viewer through the application slide by slide. This allows me to tell the story I want to tell about the interaction. It allows me to choose the level of fidelity I want. I usually animate a little mouse cursor to show where the user is clicking next. The downside is that there is no re-use of components or UI objects.

    I use Balsamiq for creating one-off pictures, but I think it would be cool to have the ability to have “slides” of balsamiq sketches and show those in a slideshow style.

    Just a thought.

  15. The simplicity of Mockups and its success are two variables that can not be ignored and must be very closely related.

    I wish I knew and thought more about simplicity a while ago. The next version of my product is mainly focused on simplicity. Sacrifices need to be made. 🙂