Buzzword Takedown: Responsive Design

The difference between a responsive site and “non-” is that a responsive site reconfigures it’s user interface to “fit” the screen it is shown on. Consider a 3-column layout web page that has been built in a “responsive” way.  On a desktop browser it shows full width, with all 3-columns. On a mobile phone, it will automatically configure itself to show the 3 columns stacked on top of each other, so that the columns can display wide enough to be easily read.

For more on responsive, see: alistapart.com/article/responsive-web-design

Now, of course, every project is different, and the way we apply this design approach to different sets of user requirements is dependent on several factors, including (bullet list!):

• User need. How many of the users are on tablets and smartphones at the times they will access the site?  If the answer is “a lot” responsive design (RD) should be considered.  If the answer is, “sometimes,” then maybe a mobile-tested site that will function on various devices–even if it does not support the kind of automatic re-arranging I described above–is going to work out fine.

• Content. Some content lends itself better to RD approaches than others.  For example, a site that serves up a lot of PDF files is not a great candidate for RD because PDF files are meant to display the same way everywhere and they cannot be made to fit the various breakpoints your RD strategy calls for.  A site like a blog that already works well in a 1-column display might benefit from RD, or it might not.  A news portal with a 3-column homepage and lots of big, heavy photos almost has to include an RD approach to it’s interface, or mobile users might go away frustrated.

• Cost. The effort that goes intobuilding a website that supports RD is a bit more than building one that does not, becausethat automatic rearranging is done with web development technologies that are implemented by a programmer.  If the front end of the site must be flexible to accommodate requirements for RD, then that guy has more work to do to accommodate the different displays.  Not an order of magnitude more dev, but more dev. As for testing, we usually plan to test websites on a list of devices whether the site is RD or not, so QA testing can often remain pretty stable price-wise, unless the device list grows.

What this means to us as we build websites to an RD specification is that we know we have a responsibility to give mobile and tablet users an experience equal to that of the desktop user, and this is a tall order. It means our UX and UI design will account for RD by minimizing certain elements, like large photographic backgrounds, and leaning more on others, like using code more than images to give the pages color and style.  There is a whole mindset we must bring to an RD project that is a bit different.

Responsive Design is also a buzzword, co-opting would-be consequential conversations across our fair land. So we have to ask: Is it worth it?

Sometimes it really is.  Tech-savvy users, who spend half of their days pecking at iPhone apps (like my kids, or maybe like you), expect their stuff to function a certain way, and may perceive it as “chintzy” or even “broken” if their mobile experience is interrupted by having to zoom and scrollaround a screen to hunt for what they need. Fair enough! In some contexts, though, RD might be overkill. For example it is easy to imagine a situation where a less mobile-tech-savvy user just needs to grab some information, urgently, and is glad to have mobile access to it at all.

Frequency of mobile use, appropriate content, and a business case to expend the effort for RD are all important factors in this decision, and we can help you determine what’s right for you.