5 research-based design principles for porting iOS apps to Android
One of the projects I currently work on involves porting an iOS app to Android. There’s several resources out there that discuss the UX differences between the two platforms, but they tend to be either too high-level or based solely on opinion.
As a result, my colleague and I decided to run a quick user study to get some empirical data on what works and doesn’t for Android users.
Using Axure 6 beta’s mobile prototyping capabilities, we created a prototype that replicated the iOS app experience in a mobile web browser on an Android phone.
We then recruited Android users without significant prior experience with iOS. Their expertise levels with Android were split roughly evenly between intermediate and expert.
We had these participants complete several tasks that were specifically designed to exercise iOS design elements whose applicability to Android was in question.
Here are 5 design principles we were able to infer from the study data:
- UX differences between Android and iOS are only noticed by expert Android users. Intermediate users were largely oblivious to the prototype not following Android UX conventions.
- When in doubt, Android users reach for the hard buttons. Whenever participants couldn’t figure out how to accomplish a task, their first instinct was to use hard buttons, especially Menu and Back.
- iOS UX elements whose function is clear can be successfully used by Android users. An example is global tab bar navigation, which some Android developers shy away from as it’s perceived to be an iOS artifact. All of our participants successfully used it, and none questioned its use on Android.
-
iOS UX elements that are redundant with Android hard buttons should not be used. Some examples include Back and Action buttons, as well as search bars on top of list views. Expert Android users can still use these, but they immediately flag them as iOS artifacts, which negatively affects their perception of the app.
-
iOS UX elements whose purpose is unclear without iOS familiarity should be replaced by Android conventions. A prime example of this is the detail disclosure button for accessing list item properties. None of our participants understood its function immediately, and some weren’t able to use it at all. As principle #2 suggests, participants’ first impulse was to try to access list item properties using the Options menu. When that failed, several tried to use a longpress gesture.
These principles can be used as a starting point for porting an iOS app design to Android. But, of course further refinements will usually be needed. When that’s the case, resources like Android Interaction Design Patterns and Mutual Mobile’s Android Design Guidelines can help. Ultimately though, testing with your app’s users is the best way to validate your design choices.
Interesting research, I’d be interested to see research for a similar experiment using Windows Phone 7 where the design guidelines differ by a large amount from iOS and Android.
Thanks Nigel. That would be interesting indeed.
My hunch is that, because the design aesthetic is so different, users with significant Windows Phone 7 experience would quickly reject any attempt to carry over design elements that don’t fit their expectations. Bryan Fling has recently written a good post on this subject.
Hi,
an interesting read. Would be interested to know more, i.e who and how many people you ran the test on
Question: If users will use the tabbed navigation, should you still include an options menu that’s activated with the hard menu button? It seems redundant but some users may still prefer it?
Hi Smitri,
While some Android apps use the Options menu for global navigation, in my opinion this is not as effective as using tabbed navigation, because it is not persistently visible and because users require an extra gesture to access it.
I would instead recommend using the Options menu for secondary navigation options that may not fit into the tab bar (e.g. Settings, Help), or else actions that would take away from the screen real estate available to view content if displayed persistently (e.g. Share).
Some examples:
http://www.androidpatterns.com/uap_pattern/options-menu
http://www.androidpatterns.com/uap_pattern/share-button
Dmitry
I should add that I definitely wouldn’t recommend duplicating tab bar navigation options in the Options menu. It will only make your app feel more cluttered, and make users wonder whether the two sets of options are really the same.