Published on | Prototyping: From UX to Front End — Medium Brian Law

Android and iOS have always been different. Is there an objectively better design philosophy?

The Big Three: We can agree on some things.

Google, Microsoft, and Apple all have published guidelines on designing apps for their platforms and there are certainly some major differences between them. However, there are some basics that these often at odds companies can agree on, if not in practice, at least in principle. The very first heading on the Microsoft Design Principles page is “Keep it simple,” appropriately done with white text on a blank, red background. Apple states in their own guidelines that “a sharpened focus on functionality motivates the design.” Google explains that bold, intentional graphics, a center principle of their Material Design, “do far more than please the eye. They create hierarchy, meaning, and focus.” These principles all essentially state one major point in some different words. Keep it clear. Clarity is essential to a usable interface.

With the release of the iPhone 6s, apple introduced 3D Touch, a system of pressing into the glass to access more actions than could be achieved with tapping alone. Liz Stinson of Wired explains that it introduces the ability to include “complicated contextual information and new functionality without cluttering the user interface.” It’s a design element that some may see as more complex, but it keeps the screen visually simple.

The days of abundant skeuomorphism are done. Back in 2013, David Pogue of Scientific American predicted that with with the departure of Scott Forstall from Apple, and his position being filled by the designer Jony Ive, “The days of iPhone apps that have fake wood grain, fake brushed metal and fake stitching in fake leather are probably numbered.” Sure enough, iOS 7 brought a massive change with a completely rethought design. The compass no longer looked like a sturdy, metal instrument sitting on a vintage, wooden table. It looked modern with the minimum number of design elements to convey its purpose. The notes app did away with ripped pages and replaced it with bold yellow and white graphics.

Notes on iOS 6 looked like a physical notebook. An update cleans up the design for a clear writing space

Bolter and Grusin would state in Remediation: Understanding new media that incorporating familiar elements from past mediums is essential to making new designs intuitive. When users weren’t used to computers, the desktop was a natural way to create a working space. A user could move around documents like they might in real life. Folders kept things organized the way real folders could hold one’s files. Modeling the new after the old keeps things familiar. And as Nir Ayal points out in “People Don’t Want Something Truly New, They Want the Familiar Done Differently,” once users are familiar with a concept, a designer can “shepherd them” to a more raw form of the utility.

In 2017 though, a vast number of software users’ prior experience is with other software. So certain elements connecting to our past will likely remain in our software because they have been established as having a consistent meaning. As Pogue points out, the camera icon that looks like an actual camera is likely here to stay. Users might have never even held a camera other than the one integrated into their phone, but it’s the icon they’ve seen before, so they’ll recognize it when they see it again. It doesn’t take experience with a professional DSLR camera to recognize the function. But while these relics of a transitional period may carry on, for the most part, user interfaces can be simplified. In some cases, folders are replaced by tags. On mobile devices, there is no desktop to organize your files because it is accepted that applications can handle that for you. Designs have started to reference each other more than they do the real world.

This makes the next focus of design between the big three tech companies make all that much more sense: consistency. Microsoft states “Think universal.” Google aims for a “unified experience.” Apple states that an application should implement “familiar standards and paradigms.” It makes sense that intuitive user interfaces mirror each other and carry more similarities than differences across platforms.

Consistently Inconsistent.

Even though Google, Microsoft, and Apple have these similarities in their goals, they certainly take them in different directions. At the principle level, they all depart from each other in some amount. Apple states that user interfaces should feature a “minimal” use of drop shadows while one of Google’s central “Material properties” to follow is that “Material casts shadows.” Meanwhile, Microsoft makes no mention of shadows at all and includes none on its Design and UI page.

On the use of color, both Microsoft and Google share a heavy use of bold, solid palettes while Apple implements gradients, applies transparency (especially at the OS level, choosing to make features such as Notification Center show a blurred version of the app behind them), and focuses on the ability of specific colors to convey meaning. To address only the visual differences between these tech giants though, would be to miss a major design element of a user interface.

Apple heavily uses transparency

Beyond the Visuals.

User interfaces are more than just pictures on a screen. They are interactive. As such, even if two systems are visually similar, their functionality can vary dramatically. Menus, tabs, buttons, sliders, switches, and text fields all take actions. Beautiful interfaces can, in fact, be awful interfaces. Louie A. dedicated an article to fighting an industry standard to use “Hamburger Menus,” (also called “Basements” and “Navigation Drawers”) side menus containing various navigation buttons. He explains that they hamper discovery within the app, are inefficient, and cause navigation problems. For example, a back button is integrated into Android as an operating system while iOS applications are expected to include them on screen, usually placed in the upper left or right corner, depending on the user’s language. The similarly placed basement menu makes navigation either confusing or clumsy. Louie A. isn’t alone in this stance. Anthony Rose published an article on TNW explaining that even when users liked the look of a navigation drawer, their time using the app significantly dropped.

