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.