Responsive Web Design for Corporate UX Design

By Janet M. Six

Published: September 23, 2013

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our experts discuss responsive Web design within the context of corporate UX design.

Every month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: ask.uxmatters@uxmatters.com.

The following experts have contributed answers to this edition of Ask UXmatters:

  • Steven Hoober—Mobile Interaction Designer and Owner at 4ourth Mobile; author of Designing Mobile Interfaces; UXmatters columnist
  • Peter Hornsby—UX Consultant at Friends Life; UXmatters columnist
  • Bob Hotard—Lead eCommerce Web Design Architect at att.com; Technology and Production Chair, TEDxSanAntonio
  • Adrian Howard—Generalizing Specialist in Agile/UX

Q: Recently, we’ve seen an influx of rapid design tools, the birth of the mobile-first strategy, and the growth of responsive Web design (RWD), which by its nature, simplifies content, layout, and overall user flows. On the other hand, communicating that RWD concept to stakeholders becomes a little more complex when a site shifts to a larger breakpoint. How is RWD changing the approach to corporate UX design?—from a UXmatters reader

“When you already have a traditional desktop design in production, you really have to take the approach of reconstructing each module, page, or application flow with RWD.”—Bob Hotard

“I think everyone understands the concept of starting with a mobile design—a small screen, simple interactions, and less content,” answers Bob. “But when you already have a traditional desktop design in production, you really have to take the approach of reconstructing each module, page, or application flow with RWD. Ask yourself, How would I reinvent this page if I were designing it for the first time for a mobile device? That will put you in right mindset.

“I’ve heard designers describe this frame of mind as mobile up, not desktop down. It forces you to ask the basic questions that, as designers, we always want our business partners to ask: What is the single purpose of the page? What is the primary content, and how should you prioritize the content?

“In this context, product owners immediately get the picture of straightforward content, simple interactions, and clean visuals.”—Bob Hotard

Since attending Luke Wroblewski’s ‘Mobile First’ workshop, I now ask: What is your 1, 2, 3? When I show product owners a block wireframe of the teeny, tiny iPhone screen, they usually see right away that, for example, only 1 and part of 2 will initially be visible, and 3 after a swipe—and that’s okay. This demonstration hits home. I have found that, in this context, product owners immediately get the picture of straightforward content, simple interactions, and clean visuals. Then it becomes much easier to communicate, illustrate, and demo the expansion of a tablet breakpoint, and finally, a fluid, adaptable desktop version. But creative is only part of the plan.

“I recently tweeted, ‘If you’re in corporate Web design and considering converting to RWD, get ready for future shock,’” continues Bob. “RWD is forcing all of us in the corporate arena to look at our design process, our deliverables, and how we interact with developers, testers, and release management. If your company’s response is ‘Oh great! Now we have to create three wireframes, comps, and content documents for every page.’ they’re missing the boat—and unfortunately, it’s a speed boat with a wide turn radius. It would be wise to consider modifying your creative process as well as your development and testing methods. It really is a culture shift, and it is all for the good. But as with all change, this is rarely easy, and people may not be ready to embrace it.”

A Paradigm Shift

“In the current era of multiple devices, people understand that you can’t present the same content in the same way on every display.”—Adrian Howard

“RWD has put the final nail in the coffin of one of the most pernicious misconceptions of Web design—the pixel-perfect Web site,” replies Adrian. “In the current era of multiple devices, people understand that you can’t present the same content in the same way on every display. RWD gives us a relatively simple way to attack the problem without developing n different device-specific Web sites.

“RWD is certainly not a panacea, but I have found that it can remove much of the fear of dealing with our new cross-channel world. The growth of RWD frameworks, design patterns, and tools means that people are finally accepting that a Web site can look different depending on the context.”

Connecting the Design with the Brand

“For the corporate types—who are just now migrating to the concept of multi-channel support and considering responsive and adaptive principles—RWD doesn’t necessarily make things easier.”—Steven Hoober

“I am not at all sure that RWD simplifies either content or layout—and certainly not flow,” asserts Steven, “But let’s talk about the first of these. At least for the corporate types—who are just now migrating to the concept of multi-channel support and considering responsive and adaptive principles—RWD doesn’t necessarily make things easier. The most important part of adapting experiences is not the responsive-centric focus on screen size and breakpoints, but making sure functionality and content is similar across every touchpoint. A typical, old-line corporate client has what amounts to functionality and content in paper and CD catalogs, on signs, in desktop applications, on installed hardware and its dedicated software, in internal databases, on intranets, in billing systems and bill stuffers, and a dozen other touchpoints. 

“Just upgrading from a desktop-only Web site to a responsive design is barely moving the needle. Really driving change and bringing a company into the 21st century requires looking hard at what its brand means and what customer interactions will be like in the near future. More often than not, I derive the content for new designs and new systems—like a mobile-friendly Web site—from those antiquated paper- or CD-based systems. Sometimes it’s good content, but often it’s just what is there now and what a good mobile or tablet experience will replace.”

The One-Web Approach

“Responsive Web design is just one approach to what the W3C calls a One-Web Approach, where the same information and services are available to users irrespective of the device they are using.”—Peter Hornsby

“Responsive Web design is just one approach to what the W3C calls a One-Web Approach, where the same information and services are available to users irrespective of the device they are using,” responds Peter. “Other popular approaches include adaptive Web design and server-side adaptive designs. Igor Faletski gives a good overview of the strengths and weaknesses of each approach in the webmonkey article, “The Two Flavors of a One-Web Approach: Responsive vs. Adaptive.’ Designing for the One Web doesn’t inherently simplify anything: you need to design to take advantage of it!

