Native guidelines – between conformity and rebellion

What’s the best way to deal with multiple design guidelines on different operating system when designing one product? Do you follow the rules or create your own?

Katrin Sczepan UX Designerin at Fork Unstable Media GmbH

Various challenges arise when designing a mobile app for multiple devices and different operating systems. Each operating system differs greatly through a mixture of interaction and navigation paradigms, performance restrictions and system guidelines and all of them shall be obeyed. On top of these restrictions your company or your client will also have certain design guidelines that need to be adhered to as well.

Especially the native Android and iOS guidelines are an ultimate argument in some discussions, but the accordance to guidelines must not always be the best way to solve the requirements.

The creation of an app basically starts with research about the users and the target group you want to reach out for. The understanding of their interests, needs and experience levels is important to meet the expectations. It’s crucial to keep this information in mind when usage scenarios are going to be discussed, not only at the beginning, but also during the app creation.

Within the first high-level concept work the general focus and product strategy of the app will be defined and after the setup of the information architecture, usage scenarios and technical specifications you will try to fit all functionalities into one model. In general native UI elements can cover a lot of the requirements, but you might also stumble across usage scenarios where they cannot cover them: Maybe you need more complexity or different native paradigms clash with each other or they simply don’t work, meeting the goals of your design strategy.

Loren Brichter’s musing on “pull-down-to-refresh”-gesture teaches us that with innovative forms of interaction we also influence the general behavior and UI elements and it is not only the other way around. Loren Brichter wanted to create a simple and consistent action bar and found out that the refresh icon just was too much to fit in with all the other elements. He invented the behavior to reduce the elements in the action bar and it worked out: people accepted the intuitive gesture and it is implemented in a lot of other apps. We don’t have to obey all the rules, sometimes we have to make them ourselves.

Usually the iOS app navigation is a bottom bar with icons and some text. The amount of elements is limited by the width of the device, the icons need to be at least 44 pixels in height and width etc.

• SPACE: The bottom bar takes in space and if the app provides limited functionalities it doesn’t make sense to waste the space for only 3 items.
• PRODUCT FOCUS: The app concentrates on the consumption of content, rather then actions – but anyways the necessary actions are reduced to a minimum and are still directly accessible.
• DESIGN APPROACH: The app has a very visual approach, instead of showing titles, subtitles, descriptions, prices etc. (like ebay), it only displays photos and let them speak for themselves, so why not show as much as possible?

There is a native guideline and code example Apple recommends to use for edit menus:

• INTERNATIONAL: The app is international and therefore it all navigation text elements are reduced to a minimum – no text, no translations.
• ICON LANGUAGE: Pinterest formed its own icon language, the icons are used throughout the app. There is a learning effect and why not be consistent also within the edit menu?
• DESIGN APPROACH: Pinterest has a reduced design with a strong focus on consumption. They trust that most of the icons used are self-explanatory, if not the user can explore them without any damage to anything.

Pinterest and Stuffle go a different way, which works, is nice and all necessary actions are easily accessible. Finally they differentiate in a landscape of uniformity.

• What is the basic design idea?
• What is the product focus and strategy?
• Do the existing UI elements help the intention of the user?
• Is it possible to express design and UX needs with existing UI elements?
• Consistency: Is another solution more consistent with your concept and design approach?

If you create your own elements or invent new interaction behaviors, it is necessary to test them. User tests help to recognize critical situations in the user experience and to understand the questions users have. Also it doesn’t always have to be an expensive and elaborate user test. Tests with smaller groups and paper prototypes work out as well.

Coming back to Loren Brichter: The story about the “pull-down-to-refresh” gesture also shows that people are able to learn new behaviors. I therefore recommend in some cases not to judge too quickly if users have difficulties – if you believe in your solution, also support it with a tutorial.

During recent project work I learned that native guidelines are overall principles to enable a uniform interaction within the operating system and it is good if we can apply them on our products. If you can cover all functionalities with native UI elements – than…well that’s great! But they should not be regarded as unalterable rules, they are guidelines, they are fluid and changing and they should help to enable a great user experience.

If native guidelines are applied too easily over all apps, we receive a landscape of apps, which will all look monotonous and we would miss our chance to challenge them, to improve them. Rather than blindly following the rules, it is advisable to question those rules from time to time. Strive for simplicity, ease-of-use, and attractive and characteristic design. Be brave and explore!