Should My iPhone App Match My Android App?

October 15, 2013 — 2 Comments

I get this question all the time from clients and fellow designers. The answer is yes and no and sometimes.

What should match

The Core UX: The overarching user experience, meaning the flow of the application, should be the same in across all OSs for a specific form factor. The personas, scenarios, design principles and conceptual model should all be established and validated before screen level design begins.

Aesthetic: The overall aesthetic should be similar for both; it should support your brand strategy.

What will probably match

Information Architecture: The IA for both OSs will likely be the same, although the navigation controls may be different. I have seen apps deviate when one OS offers features (not UI controls, but actual functionality like in-app launching of another app) the other does not.

Content: The base copy will probably be the same. You may have more or less transactional copy for one OS vs the other depending on the specific UI, but the majority of the copy will be identical.

What won’t match

User Interface: Each OS has their own set of controls that should be leveraged.

Interaction Design: The OSs also have their own gestures and interaction design conventions that should be learned and respected (if not always adhered to).

Please note, the answers above may not apply to games since games typically use a OS neutral custom UI.

allthecooks

Let’s take a look at an interesting example I found yesterday of a company who nailed their Android App design, but blew their iOS7 redesign, allthecooks. I don’t want to sound too harsh, they were likely under some tight timelines. But tight timelines are even more of a reason to stick with the established UX and IA in the Android app.

The Android App

This is a slick app for social recipe sharing. Of more than 300 Android apps I looked at, they definitely rise to the top 10% for usability and UX design.

Navigation
We recently had problems at RetailMeNot when testing a the navigation drawer design that complied with the Android design guidelines:

Upon first launch of your app, introduce the user to the navigation drawer by automatically opening it. This ensures that users know about the navigation drawer and prompts them to learn about the structure of your app by exploring its content. Continue showing the drawer upon subsequent launches until the user actively expands the navigation drawer manually. Once you know that the user understands how to open the drawer, launch the app with the navigation drawer closed.

We followed the Android design guidelines exactly, but this did NOT test well with RetailMeNot Android users. They were confused, “Why can’t I just see the home page?”.

Allthecooks menu invitation strikes just the right balance between obtrusive and instructive:

Search & Results

Next comes probably the most important element of a recipe app- the search. It is well designed using:

  • Auto suggest
  • The Android spinner control for changing sort order
  • A clear option for adding dietary preferences to refine the search
  • Tags (albeit at the bottom) to make it easy to hone in on specific types of recipes. Even though the tags are all the bottom, if you select a certain tag it is redisplayed at the top so you can see what tags are currently applied to the results.

allthecooks_autosuggest

allthecooks_results

allthecooks_results_sort

allthecooks_filter

allthecooks_results_scroll_down

allthecooks_filtered_and_tags

Couple of minor quirks:

  • The gear/settings in the top right of the results page is a duplicate of the filter functionality. Wrong icon, and why do you need the same features twice? Just ditch it.
  • The checkboxes under the search box don’t really make sense. I would have never given these a second though except for the implementation in iOS7 filter made me wonder: Who thinks like this?

    “I want to search for ‘pear’ but not in the title, only in the description, but not in the ingredients.” Seems like an edge case which means those checkboxes could be de-prioritized in favor of the more common ways people think of finding recipes: by entree, dessert, salads, etc… (ie. raise the prominence of the tags that are pushed down to the bottom of the results list)

quirks

Details Page

Once the results are reviewed, the social cook can navigate to a recipe details page. It is well laid out, easy to scan, with the common actions clearly visible.

Note: allthecooks are not following the Android design guidelines of putting all the actions in the action bar and using the overflow action menu, but have instead decided to put the actions in proximity to the content where they make the most sense. Bet this tested better in the real world.

allthecooks_recipe_top

allthecooks_recipe_middle

allthecooks_recipe_bottom

This page could have used the Android scrolling tabs control to show the Overview, Reviews, Photos, and Q&A, but a long page is even easier to scroll through and see all the important information at a glance.

The iOS7 App

Here is my audio and video walk through of the iPhone app:

Even ignoring the bugs, you can see the iOS7 experience is sub-par compared to Android. Let’s break this down:

Navigation