“Taking a One-Web approach for corporate site design is usually a good idea, but you should dig around a bit to ensure that it works in your case. If the site you’re designing will have little or no usage on mobile phones, consider designing down to tablet level. Designing for the One Web simplifies the design that the user sees, but complicates the testing and design processes.

“The challenge of designing for the One Web is twofold,” concludes Peter. “The communication challenge you’ve already picked up on. First, many stakeholders don’t know about the need to design specifically for mobile devices. They see Web sites working well on their mobile devices without understanding the design work that has gone into it. Second, if you can agree that One Web is strategically important for the organization—and most of the time, it is—you can leverage this overall goal in reworking your content and functionality.

“Many corporate Web sites are the outcome of debates between competing stakeholders, leading to the need to manage the opinions of the highest-paid people (HIPPOs).”—Peter Hornsby

“Many corporate Web sites are the outcome of debates between competing stakeholders, leading to the need to manage the opinions of the highest-paid people (HIPPOs). For further discussion of this point, see “Tips for Handling a HIPPO (Highest-Paid Person’s Opinion).’ In a best-case scenario, you can use the need to design for the One Web to push for greater focus within the organization. Get people to understand what the key design focus should be, under the umbrella objective of supporting users on mobile devices.”

6 Comments

I have to admit I’m pretty confused about what RWD is in relation to UX. Isn’t it about how things are built rather than what gets built? We may as well be talking about whether we should using PHP.

So, from the above panel, I still don’t really see what, from a UX—as opposed to a technical / coding—point of view, is bad about maintaining separate designs for a series of device viewports or resolutions? Indeed is there even an alternative to that situation?

I can’t see what it is about RWD that makes any difference to the UX of a product at all.

re: Mr. Hotard’s comment: “Ask yourself, How would I reinvent this page if I were designing it for the first time for a mobile device?”

I completely disagree! It’s not about the device, it’s about what the user needs to do with it. If you have an existing, traditional desktop design in production, any design change for mobile would have to include a change in the user’s workflow first. The actual layout, RWD or otherwise, would follow from that.

Comments, so far, are right on—that it’s about user context. Not just the traditional—and so much derided—environmental context, but user expectations, and also how user behavior varies based on the device they use. This is probably not because of the device, but the device they choose implies their state of mind and availability of attention.

To a certain degree, therefore, we should be talking more about adaptive than responsive design. Adaptive is, I think, the best way to summarize the broader issues at play—of feature availability, of content being suitable for all platforms, of multichannel task planning, or of thinking not about desktop or mobile first, but users first.

Articles like this are similar to questions I get three times a week from clients. RWD has mindshare. Sure, it’s often the wrong choice or a limited first choice, but at least it begins the conversation about how all of the digital properties—at least on the Web—can work efficiently and properly. Sometimes it ends up being a pretty lame RWD-only solution, but sometimes it’s all about device detection or the decision is to create separate sites or to differentiate what’s on the Web from what gets pushed to an installable app.

If I missed something, tell me about it, and I’ll try again.

Gary,

Thanks for your comment. I agree with part of your comment: “Any design change,” … especially a migration or merge to mobile, should include a change in the user’s workflow. I am a big advocate and champion of user-level flow diagrams—and doing those first.

I think you may have taken the word device a little too literally. I was pointing out that marketing or business stakeholders usually don’t get mobile until they see that all their content has to fit and be usable and understandable on a screen that is 2” x 2.25” before a swipe. That is Web design future shock to them.

RWD helps to bridge that gap from a page that seems oversimplified on a small screen to one that translates nicely to a large screen. A design that should meet the user’s needs and, of course, in the corporate world, achieve the business goals as well. As Adrian Howard states: “RWD gives us a relatively simple way to attack the problem without developing n different device-specific Web sites.” Couldn’t agree more.

Interesting to read Steven’s response suggesting we should be talking about adaptive rather than responsive. Any chance of more detail on the differences?

Carl

Hello Bob H.

A treat to see you as a contributor to this discussion. (I’ve worked with Bob.)

There are bits and pieces that I agree with that all contributors have made here. There are several points that were made that I’ve had to address as the Principal Information Architect for Turner. RWD is something that has been a hot topic for TNT/TBS/TCM. We’re working on it. As both a UX professional and an IA, I cannot merely philosophize on the best mobile-first or mobile-up strategy, but must examine our user types, how they use our site, what tasks are most common, consider where we are—and where we are going—and devise a solution that will work for today and get us many steps closer to where we need to be in the future.

I would like to second Steve’s observation, “The most important part of adapting experiences is not the responsive-centric focus on screen size and breakpoints, but making sure functionality and content is similar across every touchpoint.”

There should be an effort to make the content and functionality consistent, but there also needs to be a framework in place to support it. I feel it is our job to help developers understand how to implement breakpoints and presentation layers. As PPI screens in smartphones—such as the Samsung Galaxy 4S Active—rival the resolutions of desktop displays, we must ensure that the philosophy behind RWD is, in fact, implemented correctly. I’ve created a 5-step process for implementing RWD: e1a1692df14e534b1669cd60f950f60d

As others have stated, we must examine our design process and how functionality will work across all presentation-layer derivatives. I’ve created a deck (not included) that is highly illustrative and visually conveys how the grid system works, the breaks, the elasticity of the grid system, template usage, containers within those templates, and components/modules within the containers.

While examining this approach, it is important not to lose sight of the congruence between functionality and content. I think Steven hit the nail on the head with his observations.

Arondale Withers

Principal IA at Turner Broadcasting

Join the Discussion

Asterisks (*) indicate required information.