I often feel jealous of my iOS colleagues. How nice it must be, I think, to have a mere two set of screen resolutions to design for (four if we’re counting retina displays). How nice to have only two aspect ratios to worry about. It must be pleasant to always know exactly how tall the status bar is, and how much space to reserve for the navigation bar.  We Android developers are used to living in a messier world, with far greater variation among our devices.

Adapting to Changes

Android device fragmentation affects all aspects of development, but differences in screens probably have the biggest impacts on an app’s visual design. A few common resolutions account for the most popular devices: 1280×800, 480×800, 480×854, 1280×720, and 1024×600 will cover most of today’s popular handsets and tablets. But, there will always be device manufacturers large and small that want to “push the boundaries” by releasing their own unique screens. Remember when the Droid X 2 came out? Motorola helpfully increased the screen resolution from earlier Droids’ 480×800 to 540×960. That close-but-different size meant that many apps looked just a little wrong when running on the newer devices.

The simplest apps tend to do the best at running on a wide variety of Android screen sizes: as long as you stick to the default Android layouts and styles, the platform does a good job of resizing everything to fit appropriately. Unfortunately, this rarely looks impressive; it’s great for hobby projects or open-source apps, but I’ve never met a business that didn’t want to brand their app and make it look at least somewhat distinctive.

At the other extreme, many designers who are new to mobile software want to specify everything down to the pixel. They may pick two or three “target” screens, create a design that lays everything out precisely, and then hand it over to development to build. It’s easy to make this type of design run properly on the target devices, but harder to make it look correct on larger screens, and even more challenging to look good on smaller screens. It also can lead to some confused customers asking, “We already have the app running on a tablet that’s 800×480, why can’t we just put that same design on a phone that’s 480×800?”

Designing for Differences

You need two things to escape from the morass of Android screen layouts, a small tool and a big solution. The tool is to always use density-independent pixels (commonly expressed as “dp” or “dip”) in your layouts. Google has been very good at pushing this approach from the very beginning of Android, and describing the motivation behind it. A density-independent pixel will always occupy the same physical size on a screen, regardless of that screen’s dot pitch. 10 pixels on a ViewSonic 7″ tablet will be much larger than 10 pixels on a Samsung Galaxy S III; however, 10 dp will be the same size on each.

Density-independent pixels are not a panacea, though. Even if you create your tablet UI using dp units, the UI still may draw off the edge of the screen when you try and run it on a handset. As a general rule, Android designs tend to do well when running on screens that are physically larger than the ones they were created for, but not in the other way. We’ve found that the most skilled Android designers we work with tend to do the following.

1. Decide how many different designs you want to create. This is usually one handset and one tablet design, but it could easily be one small handset, one large handset, one 7″ tablet and one 10″ tablet.
2. For each design, build to the lowest common denominator: focus on the “worst” device that needs to be capable of running that app. If you want to use one design for both 480×800 and 480×854, design for the former, and it should look fine on the latter.
3. Decide whether to handle rotation. Android makes it fairly easy to support both portrait and landscape orientations, but it’s even easier (and cheaper) to only support one. People are used to portrait-only apps for handsets and landscape-only apps for tablets.
4. Try to keep app flow as consistent as possible across all designs, while taking advantage of the opportunities larger screens afford. That means using fragments or Master-Detail designs for tablets, which should ideally behave similarly to single-screen designs for handsets.
5. Design to the width, and let the height flow, scrolling vertically if necessary. This is the standard UI experience on most Android apps, including the pre-loaded apps like GMail and the browser.

Leave Room for More

Finally, the part that separates veteran designers from novices: describe where unclaimed space should go. This is what will future-proof your design, and ensure that it will look fine on screen sizes that you don’t have to specifically build for.

I’m not a designer, but here’s a rough sketch of the type of design I love receiving.

This looks different from a standard Photoshop-style design, which precisely positions every element at a specific location. Instead, this type of design gives sizes for most elements, describes the margins and borders for nested elements, and most importantly, describes where unallocated space should go. This last point allows the design to “scale up” to arbitrarily larger devices.

Partners in Design

Ultimately, a successful mobile app will depend on the coordination of designer and developer. The designer is responsible for creating an attractive and useful interface; the developer should help by providing technical feedback and encouraging the designer to think about what will happen if the app runs on different types of devices. Iteration of design helps a lot, and spending a few days or weeks at the start of a project to future-proof an app design can save weeks or months of headaches at the end. Developers, be good to your designers, because everyone will judge your app by what they produce; designers, consult your developers, because they will make your app feel as good as it looks.