Responsive Web Design and Interaction Prototyping

Interaction Explorer in Indigo StudioAs 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.

Intersection: User + Context + Device Class

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.

Comments  (4 )

Guillaume Khayat
on Fri, Feb 15 2013 6:15 AM

I think you're missing an important point.

RWD — or at least Fluid Layouts — enable me as a designer to make prototypes that scale to my clients and users' device screen width. This in itself is a pretty huge deal since it makes it possible for a lot more people to try my designs and focus on the UX instead of zooming in/out constantly to have my designs match their screen size.

Ambrose Little
on Fri, Feb 15 2013 8:28 AM

Hi Guillaume,

I think I understand where you're coming from. But I guess my response would be 1) that if you're doing mobile first, then you don't have people having to zoom in and out to review your design, 2) that for the purpose of interaction prototyping, it is faster to quickly clone and relayout the prototype for the different device classes (which you can then send to your client, e.g., 'this one is for phone', 'this one for tablet', etc.), and 3) the focus ideally would be more on users and testing with users, so you would test the appropriate prototype with them.

Indigo Studio Blog
on Fri, Apr 5 2013 9:04 PM

So you've been using Indigo Studio for a while now, and you're thinking, " Wouldn't

Nicholas McClay
on Thu, Aug 14 2014 11:02 AM

Thanks for the great article about the challenges with using RWD for interaction prototyping.  I think you've persuaded me that what I'm looking for in Indigo Studio isn't so much RWD support but multiple display contexts with a given screen.  Currently in my mobile projects I have to provide at a minimum guidance for phone and tablet variations across both iOS and Android.  These contexts often highly reuse the same UI and interaction states with some slight layout variation or different platform affordances.  What would be optimal is to be able to define a given screen in one place, and simply have a toggle to choose what context I want to look at that given screen/state in, then just make the adjustments.  The alternative to this is what you suggest above by using a top level state context selector.  My problem with that though is that once you get into a screen with a couple layers of interaction you are making my life a pain to manage all those 'parallel' states downstream that are just a layout variations of a state in another context.  Or you end up doing what I'm currently doing which is having 4 different Indigo Projects for managing the design for what is essentially the same app across 2 platforms and 4 (or more) display sizes.

My wish would be that you could make creating and managing these different display contexts in Indigo for a given screen and its associated states with as little rework as possible.  I know that's a daunting ask, but I think there are ways it could be done, for example maybe having a context selector in the screen interactions overview that lets me easily control what states are applicable to different contexts and adding new states for contexts that need them.  The end goal should be to limit the amount of rework necessary to deliver consistent prototypes for different display contexts of the same application screen and state.

Hope that helps!