Despite the widespread agreement that navigation drawers are not an example of well executed interface design, they still appear on iOS and plague Android apps. They have even been officially endorsed by Google.

Google Calendar uses a navigation drawer to access calendars and views

It comes down to the information architecture of the app as Louie A. explains. A good user interface requires good organization of its components underneath it. Navigation drawers frequently hide important features off to the side, but Microsoft’s “Tile” system is equally guilty of missing the mark with their information architecture. Treehouse lists visual hierarchy as a user interface design fundamental and tiles completely lack in this department. They are simply placed in a grid, with no apparent order or ranking.

A Working Interface.

Even after perfecting pleasing visuals and structure of a user interface, there are still further steps to making a user interface work. It’s a dynamic, responsive system. Animations and actions need to convey what an application is doing in response to a user’s input. Peter Vukovic of 99Designs has written a set of 7 laws to follow that center, mostly, around the way an interface reacts to user input. Asking a user to do something with a prompt will dramatically change the chance that they take an action. Larger actions should be broken down into smaller steps. Every action should have clear feedback to show the user that an action they have taken worked.

Vukovic also makes a point that the defaults of a program are extremely powerful. Users will likely never change the settings of their devices. This is an idea that Apple clearly keeps in mind with their design. With the move from iOS 9 to iOS 10, Apple actually removed customization options in favor of their chosen defaults, including the sorting of notifications by time rather than by app. Whereas Google has embraced the path of customizability, sometimes focusing less on establishing a working system from the start and more on the user’s ability to hone their device’s functionality to their personal preferences.

So Where Next?

If the largest tech companies can’t agree on a design philosophy, how do we know what’s best? There are few surviving design principles that are universally regarded as poor ideas within these major ecosystems, navigation drawers being a rare exception. One hurdle that makes establishing the best path is that there are few chances to place two designs head to head. App support between devices is frequently different, but when it does overlap, developers often choose to keep their apps consistent between each platform rather than keep the apps consistent with the platform. It takes a direct comparison, with the same functionality, to actually establish which design is superior. Luckily, there are some examples to evaluate in order to reach a meaningful conclusion.

Google Calendar is nearly identical on both iOS and Android

Testing User Experience.

There are companies that choose to follow the design principles, at least in part, of the platform they are publishing on. PocketGuard and Todoist are excellent examples of this. The apps on separate platforms certainly resemble each other, featuring the same functionality and the same color choice.

But there are features on each platform that clearly have roots in their platform’s design principles. In the case of PocketGuard, the iOS version uses a transparent blurring effect, and the app is navigated using a tab menu at the bottom. The android version is inspired by Google’s Material Design, using solid colors, subtle shadows, and a navigation drawer.

PocketGuard for iOS and Android feature the same colors, but still follow Android and iOS guidelines

Doist’s powerful organizational app, Todoist, features app designs that are consistent with their platform’s guidelines save for Doist’s own visual style that maintains some consistency across each device. The iOS version features a layered design with the use of an upper left back button. The android takes advantage of Android’s built in back button, features a navigation drawer, and uses a more three dimensional appearance.

I had users test these two apps, given specific tasks to complete in them, and respond about their experience with some multiple choice questions and one open ended question asking about their general thoughts about the design. Participants were asked to test only one of the platforms in order to avoid bias by trying one before the other. Trying to execute this in person using my own devices would have been difficult in a small timeframe, so I used an online form that had participants use their own phones.

Survey Design

The survey was sent out to as many potential users as possible with each using their own device. To keep things simple, I looked at strictly iOS and Android as the Windows Phone is not very commonly used, has a more limited app store, and tends to be not as up to date. The survey initially asked which device they are using. Because this study compares the iOS and Android versions of Todoist and PocketGuard, anyone using another operating system was excluded. These surveys completed upon their selection of an operating system other than the ones we’re focusing on.

From here, each user was asked if they have experience with either PocketGuard or Todoist. Any prior experience would add significant bias. This study wouldn’t say much about intuitiveness if the user had already learned how to use the application, so those who have already used the apps were excluded and moved onto the next one.

For users who have not used one of the apps before, the next step was to download the app, create an account, and follow through some basic tasks within the app. PocketGuard users needed to connect a financial account to the app that they might wish to monitor, set a spending limit in the “Auto & Transport” category, then exclude an account from budget calculations. These tasks were deliberately chosen because they involve using different menus for each of them. Because menu switching is so involved here, if the app designers constructed effective information architecture, it should not have been too much of a challenge. If the information architecture is not well designed, however, it would likely be difficult for users to understand or complete.

