Device Classes & Responsive Design

by Luke Wroblewski January 17, 2011

While the task of designing for multiple devices can be daunting, two techniques can help make the process more manageable: defining device classes and designing/building responsively for devices within each class. Here are some of my initial thoughts on how these two techniques can work together...

Device Classes

Device classes are defined by unique customer needs that stem from the context within which a device is used and the technical capabilities or limitations a device possesses. Today, for instance, I consider five unique devices classes when designing Web applications: connected TVs, desktops/laptops, tablets, smart phones, and feature phones.

Each of these device classes has a unique:

  • Context of use: 10 foot lean-back experience on the couch, long periods of use at a desk, casual couch/bed use, or quick bursts of activity in various locations throughout the day
  • Primary input method: remote/gestures, mouse/keyboard, touch/sensors, or keypads
  • Average display size: wall-sized, desk-sized, lap-sized, palm-sized, or thumb-sized
  • And more...

As a result, each device class typically requires a unique user interface design solution. The relative importance of primary tasks will differ across devices classes (because of context of use), as will the layout and interaction design needed to accommodate different input methods and average display sizes.

While it’s possible to have a single user interface work across more than one device class, developing a single interface that works across all device classes usually results in significant compromises or bare-bones experiences that don’t take advantage of what makes each device class excel (or conversely, rich experiences that fail to load/work on lower end devices).

So while a connected TV could browse a text-list optimized for feature phones, it is unlikely anyone would want to. On the other hand, a tablet-optimized Web application might feel simpler to use on a desktop Web browser because the number of actions has been reduced to work on a smaller display size and the size of the actions has been increased to accommodate touch interactions. While this interface wouldn’t be optimized for a desktop computer’s context of use, input methods, or display sizes -it would be pretty functional.

I should also note that not all Web applications make sense on all device classes. When designing for multiple devices, you first need know which classes you are targeting and why/how. From there, you can begin designing.

Responsive Design

Within any device class, there’s still a lot of variation -especially in display sizes. Connected TVs, laptops, desktops, tablets, smart phones, and feature phones all come in a variety of screen resolutions, densities, and aspect ratios. But don’t worry... responsive design can help.

Responsive design allows you to fill in the blanks within devices classes through the application of fluid grids, flexible images, and (where possible) media queries. So once you have a context-optimized smart phone solution, the difference between a 320x480 screen and a 480x854 screen is covered by responsive design and a few simple rules of adaptation like adding additional rows, increasing image sizes, and the like.

Some Web sites can even use responsive design to deliver a single solution across a few device classes. Sites that consist mostly of simple content might be able to apply a responsive solution across smart phones, tablets, and desktops/laptops assuming there’s no difference in use based on context and that the site’s media assets are minimal (i.e. they can be downloaded over slow network connections).

With a set of interface solutions optimized for an appropriate set of device classes and responsive design, all of your Web applications URLs can resolve to an optimal experience for your customers online –no matter how they get there.