Designing for Android 🤖📱
I've spent too many hours over the years cross-referencing websites, taking screenshots on different devices, looking at internal data, and searching for documentation in order to understand what screens to design for.
Here's what I've learnt [1/12]
I've spent too many hours over the years cross-referencing websites, taking screenshots on different devices, looking at internal data, and searching for documentation in order to understand what screens to design for.
Here's what I've learnt [1/12]
If you only design for one resolution, choose 360 x 740dp. It's most common and is similar to other popular resolutions (360 x 720, 747, 780).
If you only buy one device, choose a Samsung S Series that's 1-2 generations old. Right now, that would be an S9 or S10.
If you only buy one device, choose a Samsung S Series that's 1-2 generations old. Right now, that would be an S9 or S10.
Having a Samsung S9/S10 makes it easier to QA implementation against your design spec by taking screenshots. You want your test device to match the resolution you design at.
Otherwise, ask an engineer to take a screenshot in the Android Emulator. It's called "Screen Capture."
Otherwise, ask an engineer to take a screenshot in the Android Emulator. It's called "Screen Capture."
When you bring your S9/10 screenshots into Figma, just scale them down to 360 x 740dp (1/4 of their actual resolution).
If you're like me, you may be confused why Samsung's app bar is 42dp (not 40 or 48dp). Don't be confused. That's just how it is 😑
If you're like me, you may be confused why Samsung's app bar is 42dp (not 40 or 48dp). Don't be confused. That's just how it is 😑
It's also good to understand how an interface will appear on older phones. For that, check your designs against 360 x 640dp. It's still very relevant, especially outside the US.
These devices include the Samsung S6/S7 and tons of older phones from Huawei, HTC, LG and Sony.
These devices include the Samsung S6/S7 and tons of older phones from Huawei, HTC, LG and Sony.
360 x 640 resolution phones do not have software-based 'navigation bars'. They have soft keys, separate from the screen (except the Nexus 5).
This gives the interface an extra ~48dp of height.
This gives the interface an extra ~48dp of height.
If you're up for it, you can also see how your design scales for larger phones. For that, design at 412 x 914.
This is the resolution of the popular Samsung A51 and A71, among others. It's also very similar to iPhone Plus/Max phones (414 x 896).
This is the resolution of the popular Samsung A51 and A71, among others. It's also very similar to iPhone Plus/Max phones (414 x 896).
Similar resolutions are 412 x 915 (OnePlus), 412 x 892 (OnePlus, Samsung A Series), 414 x 869 (Samsung Note, Google Pixel XL) and 412 x 732 (Google Pixel).
Samsung and Xiaomi also have a bunch of phones at 393 x 851.
These are all so similar that 412 x 914 will cover them all.
Samsung and Xiaomi also have a bunch of phones at 393 x 851.
These are all so similar that 412 x 914 will cover them all.
Since the majority of our mobile interfaces are vertical scroll views, width is the most important factor. The greater the width, the more text and elements will fit horizontally.
320 → 360 → 375 → 393 → 412 → 414.
The "fold" may also be important for your product.
320 → 360 → 375 → 393 → 412 → 414.
The "fold" may also be important for your product.
But some interface layouts (like music players or Stories) respond to both width and height. For this, the screen ratio is most important. 19.5:9 and 16:9 will cover iOS and most of Android.
20:9, 19:9 18.5:9, 18:9 are other ratios, from most to least common.
20:9, 19:9 18.5:9, 18:9 are other ratios, from most to least common.
Should you even spend the time designing for different resolutions?
My belief is: design for the predominant platform within your userbase and only check the other resolutions when it affects your layout/composition, or the 'fold' is important. Otherwise it's a waste of time.
My belief is: design for the predominant platform within your userbase and only check the other resolutions when it affects your layout/composition, or the 'fold' is important. Otherwise it's a waste of time.
If you want to look up the base resolution / viewport of a specific device, I've found YesViz to be the most useful and accurate. yesviz.com/viewport/
Outside of screen resolutions, there are a few other considerations. Even though apps across iOS and Android are converging in their approach and design patterns, there are some platform-specific things to think through.
Navigation/app/tab bars have slightly different heights and Android's titles are left-aligned. It may feel odd if you're used to staring at an iPhone, but that's cos you've been staring at an iPhone 🙃
Android has two methods for going 'back'. The 'up button' in the top navigation bar returns you back up the stack (or to the prior step), while the 'back button' at the bottom is a historical back.
I often forget to define this behavior but ya gotta do it.
I often forget to define this behavior but ya gotta do it.
There are two primary methods for displaying an overflow of actions: an action/bottom sheet and menus. This used to be more divergent but as of last year both platforms support both approaches. Yay for us!
Chat with your engineers about dialogs and permissions. How does bluetooth pairing work? How do notification or photo permissions work? If you decline permissions, how do you enable them?
The behaviors and rules are often changing.
The behaviors and rules are often changing.
You may also need to consider the different behaviors and interaction patterns for notifications, like actions.
Android also requires that you show notifications for background activities like uploading. How does that interplay with an upload UI you might have in your app?
Android also requires that you show notifications for background activities like uploading. How does that interplay with an upload UI you might have in your app?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
