Responsive Web Design and Interaction Prototyping

As the product manager for Indigo Studio, I get to keep an eye on what people are talking about in terms of interaction design and, especially, prototyping for interaction design, what I like to call interaction prototyping. You see, Indigo Studio is an interaction design tool. A key focus for it, then, is prototyping interactions, above and beyond static wireframing (although it can of course do static wireframing better than many wireframing tools, if that's your thing).

Because of this, it's important for Indigo Studio to address new hot topics like responsive Web design when they come up, understanding how they pertain to interaction design and, consequently, a tool that specifically targets interaction design activities. To that end, the other day I opined on responsive Web design's relationship to interaction design/UX at a more conceptual level. The tl;dr is essentially that responsive Web design (RWD) is not really of particular interest to interaction design because it is more of an implementation technique than a design activity. In this post, I'll scope it a little more specifically to interaction prototyping.

Is There Value in RWD for Interaction Prototyping?
Because interaction prototyping is by definition prototyping that is concerned with interaction design/UX, RWD's applicability to interaction prototyping is similarly limited. What is odd to me, though, is that I've seen some folks here and there on the interwebs saying that one of the key benefits of prototyping in code (namely HTML, CSS, and JavaScript) is that it inherently supports RWD. But RWD is not really that pertinent or valuable for interaction prototyping. It only explores the one, generic, context-and-user agnostic question of how a layout changes across a multiplicity of devices.

It does not consider who your users are.

It does not explore what their desires are.

It does not explore their contexts.

It doesn't even help you understand what a good design would be for them using a given device or device class. It simply offers a technique to reflow content ("responsively").

What's Important for Interaction Prototyping
What's important for interaction prototyping--for interaction design--is not that your layout fluidly changes during resize--but rather what the experience of your design will be for your users on their devices in their contexts. You don't need RWD to explore that.

Let's be a little more concrete:

• What is your users' experience of your design for a smartphone?  
• What is your users' experience of your design for a tablet?
• What is your users' experience of your design on a desktop/laptop?

These are things you can test with a prototype, ideally with actual users in their actual contexts. To explore these, you don't need to worry about busting out your rockin HTML & CSS skillz. You need, rather, to as quickly and cheaply--as throwawayly--as possible bang out prototypes that optimize for each applicable context of use/device class.

The Challenges of RWD for Interaction Prototyping
Let me say that again: optimize for each applicable context of use/device class. One of the problems with assuming RWD as a starting point is that you are artificially boxing yourself into the constraint that there will only be one implementation that tries to serve every context of use on every device. You need to evaluate that assumption before deciding to use RWD. If you start your evaluations within an RWD framework, you are short-circuiting that important step and, quite possibly, not designing for optimal experiences for your users' contexts of use with any given device class.

RWD also assumes that each context of use/device class is equally important to your users. That is another assumption that you need to evaluate with users. What if you found that your users almost exclusively want to use your design on their phones? Surely you should then spend more time optimizing the phone experience than the desktop? But if you start from RWD, you may artificially (and sub-optimally) constrain your design choices so that there is only this one solution for all.

Another challenge pertains to the difficulty of both prototyping and later implementing a one-size-fits all solution. As a sometime software developer and architect, I am well-acquainted with the inherent challenges in a one-size-fits all approach to design. Superficially, it sounds more feasible and maintainable on the surface, but you inevitably discover conflicting design forces that make you end up coding your solution all into knots such that it ends up taking more time to create, has more issues, and is more difficult to further customize/change. All this technical debt accretes so that in the end you shy away from optimizing due to the cost involved, and you end up with sub-optimal experiences across all along with the increased maintenance burden. This is what we call overengineering. Beware the "one ring to rule them all" mantra--it really is usually evil. ;)

All that's not to say that RWD is never the right solution. But that's the point--you can and should use interaction prototyping to, among other things, evaluate if RWD will work well for your project. If you find that the optimal designs you discovered for each device class are compatible enough, then you can make the implementation technique choice to use RWD. This is properly putting the cart behind the horse.

Interaction Prototyping for User-Context-Device Class Intersections
So it turns out, you don't really need RWD as such for interaction prototyping, and in fact it can be detrimental. Rather, what you need is to cheaply evaluate designs for user-context-device class intersections (we'll just call these "intersections" from here on out). Most software prototyping tools should support this in one way or another. The simplest and most straightforward way (and possibly the best way for interaction prototyping) is to just create separate prototypes for each intersection. This doesn't have to be as costly as it sounds--if you're finding it too costly, you're probably either putting too many unimportant details into your prototypes or you're over thinking how many intersections you need to test.

First off, do some design research. If you discover that phone contexts are your most important contexts, spend the most time exploring phone designs first. Then you can take what you learned from that and apply it to your other intersections of interest (for example, tablet and desktop). This way you don't have to relearn the same things across all of your prototypes and can instead hone in on the specific things you need to learn that apply to specific intersections.

In Indigo Studio today (V1), there are a few ways to evaluate designs for different form factors. I would recommend the approach just outlined--start with your primary intersection (or pick one--phone's a good default if you don't know) and prototype it first.

Once you've generated alternatives, explored, and synthesized to find what seems to be optimal for your primary intersection, move on to the next most important one, applying what you learned from the first intersection but trying not to bias too much towards your first design (remember the point of this exercise is to discover optimal designs for the various intersections). But a lot of what you learned about your users, their desires, and your design should transfer well.

With Indigo, we've endeavored to make prototyping fast, cheap, and as throw-awayable as possible, so none of this should take you a long time. Stay focused on your known stories and don't get distracted by too many what-ifs (just write those down as they come up, but table them until you get done with your primary/critical path stories). You should be able to bang out most prototypes like this in a relatively short amount of time. The goal of interaction prototyping at this stage is not full on app simulation.

Also, don't jump to "pixel perfect" or even "content perfect" right away. The goal with interaction prototyping is not to impress people. Yes, you need to think about information hierarchy. Yes you ideally have realistic content, but don't get sucked into making it perfect at this point. Just make it real enough to evaluate. If you err on the side of too little realism, you save time, and you'll learn in evaluating the prototype where you actually do need more realism (versus what you imagine you need beforehand). Also, sticking to your stories here helps, too--if it is crucial to your flow, make it realer; if not, quick faking is ok.

The driving principle is always to only invest just enough so that you can move on to other alternatives and/or quickly evaluate, learn, and iterate. RWD comes later, if it comes at all. Whether or not it applies is one thing you will learn from this.

If You Do Want to Do RWD in Indigo...

UPDATE (15 October 2014) - Due to popular demand, as of Version 4, Indigo Studio now has direct support for RWD.

UPDATE (9 Mar 2013) - I just ran across this case study that illustrates some of the problems with starting from RWD as the assumed implementation. Specifically, they discovered two key points that I highlighted above:

• They did not initially take the time to research their users/what they need/want and how they want to use their app (contexts).
• It (artificially) constrained their designs and prevented them from optimizing it for their users' primary contexts.

About Indigo Studio for Interaction Prototyping

Don't have Indigo Studio? Download a free 30-day trial which will let you try all of the prototyping goodness.

Download Indigo Studio

Looking to suggest improvements and new ideas for Indigo Studio?

Submit a new idea

If for some reason you are having trouble with Indigo Studio, check out our help topics, forums or contact support.

Get Support

Follow us 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.