There is no menu invitation, but presumably the icon is familiar to most mobile users by now. Looking closer at the expanded menu- I noticed there are some differences in the IA.

allthecooks_menu_open_full

allthecooks_menu_iOS

Now, since I don’t work at allthecooks, I don’t know if they are in the middle of a strategy overhaul and the iOS7 app reflects this. But the IA could use another review- this menu is too long and poorly organized. Here are some tips to try testing:

  1. Remove duplicates. There is no need for the Search in the menu and a persistent search in the title bar. Roll Browse (by category) into the persistent Search feature, like Sam’s and Etsy.
  2. sam's club-browse

    etsy-search

  3. Group things that go together- together. For example: My Favorites and Shopping List are utilities for the user, might want to put them near My Profile and My Recipes and My Messages. In fact, bundle these last three together under My Profile. A single profile page that includes Recipes, Messages should work. The profile can also include who I follow and who follows me (like Twitter), and quick access to my shopping list and favorites.
  4. News Feeds, and What’s New and Forums are all ways to learn more and get involved, so consolidate them. Consider adding in some social elements like a leaderboard/top contributor page.

Search & Results
First and foremost the search should work. Once that bar is cleared, let’s look at the search results view. As I noted in the iOS7 video, there seems to be a completely different search experience design for iOS than for Android.

search_bug

search_results

search_filter

search_filter_bottom

search_results_users

profile_page_from_pears_users

Here are some tips to for improving the search experience:

  1. Show the number of results
  2. Show an on-page sort
  3. Use a standard filter icon to launch a filter form
  4. Show the filters that are applied
  5. Remove the toggle for Recipes/Users- instead consider elevating the social element by defaulting the sort to “most popular” or by showing results from people I have followed first in the list (include their photo maybe?), then the rest of the results.
  6. De-prioritize the filter checkboxes for title, description, ingredients, or consider implementing a scoped search control for both Android and iOS, if the demand for this feature is really strong.

Here are some good examples of results pages with sort and filter features:

Expedia offers onscreen sort and filter options.

Expedia_select_location

Expedia_filter

Expedia_sort

Target on Android uses and on screen sort and a filter drawer and shows that a filter has been applied.

target_search_results

target_filter_drawer

target_results_filtered

Saks uses a full screen form for both sorting and filtering and shows the applied filters.

saks_results

saks_sort

saks_refine

saks_sub_category

saks_results_filtered

Details Page
The details page on iOS7 may look nice at first glance, but it is not as easy to use as the Android app.

detail_page
Challenging elements:

  • The buttons (to the right of the title Ingredients) don’t look like buttons and are really small. The last button in the row is particularly hard to decipher, and doesn’t provide any accordance wen it is tapped. But once I scrolled down I noticed it changed the unit of measure from standard to metric.
  • The IA of the content isn’t as well structured as on Android. For example, there is an option to take a picture when done cooking, but not leave a review. Android offers both in the right spot, plus the option to Flag Recipe in case there are errors.
  • Each tab: Cover, Reviews, Photos, and QA repeats the ingredients and directions- more unnecessary duplication.

Other Examples

What are some examples of native apps that have done a good job of creating a consistent UX across the multiple OSs with the same form factor? Some of the best I’ve seen are the Android and iPhone apps from AirBNB, Expedia, New Egg, Zillow, Dropbox, Flipboard, and Evernote.

2 responses to Should My iPhone App Match My Android App?

  1. 

    Nice article, definitely something I have thought about quite a bit. What do you think of a websites mobile version conforming to the Mobile app equivalents? Worth doing?

    • 

      That’s a really good question and something we are working on for a couple of clients currently. Ideally, companies won’t have to have native apps, mdot (mobile aoptimized) sites, tdot sites (tablet optimized) and a classic website. They will just have a responsive website, and native apps if those make sense for their business and users.

      But, while mdot is still around, I do not believe a mobile optimized site should be make to look or work just like a native app. Tools like JQuery Mobile offer a similar set of UI controls as say, iOS, but it never really works the same over the web.

      Guess I’ll pull together an article on this next. Off the cuff, I am thinking UX will depend on the business strategy and personas/flows and feature set, which could very well be different for the two platforms. Aesthetic and copy will be similar, and UI (including IX and gestures) will be different.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s