Designing a Mobile Experience – Platform Diversity and App Consistency

Designing a Mobile Experience

Platform Diversity and App Consistency

Welcome back to Designing a Mobile Experience.

Today we will be talking about how to design for multiple platforms and other things that may cause inconsistency.

First lets talk about what not to do. At the beginning there was iOS and then came Android. iOS had strict guidelines and Android was more open and free form. This led to some app makers to using the iOS guidelines for android apps. In some cases these apps were complete ports from iOS to Android.

This was a significant problem. There were many components that android didn’t use as a platform – most notably bottom “tab” buttons:


This brought two groups – one that believed an app should be the same no matter the platform, and if the app was built on iOS first that layout and design should be present on any other platform. The other group stated that native layout was superior and that apps should use the native platform design even if that causes inconsistency in your app’s on these separate platforms.

The first group quickly found that while the app might be consistent cross-platform, very few users switched platforms so often that the consistency was worth the poor user experience on the secondary platform – usually Android, which was gaining a lot of users. Google also addressed this by publishing their own UI design guidelines. This proved the second group – platform functionality could create inconsistency – was the better option for users.

This is the idea we will talk about today – why might an app be inconsistent on different platforms.

Alright, lets start by mentioning the Interface guidelines for the top 3 current platforms:

When you look at each platform there are key differences in how they display information. These guidelines are not your bible, but they will help you to create apps consistent to their platform. There are some components you will be required to use for approval to an app store, like the grid system on Windows, so pay attention to these key platform requirements that you must follow.

However, there are places that you can choose to deviate from the guideline, and may need to if you are designing for multiple platforms.

Lets look at a few examples of differences between platforms:
The simple button looks very different per platform.

  • iOS7 removed all outlines and shapes around button text.


    However there are places that they so use shape or color to imply a button. We’ll come back to this.
  • Android uses a square flat solid color for the button with the text label on top.

  • Windows uses a square outline with text of the same color.


The same is true for input fields:

  • iOS usually has a rounded outlined box… sometimes, but not always – they leave a lot up to context.

    ios-inputbox vs.
  • Android uses a line on the bottom of the field.
  • Windows uses a box with an outline. However this can be hard to differentiate from a button when the background of the app is white.

Lets move on to icons. Each platform includes a basic set of icons for common functions like: back, search, delete (trash) refresh, etc.

In some cases they are all very similar shapes. However each platform handles them differently.
They are all flat in their style but iOS uses a fin outlined style for their icons, Android uses a filled style, and windows uses a different fill style. Windows also uses circles to outline their icon buttons.

Lets look at the magnifying glass:

iOS uses a the simplest but it is very close to Android’s with only makes a slightly more detailed handle.
However Windows uses the magnifying glass facing the opposite direction – with the handle on the left and glass on the right.

Now lets look at refresh:

Here Windows and Android have very similar shapes – 2 arrows pointing at each other to make a circle. But iOS uses one single arrow in the shape of a circle.

These are still relatively similar. When looking at other icons like bookmark, and share things start getting very different.

What does this really mean?

It means when possible you want to use these platform provided icons for platform consistency. This is also a plus for android developers since this will also work on skinned versions of Android (like Samsung’s “touchwiz” or HTC’s “Sense”). It also means that when Apple decides to do a major UI overhaul that your app will transition nicely, as you don’t have to make all the new assets.

Depending on how icon heavy your app is you may not need to make any custom icons, which is very helpful when supporting multiple platforms. Now if you app is very icon heavy you may need to create versions of your additional icons for each platform you support, or create your own style icons that all platforms (and skins) will use. We will talk more about iconography in a future article.

Icons, input fields, and buttons are not the only built in components to an OS. Switches, check boxes, radio buttons, lists, and scroll bars are just some of the basic building blocks provided by the OS.

Using these built in components means that changes to the OS will take effect and keep your app looking up-to-date. This is especially helpful when some one like Apple decides to completely redesign their UI between iOS6 and iOS7.


Devices that can’t update will keep the iOS6 design even now while we look ahead at iOS9. I still have an old iPod touch that can’t be updated past iOS6, and it still works great for playing music. The good news is that users will keep their familiar experience even though there is a change in the OS design. It is also better from a development point, that you don’t need to update these components when a system change happens.

This same situation happened between Gingerbread and honeycomb on Android, although maybe not as great a change as the one between iOS6 and iOS7.

The next big component is screen size. Even if you are supporting one platform you need to think about what devices you are supporting – Phone and / or tablet.

Here the biggest problems come from portrait vs landscape view areas. Phones are default in portrait, and 90% of the time they will stay that way because thats how the user holds it. Even when playing a game that is locked to landscape on the phone, I have held in portrait due to one hand usage. Is it optimal? Not at all, but thats what happens in real life. Phones are for people on the move, and sometimes you are standing on the bus with only one hand available.

Tablets are a bit different. You can assume that your use is in a place that will be able to use it in landscape if the app is locked to it. The biggest problem I have seen here is that some apps that were optimized for the phone are publishing their app for tablets without optimizing for a tablet. Tablets are larger and have more space so to have apps that are clearly a port, having black empty space around their content, or have a zoom button to make the phone content bigger and fill out a tablet, are simply an awful experience.

If an app plan to publish for multiple device sizes it needs to support each size in its most optimal state. This was a big problem for android apps at the beginning as hardware for the platform was very inconsistent. Check out Google’s guidelines on supporting multiple devices for more information.

I had a very interesting conversation with an android developer during this time. The first 6 inch size phone had come out, it was the start of the phablet conversation, and he wanted to know if this phone should use the tablet UI or the phone UI for this device. It all came down to that it was classified as a phone, so people were going to use it like a phone, and thus it should have the phone interface. He followed up with: “what about for a 6 inch tablet?” This indeed a harder question, and the answer comes down to what is the best usability of your app for that screen size.

As a closing to this article I would like to link to some of my most used (and free) templates:


  • Platforms are diverse and apps should use native components when ever possible, even if it makes your app inconsistent when compared platform to platform
  • If you need to make custom components, like icons, you have 2 options:
    1. . Make once that match the platform defaults – this means making a set for each platform
    2. . Forgo the platform included component and make a custom one for your app – you make one set but need to make all the components effected
  • Determine the devices supported and make optimized layouts for each – i.e., phone only, tablet only, phone and tablet.
    • tablets are landscape and portrait
    • phones are default portrait
    • A landscape tablet layout will be inconsistent with a portrait phone layout due to space available. This is ok and correct

Next time on Designing a Mobile Experience: Lets Colorize