Whyyy Are You Still Designing With Static Wireframes?!?

Why?? Seriously. Interaction prototyping is so much more effective.

Honestly, it's a little baffling to me when I see the disconnect between theory and practice in UX/interaction design when it comes to wireframes and prototyping. For all our talk about "interaction design," we seem amazingly complacent when it comes to actually designing interactions.

"Oh, you need a design? Let me churn out a static wireframe of that UI." Then we hand off this dead artifact, all the time waving our arms about, gesticulating that "when the user clicks that, then fade/slide in a dialog box just below it," whipping out the next static UI that shows the aforesaid dialog box already in place. No interaction is in the design. No transition. Just a magical this state ergo that state.

Then a dev implements it, and we're like, "nooo.. no.. that's not right, fade and slide at the same time. Try like, I dunno, 200ms or something." And we iterate back and forth, burning not just our time but also the devs. Then it's implemented, but we still need to test it after implementation, despite the fact we know this isn't a good time to be testing because it could imply more changes and iterations with dev. And that's assuming there is time and we don't just have to cross our fingers and hope we can fix it later.

Such an approach may all be very Agile or Lean, but it's still wasteful. And that's assuming we even have the luxury for this kind of iteration with devs. What about those all-too-common situations where we simply have to toss a batch of wireframes with annotations over the wall and hope, only to cringe at the implementation some time later when we see it, when further changes and iterations are not possible? "I guess I won't put that one in my portfolio…"

These are the hidden costs of being complacent in interaction design and settling for simply doing static wireframes. Sometimes it is time spent burning multiple wicks when one could do. Sometimes it is that the design just doesn't get done right because 1) the devs ran out of time to iterate further, 2) we didn't have a chance to iterate with them, or 3) we never even got to evaluate the interactions with users.

"But but but!" you say, "we can do paper prototypes with our static wireframes!"

So wait, let me get this straight. You're going to spend time designing software on a computer, and then you're going to print that out onto paper, cut it up, organize it all neatly, and then pretend you're the computer? (Or you're going to spend a lot of time hand drawing, copying, cutting, and organizing?) All the while asking people to imagine what they are interacting with is software, and that while you're struggling to find and place the right static representation in front of them, they should just imagine there's a spinning beach ball or donut because the "computer" is thinking? Really?

Okay. Sure. Paper prototyping is like a bagillion times better than not evaluating your designs with users at all, or just showing them pictures and asking them where they'd click. It's better than waiting until you have the software implemented and hoping you have time to change based on what you will discover in your evaluations.

But at the end of the day, paper prototyping is still a hack. You can only get so much meaningful evaluation out of them. We have to face it--it just ain't the real thing. And no amount of consensual hallucinating is going to make that better.

No, if you're doing interaction design for software, you should be able to design actual interactions in software and evaluate actual interactions in software. You should be able to design transitions, especially these days when small changes to a UI are much more common, and when often you can significantly impact the effectiveness of the design with transitions, various kinds of animations to help users along. This is what interaction prototyping is all about.

Most of us know this. Most of us know the value of real, interaction prototyping. But we've grown complacent for any number of reasons. Maybe when we learned how to do interaction design (or UX, or IA, or HCI, or whatever), the tools just weren't there. Maybe what we were designing for didn't really support much in the way of interactions anyways--it was just monolithic slabs of state->state->state pounding one on top of the other. Or maybe we've used tools that seem to slow us down and require too much investment to learn, to use, and to iterate with. So we stick with what we know, what we feel we are fast with (usually only because we've invested many hours becoming masters of our less capable tools).

Maybe we think that the best or only way to do software prototyping is with code, but we don't want to learn to code. Maybe we have good reasons for not wanting to code for interaction prototypes. Some certainly advocate for prototyping with code, suggesting that code is our medium.

But code is not our medium. Code is just one way to tell a computer to do what you want, a pretty primitive and fairly inefficient (albeit very powerful and flexible) way. Our medium, well one of them anyways, is software, that malleable, polymorphous stuff that lives on the hardware. Reduce it down; it is just a bunch of instructions flipping binary switches over which we have layered abstraction upon abstraction. So it is somewhat arbitrary to say that this one layer of abstraction (e.g., HTML, JavaScript, CSS, XAML, etc.) is the medium, the one that we should use to mould the electrons to our will.

Now I'm not ignoring that there are arguments to be made at times for dropping to this level of abstraction, and I would not get in your way if truly it was the most effective and efficient way to sketch prototypes for your interaction design problem. But as a rule, you shouldn't have to go there, at least not first.

And it was precisely this "it should be better" thinking that led us to begin work on what became Indigo Studio. There should be a way to quickly, rapidly sketch prototypes. You shouldn't have to learn to code to do it. You shouldn't have to think in code to do it. You shouldn't have to settle for pretending to be a piece of software when you could literally design a piece of software as software, faster and easier than doing a paper prototype, and evaluate that real piece of software. You shouldn't have to settle for spending a bunch of time designing dead artifacts and then having to imagine what they'll be like when they're alive, forcing others to imagine the same based on added words and gesturing, and hoping everyone comes away with the same idea of what it will be like.

In the end, prototyping is better than wireframing for the same, essential reason that wireframing is better than verbal functional specifications--it's that much closer to being the real thing and thus requires that much less (often wrong) imagination on everyone's part. With Indigo Studio, we made designing interactions to sketch prototypes the central idea so that we, you--nobody who is responsible for designing software UIs--would have to settle any longer. We no longer have much excuse to be complacent and settle for static wireframes in interaction design. We know better, and now we can do better.

 

About Indigo Studio

If you haven’t already, why not Go Do Better! with Indigo Studio. Version 1 is free forever.

If you are using Indigo, we welcome your ideas on how we can better apply and refine these and other good interaction design principles to help you to design awesome UIs. If you have any questions or problems, please don’t hesitate to discuss them with us in our forums. We’re also on Twitter @indigodesigned.

About the Author

Ambrose Little is principal design technologist at Infragistics and has worked on Indigo Studio as interaction designer and product manager along with an awesome team based here in Cranbury, NJ, USA and Montevideo, Uruguay.