Pattern Translations

June 30th, 2012

We are accustomed to the phrase “design patterns” which encompasses an established solution to a design problem consisting of purpose, function and appearance. There are lots of libraries cataloging these solutions to help designers and developers make sensible decisions when designing and building a product.

Two years ago Ethan Marcotte introduced Responsive Web Design, which has become the biggest movement on the web since The Web Standards movement. With Responsive Web Design we changed the way we make websites, our tools remain largely the same but our approach is different.

At a component level I believe we are still learning the ropes. A design pattern established for one device may not translate so well for another. It’s easy when designing and building responsively to ignore design pattern functionality problems lost in translation and concentrate solely on layout issues. For example a large multicolumn dropdown built for navigating multiple sections within a site may provide a good user experience on a desktop machine - it may translate poorly on smaller screens and harm the user experience.

Another example would be the lightbox design pattern. The purpose of a lightbox is to display a larger image corresponding to the selected thumbnail version while keeping the user on the same page instead of linking directly to a page showing the full image. Again, there are an abundance of solutions for solving this problem but the vast majority of existing patterns translate poorly to smaller displays. In fact you may argue that a lightbox shouldn’t even exist on small displays, the image may already be displayed at full width, and where do you go from there on a narrow viewport? These are the questions we need to ask ourselves when translating design patterns across devices and viewports.

We should challenge our current arsenal of patterns, ask difficult questions of them - how will this work on a narrow screen? On a huge screen? A TV? A touch screen? For a user with low bandwidth? I try to ask these questions at the wireframing stage so I can quickly test what works and what doesn’t, then refine and iterate. Even with a Mobile First mentality I found that you still need foresight to cover all eventualities - planning, documenting¹ and getting sign-off on your pattern behaviours pays off so you have a reference for testing and controlling project scope.

We are dealing with an entirely different beast in that we are building experiences that users will be touching with their bare hands - there is nothing between them and the interface. We need to ensure our tried and tested design patterns translate appropriately for all scenarios so that we can build a new library of responsive patterns that will assist us in making great things for the web. Don’t be afraid to hack or invent, re-invent and re-invent again.