First, a couple of definitions. Responsive design, one of the biggest recent trends in web design, is the use of proportional, fluid layouts that adapt and fit perfectly to any screen of any size. Adaptive design, sometimes thought of as a precursor to responsive design, typically makes use of set breakpoints to determine the best version of a design to show based on the size of the screen and the assumed capabilities of the device. Responsive designs frequently make use of breakpoints, but adaptive designs usually lack fluidity.
To put it bluntly, responsive design isn’t possible in Axure RP. Responsive design is predicated on fluid grids and dynamically resizable elements. But in order to function as an effective and predictable prototyping platform, Axure RP depends on exact calculations for size, spacing, and arrangement of elements in the design. To maintain this precision and as much user-friendliness as possible, Axure RP handles breakpoints adaptively, rather than responsively.
Still, you can use Axure RP to plan for responsive design, using adaptive views. This allows you to create set breakpoints that will change the layout and content of your page depending on the width of the viewing window. Some people assume that this means Axure RP can only be utilized for adaptive design, but that’s not necessarily the case. In a comparative article for Smashing Magazine, Christian Holst argues that adaptive design principles can actually be more effective and more easily implemented in testing and development than responsive ones. Why’s that? In short, adaptive views are extremely predictable. They allow you to plan for a set number of screen sizes, and hence potential changes to your design, while starting responsively forces you to plan for every imaginable screen configuration. On top of that, you’re likely to incorporate fixed breakpoints in your responsive design already—4 columns of content compressing to 3, a navigation bar scaling down to a hamburger menu, etc. Prototyping with adaptive principles allows you to communicate those changes simply, effectively, and predictably.
As an example, consider the homepage for the clothing brand Patagonia, which, I should point out, was not necessarily built in Axure RP. This is a (mostly) responsive website with a navigation header that perfectly fills the width of the browser window. To account for different window widths that are likely to be encountered on desktops/laptops, elements of the header change so that things don’t get too crowded. The search bar is elastic throughout, and in a very narrow range of screen sizes is condensed into a magnifying glass that reveals a text field when hovered over. As the window continues to shrink, the “Inside Patagonia” link and live chat, support, and account icons get compressed into a hamburger icon to save space. Throughout these changes, the search bar adapts fluidly, either resizing, recentering, or both. Finally, at 767 pixels and under, the entire page shifts to a mobile-oriented design that fluidly adapts to the size of the window.
So how does adaptive design help us here? By defining each breakpoint—the base design wherein all header elements are visible, the points at which various elements shrink or expand, and the the point at which we get a mobile view—we can design around the changes to the interface without worrying about every per-pixel shift. I’ve put together an example, modeled after the Patagonia site, based on these breakpoints to illustrate the utility of adaptive design in the prototyping process.
With that in mind, here’s what a hypothetical prototype for patagonia.com, built in Axure RP, might look like. My hope is that this helps to illustrate the utility of adaptive views in communicating ideas for what will eventually become a responsive final product. Thanks for reading!
