Four Android App Design Guidelines You Should Break

Some of Google's examples are misleading to new app developers, leading to awful UX. Here are four salient examples—plus four unwritten rules you should know.

While Google’s Android Developer Guidelines do help developers create better apps, there are a number of places where usability and common sense should win out over standards. Of course, before you set about breaking the rules, you'll need to learn them, so by all means: Don't proceed until you've familiarized yourself with Google’s standards. They are important and useful. Now here are four scenarios where you can totally disregard them.

Google Design Standards You Should Probably Break

1) The app logo in the Action bar. Disregard!

If your app looks like lots of other generic apps, then putting your logo on the far left of the main Action bar (as per the Google standard) will give users much-needed context. However, most major Android apps do not do this. Why? They have a visual brand that’s strong enough—and a user interface that’s unique enough—to already provide the visual clues users need to know to make the connection.

Removing the logo has huge advantages on a screen as small as a smartphone's—that screen real estate is better used providing contextual information or navigation controls for users. Below, Google follows their own guidelines and puts the Gmail logo on the top left, but Facebook uses the action bar to provide context and navigation.

2) Unlabeled icons are okay. Disregard!

In their guidelines, Google shows a Gmail example for use of icons in the action bar. But their example is inadequate because it shows unlabeled controls—which are really only the privilege of highly recognizable apps. For lesser-known app developers (which is to say, literally everyone but the Gmail maker) putting unlabeled controls in your app just confuses users. People don’t know what your little "filing cabinet" icon is supposed to do in the context of your app. A simple word under each of these buttons greatly improves usability and especially the first-time user experience.

Icon ambiguity, even in a technology as familiar as a mail program (which tends to use very standard icons), reminds us that creating good icons can be hard. Don’t beat yourself up trying to come up with icons for complex or specialized actions which don’t already have a well-known icon. Instead, either put text under your icon, or just use a text button. Icons are great tools for usability when they’re exactly that—iconic—but otherwise, they’re just confusing.

3) The navigation drawer is a natural choice. Disregard!

The drawer is a handy navigation solution for apps that have many categories or top-level actions. I would caution developers not to use this as an excuse for having too much in the navigation. Great apps are focused. In fact, some of the most powerful and useful apps in the app store get by with just two to five navigation items and no slide-out drawer. Before you run off and implement it, honestly ask yourself if you can get away without it.

4) You should use non-obvious interface elements.

Just because something is available in the OS doesn’t make it a good idea to use it. Case in point: Don’t rely on long touches, the hardware menu button, or nested menus. Instead, always have some sort of link on screen for users to get to the data they want. Also, stay away from using multi-pane layouts since they are often unattractive, visually confusing, and clunky to use.

An app with more panes than can fit on screen creates what’s known in the biz as "mystery meat navigation." This sort of layout lacks the visual clues needed by users to know they must perform an action to see more information. If you have more categories or tabs than you can fit on the screen, consider getting rid of some or using a slide-out drawer instead. Here's an example of what not to do:

What's Missing From The Google Android Design Guidelines

Keep a visual separation between buttons.

Text buttons should be visually separated from other icons with a line. While this is a subtle touch, it is effective from a UI point of view. Tumblr (top) has a short vertical line separating their text from the rest of their action bar which is visually clearer and more grounded than the Yahoo Mail App (at bottom).

Use pull to refresh (the right way).

In many applications, pull to refresh is just a better (and more elegant) way to refresh than a refresh button, and users just get it. You should consider using it instead of, or in addition to, a refresh button—but only if you don't need the real estate above your table cells for something else. In some apps, this may be the most logical place for a search field, filter options, or metadata. Obviously, some apps require more frequent refreshes than others—if the app doesn't need to pull in data at least once per session, then consider using the space for something more heavily used.

Consider whether you need an on-screen back button.

