3 Ways to Improve Cross-Platform Mobile Design

As a designer, it’s impossible to not have your work influenced by great design from others. This isn’t limited to great design on the web or mobile apps, but great design in everyday life. The look of a watch, or the styling of a high-end automobile, a building, or even a light fixture might spark an idea. You can take inspiration from the typography on the cover of a matchbook, or the clean lines on the newest Bugatti. It’s even more difficult for designers to not be influenced by the work of other designers exploring the same medium.

For me, the medium is web and mobile applications. It’s easy to see how much other designers have fallen victim to the same malady. Perhaps the clearest example of this comes from Google. Not in Google borrowing design ideas from others, but in the impact Google’s design has had on the web and even iOS applications.

This has seemingly been the case since Google took off, with countless designers being told to “make it more like Google,” even in the least appropriate of use cases. But, the fanfare has exploded thanks first to the card designs in Google Now, followed by the 2014 release of Google’s Visual Language known as Material Design.

The visual language cues from Material Design can be found all over the web, from cards. The thing is, although Google uses this one design system _nearly_everywhere, there are reasons it shouldn’t be applied so universally. Even Google stops short of making it universal (there’s no floating action button in the web version of docs, for example).

Respecting the HIG

Google’s Material Design is a set of visual styles. Apple on the other hand has the HIG (Human Interface Guidelines). Actually they have multiple. There’s an iOS HIG, an OSX HIG, an Apple TV HIG, and an Apple Watch HIG. There are reasons each device has its own guidelines. The interplay between hardware design and software design is extremely important. Apple knows, as does Google, where the physical buttons will be on a device. They know which parts of the screen will be easiest to access with common grips. They know—in the case of devices like Apple TV—what will and won’t be capable through a remote. So the guidelines differ. They maximize the experience by creating guidelines that enable optimal interaction between software and hardware.

But then there’s the web…

The web does not have the benefit of a HIG. There are best practices, and responsive design theoretically makes a site work everywhere, but the web doesn’t quite have the same feel as an app. It doesn’t feel integrated into the device ecosystem.

Without the direction of a HIG, web designers have more freedom, but they also become more likely to take things like Material Design ideas and bring them into a context they were never intended to fit. The hamburger menu is a classic example of this. It started as a tool for condensing navigation on mobile devices. It then made its way to the web, even though this presents content discoverability and general usability challenges.

From a practical standpoint, you often have the same designer or team of designers designing a web app, and mobile apps for iOS and Android. This is where things get complicated, and where human nature can take over. If I’m one designer, I may like the way something feels and want to use it not just for the web or Android, but all of the apps I am designing. It’s also easier to design an element only once. And you can, sometimes successfully, argue that this will benefit users, since they will only have to learn your apps once. This is what has led to Google’s Material Design making its way into websites and iOS apps.

But, when we cross-pollinate, pulling the design elements from one system into another, the pieces don’t always fit quite right. This creates a disruption in visual patterns. If I’m using an iOS app, I expect it to be designed like an iOS app… and when it’s not, it takes me more time to learn and use it.

Take for example, the segment control—an iOS feature used to show different data on a single view. If you look around (for not that long) you’ll start to see examples of the segment control being replaced by tab navigation—an Android / Material Design pattern, also common on the web. The thing is, there’s no reason to break with the HIG and plenty of reasons to stick to it. You can easily design a segment control to fit nicely into an app design. This will help your app feel more natural to an iOS user.

Well-designed apps are like well-designed luxury cars. Each piece fits only that car. Would you take the doors off a Ford Fiesta and try to fit them on a Ferrari? Of course not. And you really shouldn’t try to fit Material Design into an iOS app. Or iOS design into an Android app. We have to provide users with an experience that feels native to the device they are using.

What’s a Designer to Do?

1. Think About the User First

If you are designing an interface element because you like it and you think it looks nice, or because you prefer the Material Design guidelines to the iOS guidelines (or vice versa), stop. Just stop. Put the user first. Users generally don’t care about your preferences. They care about your application working, and working as they expect it to work.

If you can support your decision to break with the HIG through user research, that’s a different story. But, if you are breaking with the HIG for personal preference, you are probably frustrating your users; not helping them.

2. Design for the Platforms your Analytics Support

We’ve talked a lot about Material Design influencing iOS apps, but the problem works in the reverse as well, though not often for the same reasons. Oftentimes, designers begin designing for the platform they know and use everyday—frequently iOS—if that same designer is also designing for Android, what happens frequently is that the design is translated to Android, rather than crafted for Android. As with language, there are great translators and there are things that get lost in translation. This leads to a less than stellar experience for whichever app gets the translation experience—frequently Android.

Instead, either pair with another designer and focus on one version of your app… or, if that’s not an option, look to analytics. If you are using iOS, but 90% of your users are using Android, throw your personal preferences aside and tackle Android first.

Designing for the platform you are less familiar with may be a good way to start in any case. If you are an iOS user, you are likely better equipped to translate an Android design to iOS than vice versa. Set yourself up for success across platforms by starting with the harder work. This will save you time at the end of the project.

3. Read the HIG(s)

It can’t be said enough, you’ve got to read the HIG. You and your dev team should read the HIGs for any platform you plan to create apps for. Everyone should understand the ecosystem and how to design and build for it.v