Navigating Todoist is dramatically different on iOS and Android

For Todoist, after creating an account, users needed to create a project for “Groceries,” add an item to the project “eggs” and set a due date of today, view the item in the Today View, then complete the item. Then, the user had to customize the app to have a theme of “Neutral” and assign an avatar to their user profile. This sequence of tasks was intended to make full use of the features that Todoist offers for free and force users to familiarize themselves with the less obvious settings menus. Again, this put the information architecture to the test. If users were able to complete the first few tasks, but not the second set of tasks, it indicates that the less frequently used menus are harder to find, but that the basic functionality is intuitive.

Google Forms was an efficient way to survey user’s thoughts

After attempting the tasks, users answered four questions for each app: Were they able to complete all of the tasks? On a scale of 1 to 5, how easy was it to complete the steps? On a scale of 1 to 5, how appealing was the app’s interface? What are your thoughts about the layout, functionality, and design of the app?

The first question was meant to gather the basic information of if these apps are even usable to someone new to their interface. The idea here is that someone who is new should not need to have a lesson in how to do these tasks. I give no directions on how to achieve them because the goal of app design is to make functionality obvious with the interface alone. If users were unable to complete the tasks, there is likely a problem with the design.

The next two questions are to gauge just how well the apps work in the user’s subjective opinion. Even if two apps are usable, the interface that is more pleasant for the user to interact with likely demonstrates the implementation of better design philosophy. Was it easy? Was it pleasant? Design languages that achieve high scores here should be used moving forward.

The last question was a chance to gather information that I haven’t accounted for or which cannot be answered with multiple choice questions. If users find that the experience was easy, but unpleasant, it will be useful to know why. Furthermore, the chance to gather opinions that I hadn’t thought of ahead of time is valuable. I want to learn as much about users’ opinions as possible.

Results

With the limited sample size, it is quite difficult to draw meaningful conclusions from the raw numbers in the surveys. The average response for the question “On a scale of 1 to 5, how easy was it to complete these steps?” ranged from 3.67 to 4.00 out of 5. This difference, given that each Android app only received four responses, is not substantial.

There isn't a substantial amount of variance given the small sample size There isn’t a substantial amount of variance given the small sample size

Similarly, the average responses to the question “On a scale of 1 to 5, how appealing was app’s interface?” for each app do not vary by much. It may be worth looking at the spread of the answers, though. Both iOS apps received answers of 2 whereas the Android apps did not go below 3 for any of the questions. Whether this is due to expectations set by other apps or a direct difference between the apps is difficult to tell.

The averages are quite close The averages are quite close

The most valuable feedback may lie in the open ended responses to the question “What are your thoughts about the layout, design, and functionality of the app?” One respondent stated about the navigation drawer in PocketGuard for Android that

“The approach of a list helps make this kind of information quick and simple to find, the user knows what they’re looking for.

So although navigation drawers are not popular among vocal interface designers, there are still users who like the organization they provide. A user of the Todoist for iOS app stated

“the home page leaves the user with nothing to go after. Pressing the back arrow to get to all the tabs I need it silly.

This back arrow is replaced with a navigation drawer in Todoist for Android, so it is possible that even though navigation drawers keep many app features out of sight, people have grown used to them and expect them to be available when navigating around the app.

Limitations

This study did not look beyond the bias that users will have to the platform they already use. As people used their own devices, they will be more familiar with the design language used by that device. Users may be more likely to see the designs in a positive light as they are already familiar with the styling.

Though, it is also possible that the the operating system may set certain expectations for the user that the app does not reach. There is no quantitative way to establish how well the applications follow design guidelines. Someone used to default Android or iOS apps may be more or less put off by a small deviation from the standard. Though these apps both do follow guidelines on their platforms, they cannot be perfect. They are not programmed by Apple or Google themselves. My hope is that the results are still useful because both groups will be familiar, so hopefully the better design will be more preferred anyway.

The sample for this study was also far from ideal. The sample size was small and not at all random. It consisted of students attending college who are going to share a perspective which is, at the very least, somewhat similar. It was very difficult for many people to take part in the survey because it was quite time consuming and required users to create accounts for the services.

The small sample size also made errors in any respondents’ surveys sway results more. The simple mistake of choosing the wrong operating system when prompted would render the results from that survey completely useless. Catching these mistakes though, is difficult. The best way to overcome them is with a large sample size so that the surveys that were answered properly drown out those with mistakes.

Ideally, this survey would be sent out to a completely random sample including anyone who uses a smartphone that is capable of using recently updated applications. In the future, if I had a budget to spend on gathering samples, services such as UserTesting would serve as excellent tools to get opinions from a wider range of users with a larger sample size.