If you’re developing an app for an Android device without a hardware back button (such as a Kindle) you absolutely need to have a back button on screen or your app could become unusable. In fact, unless your audience is comprised of only highly technical users, consider having this button on screen at all times. Many less experienced users are confused by Android’s default "back" behavior. So, the more options you give them to go back the better.

It should also become a best practice to make your on-screen "back" button take your users back only one screen, instead of all the way back to your main menu as the Google guidelines suggest. Why dump people out of your app when they're just trying to complete a different task in your app?

It doesn't matter if your icon has rounded corners.

When I speak at a conference, or am consulting with a client, I’m often asked, "Should app icons have rounded corners or square corners for Android?" My answer? Let it go. It doesn’t matter. Maybe in a year or two then we’ll see a clear winner start to dictate Android app design conventions for the rest of us, but right now, 95% of your users really don’t expect one over the other. Make the rest of these choices yourself—but on this one, I suggest using it as an opportunity to defer to the HIPPO (Highest Paid Person’s Opinion).

Screenshot images from Google's design guidelines.

[Image: Flickr user Eric]

Add New Comment


  • Mark Buikema

    I couldnt stop laughing while reading this. It's saying exactly the opposite of what it should say. Android guidelines are near perfect in terms of design, just follow them. Diverting too much maked your app look amateuristic.

  • omaryak

    You have to know the rules before you can break them, and as some other have pointed out here, it appears you're not very familiar with them. Yes, the apps from bigger brands break rules, and sometimes (not always) for good reason. But most apps aren't Facebook and shouldn't try to be (a point you touched on with the navigaton drawer). For most apps with basic functions, following Google's guidelines helps make an interface more predictable and guides the user along. Used properly, it can make an Android app as intuitive as its iOS counterpart. It's when those rules are broken that confusion can ensue.

    I agree that there are some ambiguous icons that may need labeling, especially when an action is prominently needed to complete a task, or when the potential destruction of data is involved (something Google recommends a popup dialog for anyway). The proper way to label icons on Android is to place text to the left or right, not below the icon.

    I do like the idea of using the app's icon to provide a navigation menu; one of the more frustrating aspects for me about Android UI is the prominent placement of a skeuomorphic app icon that is not tappable half the time. I'd get rid of the duplicative "more" icon on the left though (an ellipsis is meant to be used at the end of a sentence …).

    Also, whatever in the world is wrong with what Google did in its contacts app? That's not mystery meat navigation at all … those are familiar icons to modern technology users. MMN is an outdated concept from Web 1.0. Users have learned a lot since then. Let's let them use that knowledge (and perhaps learn with a long tap … or, God forbid, tap to discover) to bring us forward into the 21st century. And if we break guidelines, let's do it for good reason in a way that helps the user.

    There seems to be an irrational fear plaguing modern UI design thinking: that if users don't know exactly where they're going and what will happen they will get frozen on a single screen. Exploring is one of the best things about using a new interface. Users need confidence to explore … so don't gyp them. But for God's sake, let them explore! And let the interface sing.

  • Thomas

    Sorry, but means "major apps", iOS style apps? The magic word is "recognition".

    An UI back button in the action bar, pull to refresh instead of overscroll, removing the icon to get additional space, but labeled icons? It's confusing crap... please read and understand the guidelines and patterns.

    Android's only problem is Google and their not compliant apps. Google Maps 7? No actionbar, a kind of menu on different places, a kind of selectable menu item (with an undefined selection state), a drawer menu like on another platform, iOS7 icons and color schema...

    Android has a good styleguide - but Google torpedo it again and again. Each version another UI and another styleguide... more fragmentation, less recognition, more efford to code compatible apps.

  • Sahil Chaturvedi

    Wow. This is definitely the worst android design article I've ever read. I really hope this is a joke.

  • Adrian

    Looks like someone doesn't know the difference between "Up" and "Back" for Android...

  • Android

    Oh Jason you really don't care don't you? You read Apples guidelines and you think they can apply to Android to make your life easier. I meet so many designers/consultants like you. It's really sad.  

  • Waza_Be

    you indeed show us some Android issues, but the way to fix them (or workaround) is for sure NOT what is written there.

    Please take care before posting such mistakes and let a peer review what you write,....

  • richie97

    This post is just about the worst post on Android design I've ever read, and frankly, the author probably should just stop writing. Edit: Or get fired. whichever works.

  • ryanharter

    I can tell since you call lists tables that you are just an iOS user and don't really know Android. Clearly you are trying to make split action bar action items be iOS bottom tabs, add a navigation bar instead of an action bar (for back navigation, who could ever say "if its confusing, give them more options"?), and add a search field under the upper overflow. 

    Pull to refresh in general the way you discuss it only works on iOS where you *can* over scroll a list, but android doesn't have that convention because Apple sues anyone who does it. 

    This is a terrible article and only really works to help iOS users feel better about their conventions, not design better Android apps. Please stop doing Android consulting. 

  • Paul Burke

    Almost everything in this article is completely erroneous and misguided. I truly hope that developers and aspiring designers are not swayed by these ignorant opinions, and will do my best to prevent it.

    This is typical from a web design company that's focused on iOS.

  • Mark Murphy

    "However, most major Android apps do not do this."

    And your proof of this is... what, exactly? Please feel free to cite the sources of your survey that validates your claim and provides a reasonable definition of "major".

    "A simple word under each of these buttons greatly improves usability and especially the first-time user experience."

    You are cordially invited to provide examples of any "major" apps that do this. Feel free to use advanced constructs like "hyperlinks" and "screenshots". You might also explain how humanity has survived with "unlabeled icons" for the past quarter-century, with things like toolbars in desktop apps. And fix all the unlabeled icons on this Web site -- let he who is without unlabeled icons cast the first stone.

    "In many applications, pull to refresh is just a better (and more elegant) way to refresh than a refresh button, and users just get it."

    And your proof of this is... what, exactly? Please feel free to use an intellectually rigorous definition of "better", and please feel free to cite any survey demonstrating that users "just get it" more than they do a refresh button.

    "If you’re developing an app for an Android device without a hardware back button (such as a Kindle) you absolutely need to have a back button on screen or your app could become unusable."

    All Android devices have a BACK button (hardware or software), including the Kindle Fire series. You can tell this by actually using Android devices, such as a Kindle Fire. You can obtain some Android devices fairly inexpensively, not to mention used ones on places like eBay.

  • David

    This is the most misleading and wrong article I have ever read about Android UI development.

    Every single point mentioned here can be proved wrong by tons of blog posts, Google+ posts and/or videos/tutos from Google I/O (2012 & 2013).
    And using the Facebook app, which is one of the worst Android app out there that comes from a big company, as an example, is showing how irrelevant the whole post is.

  • David

    And the blogs and Google+ posts I am talking about are not from Google.

    (After re-reading my post, I fount my sentence unclear on that point)

  • curioustechizen

    Other commenters before me have already pointed out what in my opinion are flaws in your reasoning and assessment of the guidelines. I'd like to point out a few of my own:

    Regarding Labeled icons: Long-tapping on an icon shows the description of that icon. It is a system-wide gesture recognized by users. Secondly, have you considered the **internationalization implications** of displaying labels below text (or even labels *as* text)?

    Regarding Navigation Drawer: Where do the guidelines make an unqualified statement that it "is a natural choice"?

    Edited to add:
    Regarding the Multi-Pane layout: In Android, it is a standard pattern to "click" on an item in the list view to drill down into the detail view. Perhaps you felt the users will be lost here just because there's no "right-pointing caret" to indicate that there's more? In that case, please see this: http://developer.android.com/d...

    Also, "panes" in multi-pane layouts are useful for composing them together on larger tablet-sized screens. Please understand that Android apps should target everything from a 3 inch screen to a 10 inch screen and stay responsive across orientation changes. Multi-pane layouts are *the* way to go in these situations.

    What would _your_ advice be for designers to cater to the wide variety of screens and across orientations if one were to ditch multi-pane layouts altogether?

  • Juhani

    I don't think that the autohor has really used Android devices (ie as a daily device). These advices don't make sense for the most part and do reflect authors misunderstanding of the platform.

    This article would really benefit from a better peer review.

  • George

    I disagree with the majority of this post.

    Where I do agree that the Navigation Drawer is probably not the right solution for navigation in many applications and I fear that we will be overwhelmed with applications using this pattern.

    Android does not force application publishers to use a particular shape for an apps icon, but I would recommend that the icon try to follow the suggested guidelines to create some consistent look on the platform

  • Daniele Segato

    Sorry man, but you are saying a lot of crap about Android design. I have to say it to avoid people stumbling on this and actually trusting you.

    You didn't get the design guidelines at all...
    I really suggest you to re-read them more carefully.

    1) The app logo is needed to know exactly where you are at a glance, without having to look around (on Android you switch between applications as you switch between your own activities and the user need to know, by looking exactly on the spot where the logo is supposed to be, to know which application he is using) -- If you need more space for text in the action bar you are doing it wrong. That's not meant to contain important informations.
    2)  label in icon = bad waste of space - you may need it the first time the user open your application then you don't need it anymore (wasting space)! User on Android long-press to see the "label", what an icon does. And if you have too many icons or they do not remind to their function you have to think harder on it, not just disregard the guideline - You do not advice others to do the same as a way to justify yourself.
    3) The navigation drawer is a perfect choice when you have to follow some navigation pattern. It's not the way to go for every single activity you wrote. You apply it when it makes sense and you disregard it when it doesn't .. in your activity.
    4) Oh god... its up to you to teach the user how to use your UI. A choice may be showing it to the user by starting the activity with the UI in place and quickly sliding it away with an animation, the user will then instinctively know what to do. You are throwing away good guide lines and replacing with bad ones just cause you didn't understood them.

    What's missing on Android.There are missing things, not the ones you listed.The pull to refresh is actually currently missing from the SDK but there are a number of libraries around the web that you can use and Android nowhere say you shouldn't use it. They actually use it in their new gmail app.

    Rounded corner icons? Android do not tell you what to do, that's your choice. It just sucks, in my opinion, having rounded corner icons on a platform where rounded icons are nowhere to be seen. Still this may make sense in your design. Hearing what you say I really doubt it tough.

    Having a back button in your activity!?!? Oh my... Did you ever used an Android phone for more then 5 minutes?!

    ps: this is NOT iOS, and if you want to be a designer for Android you should understand it. Please avoid giving bad advice like that in the future

  • Sebastiano

    That. Indeed.

    This post makes no sense at all. And, taking the Facebook app as an example is just plain absurd, it's got one of the most confusing UIs ever.Not to mention that right after that you say "But their example is inadequate because it shows unlabeled controls--which are really only the privilege of highly recognizable apps." when referring to unlabeled icons.This is just in contradiction to what you wrote in the first point, where you take the Facebook app and say "[...] most major Android apps do not do this. Why? They have a visual brand that’s strong enough--and a user interface that’s unique enough--to already provide the visual clues users need to know to make the connection." What, you should do just like top apps and trust your UI to be recognizable enough that people just know it's your app, even though you can't do that for icons, unless your app is as famous as GMail?

    F**k logic!

  • Paul

    An article referring to "awful UX design" seems like the perfect place to make this comment:

    I really love when I'm scrolling down the main FastCompany.com page, looking for an interesting article to read...when the page reloads, popping me to a different location on the page, forcing me to scroll up and down to find out where I was before the reload.

    Now there's an awful user experience for you. Please fire whoever let this get by, and put the rest of your crack UX team to work fixing this. Thanks.

  • Gabe Stein

    Hey Paul, we actually just fixed the scrolling issue. It's been on our radar for a long time. Enjoy and feel free to complain about any other annoying features, but we respond a lot faster on Twitter (@fastcolabs)