Balsamiq

Why We Aren't Doing Interaction in Mockups

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.