Another factor I overlooked was the ability to use tablets. This was intended to focus on phone operating systems to keep things as consistent as possible. However, Todoist is available as a tablet app. Interacting with a larger screen will change the experience. Although the app’s features are still the same, the layout is different for tablets and phones because screen real estate is so much more valuable on a phone.

Where To Go Next

From here, in a future experiment, I could design an app that takes into account the responses that users had and design app that highlight features of each design language. Users liked the simplicity of PocketGuard and found the complexity of Todoist confusing. Separating functionality into menus also helped. By keeping these features in mind, I’ll be able to make the applications follow user expectations more closely.

Further research could also involve comparing two design languages, perhaps Google and Apple’s again, but with users who do not use either. Though the Windows phone is not very common, there are still users who use them and are not used to either Android or iOS. These users could provide a more neutral sample to test Android against iOS and see what features make sense to new users, and which features impede a new user from learning an interface.

Apps specifically built to test these differences in design could also be kept much simpler. Todoist is a very full featured app targeted at professional users who need to organize a large task list across many different projects. For most people, it’s more organization than they need. This makes it less approachable than for example, the built in iOS app, Reminders.

Apple's Reminders is much simpler and easier to learn than Todoist, though with less organization Apple’s Reminders is much simpler and easier to learn than Todoist, though with less organization

Further studies with these custom apps could also focus in on individual features. How do users respond to two apps that are exactly the same, bar a change from a tab organized layout, using tabs at the bottom of a screen, to a navigation bar layout, using a simpler, navigation setup from the top of the screen? How would users respond to the same layout, but with added transparency to give the app a more “airy” feel? Focusing on each feature that holds large differences between design guidelines would produce a much clearer picture of what makes an app usable.

Furthermore, Windows Phone in itself could be an interesting topic to study. The design language is distinct from both Android and iOS. The lack of shadows and the use of a tile system would be foreign to most iOS and Android users.

What I’m Taking Away

I’m not an experienced developer. In fact, I’m just jumping into this. Having just started to learn to program a year ago, and only having made two finished iOS apps under the guidance of online programming courses, this project has served as a major lesson to me. I initially had the goal of using this research to inform the development of my own apps to test in surveys, but given time restraints, I found that such a goal was unrealistic. I just don’t have the experience or skill to turn around two major projects that quickly. But I have taken this time to learn the Swift programming language and familiarize myself with established app design practices.

One major thing I learned myself through this practice ties in well with the research I did complete. Even though I found finishing an app to be more time intensive than I initially thought, the established pattern for building apps, model-view-controller, lends itself well to interface changes. The core of the pattern is that the interface should be independent of the data structure underneath. The user sees and interacts with the interface (the view and the controller) and the interface then interacts with the data through the model. Because these structures are independent, an interface can be revised to be more user friendly without requiring that the model be edited at all. This code can be left entirely alone.

TreeHouse's iOS course highlights the model-view-controller paradigm and it's ability to keep logic organized TreeHouse’s iOS course highlights the model-view-controller paradigm and it’s ability to keep logic organized

So why does this matter? Once the minimal viable product of an app is finished, the user interface can be focused on without worrying about rendering the data model unusable. I can use the research I’ve done here late into the production process. I don’t need to worry about the interface design from the start. If the model is designed well, the interface can be built to work with that model and be edited until it fits users’ expectations. In fact, this idea of building an a core data model with a user interface built over it is perfect for cross platform development. Microsoft’s Xamarin Studio allows for a single code base for apps that work across Android, iOS, and Windows Phone. The user interfaces do need to be designed separately, but if the aim is to match user expectations, this might be for the best.

For Future Developers Who Find Themselves Where I Am.

At the time of writing this, I can’t speak with volumes of authority. My intention was primarily to write a piece that would help people who are where I was when I started to set themselves on the right path. The primary lesson I learned though lies deeper within the app design. Keeping the data model independent of the interface will be what enables you to fix your interface.

Following this research may help you design an interface that users find intuitive and pleasant to use, but ultimately user expectations will probably change. iOS has, for a long time, been seen as a well designed operating system, but iOS 3 would be nothing short of unacceptable compared to what we use now. User interface conventions will change. What users expect will change. And therefore, your app should change, but this will be dramatically easier if you follow the model-view-controller pattern properly.

User expectations lie at the core of designing an intuitive user interface. So long as these expectations are fluid, the major goal of any developer should be to design something that works now, but is adaptable for later.

The Elusive Intuitive User Interface was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Elusive Intuitive User Interface

Cool stuff, every week

More Articles