Designing for mobile: Principles, Patterns and Guidelines
--
Early last year Backbase updated their design model and moved away from designers who were dedicated to specific platforms to a model where every designer is responsible for end to end, cross device experiences. This meant they were now designing for both desktop web, mobile web and native mobile apps.
As part of the design team I was recruited to share my collective experience designing for mobile, provide guidance, outline principles and best practices. I slowly learnt that there was a wider group of colleagues ranging from product managers, product owners, researchers and senior management who didn’t fully understand the nature of designing for native platforms and device capabilities.
Looking back at my career, I recalled that this isn’t the first time that I’ve had to help and mentor my colleagues. I’ve done the same thing at other workplaces as well, which prompted me to share some key points on frequently asked questions around native mobile design and patterns. Before I start, I’d like clarify that this isn’t me telling you how to design. My intent is for this to be a starting point or reference aimed at getting you started with native mobile design.
Principles
Follow platform guidelines
When designing for native mobile, it’s important to understand that you’re designing for different platforms. Make it a point to research and read up on each platforms guidance, components available and best practices. When in doubt, refer back to those guidelines. Much like this article, use those guidelines as a starting point and then dive deeper and keep up to date with each platform as the guidelines get updated and new sections added with each major OS release.
Lastly, download their kits and detach the components to learn how their design teams have set them up. You’ll be surprised how much you can learn by taking those components apart. Give it a go!
Sketch iOS 14 kit: https://devimages-cdn.apple.com/design/resources/download/iOS-14-Sketch.dmg
Figma iOS 14 kit: https://www.figma.com/community/file/858143367356468985
Sketch Material kit: https://storage.googleapis.com/material-design/downloads/material-design-stickersheet.sketch
Figma Material kit: https://www.figma.com/c/file/778763161265841481
Leverage device capabilities
I’ve been referring to this as native mobile and not just “mobile designs”, because we must always bear in mind that these are apps that run on hardware and operating systems that are different to our desktop computers. This presents us with a plethora of options and capabilities that we can use to elevate our experiences and make them first class citizens of each platform. Think of how you can leverage things like accelerometers, gyroscopes, location services, haptic feedback, bluetooth, push notifications, voice, motion, gestures, SDK capabilities etc…
Design for scale
A common misconception with the term “native mobile” is people think it exclusively means phones. Avoid thinking only in terms of phones. Instead think in terms of size groups.
Less than 7 inches
If you’re designing for something smaller than 7 inches, then you’re for designing for a phone
Greater than 7 inches
Anything greater than 7 inches, and you’re in tablet territory. When designing for this group avoid just copying or using the same design that you produced for a phone. Tablet designs ideally should mirror their desktop counterparts, but leverage the device capabilities, like the ones in the section above.
Thumb position
As you design for scale and cater for different size groups, always keep in mind the easy and hard places to reach when your customers are holding their devices with one hand. Be careful when placing critical calls to action or interactive elements, ensuring they’re in an easy to access zone for the best user experience.
Tap targets
In line with thumb position, another key aspect when designing for native mobile is the sizes of your interactive elements. Our thumbs and fingers lack the precision of a mouse and they cover up elements that we’re about to press. Therefore, it’s absolutely critical to make the tap targets of your interactive elements (buttons, dropdowns, links, collapsible areas, etc…) at the very least 44PT x 44PT or 48DP x 48DP.
Keep the space between those elements (if you have more than one in the same group or area) healthy to avoid the frustration of tapping the incorrect element.
Please note that this doesn’t mean you can’t have slightly smaller looking buttons (e.g. inline buttons), instead what you need to do is communicate with the engineers in your team that you want the touch target height to be at least 44PT. Read up on EdgeInsets and TouchDelegates and pair up with the engineers in your team to understand any complexities or blockers and work together to find a solution.
Use native components
Avoid the temptation to build everything custom. Utilise native components as much as possible. These components are updated by Apple and Google somewhat frequently, gain integration with system services (Siri, Google Assistant, awareness of apps available, etc..) or receive technical improvements. Going full custom means you’ll likely miss out on those updates and incur a high maintenance cost.
Native components doesn’t mean you lose the ability for theming. There are hooks available for you to inject your colours, fonts and branded highlights.
The gains you get by not going fully custom means you can spend time working on components that actually need to be custom and your engineering team will appreciate your pragmatic approach.
One thing at a time
Native mobile users are constantly using apps amidst their daily activities and as such are prone to interruptions. Therefore it’s important when designing for native mobile to always keep this in mind.
To make things easier for your customers, design every screen for one thing and one thing only. Every screen you design for the app should support a single action of real value to the person using it. It will reduce the time required to learn the app and simplify overall user interaction with a product.
This pattern is visible in almost all the apps we use in our daily lives. Look at Spotify, Uber, Slack, Twitter, etc…
Typography
A frequently asked question designers have when designing for native mobile is around fonts and typography. Since the advent of font embedding on the web, using custom fonts has never been easier and has become an expectation on native mobile as well.
Custom fonts
Both iOS and Android support custom fonts, allowing you to embed or use a font delivery service in your native app. As easy as it is to roll your own font, it’s equally important to understand how you app reacts to changes in system font size and the different scaling options you may need to provide to ensure the font is displayed correctly as the size gets scaled (line heights, character spacing, etc…). In addition to that if your native app is available in other languages, you’ll also need to ensure that you have those internationalisation options covered — all things you get for free with system fonts.
In my experience, rolling a custom font into your layouts is simply not worth the development effort or cost. If you really need to use a custom font, use it on headings paired with the system font in moments where you really need your brand voice to shine.
The key takeaway here is to tread with caution and balance the efforts of custom development versus the benefit of adding your custom font.
Font sizing
Closely tied to font scaling is sizing. It’s best practice to follow the platform sizing guidance as each platform has recommended sizes and size tables available for each scale group.
Android: https://material.io/design/typography/the-type-system.html#type-scale
Lastly, also take the time to maintain the correct contrast ratios as outlined in the WCAG2.0 contrast ratio guidelines. Use a plugin like Stark or an app like Contraste to check your ratios as you design.
Guidelines
This list is a small subset of patterns and guidelines that I’ve found designers have been commonly asking around best practices for native mobile.
Tint colour
This is something that stumps designers new to native mobile. This the colour used to denote interactive elements (buttons, links, etc…) in your app. iOS calls it Tint Colour and Android calls it Primary Colour. Ensure your colours match in each platform and you’re all set!
Top Navigation
Both platforms have adopted similar concepts to display the title and actions available for that screen. There are some differences though:-
Title alignment
Android aligns screen titles in the top navigation to the left, whereas iOS keeps them in the middle. It is important to point out that a title is not required at all times, but is preferred to help the user orient themselves.
Sizing
Both platforms provide top navigation bars in a standard and large (extended in Material terms) sizes.
Usage of icons / text / both
iOS uses a combination of text labels and icons, whereas Android prefers icons over labels. Having said that, you can still use text labels in Android if you notice it works better for your customers.
Number of icons
iOS has no strict rules here and some apps adapt to suit their needs, which would be your best option. The most common pattern you notice is 2 icons on the right in iOS, whereas Android allows for a maximum of three
Overflow actions
When you have more than 2 (in iOS) or 3 (in Android) it is common practice to nest these additional options in an overflow menu. iOS uses a horizontal three dot icon and Android uses a vertical three dot icon.
Sticky styling
iOS prefers to use a background blur and a shadow when content scrolls underneath a top bar whereas Android only applies an elevation shadow.
Bottom navigation
Like top navigation, both platforms have streamlined their bottom navigation options and present them in a standardised and unified way with some subtle differences as well:-
Background colour
In Android on the light theme, the primary colour is usually applied as the background and on the dark theme it is the surface colour instead of the muted primary colour.
iOS prefers uses a more neutral colour of white / black for each display mode. Always remember that you can customise the colour in Android if the default of primary (on the light theme) is too strong for your liking
States
Android prefers using opacity to denote inactive states and iOS applies a lighter colour instead of reducing opacity. If accessibility is a concern, I would advice selecting appropriate colours that meet accessibility contrast ratio requirements.
Colour for icons and text will adhere to AA and higher standards if the High Contrast setting is turned on in system settings. However, it’s best not to rely on this and ship with accessible colours and text sizes from the get go.
There is one additional display option available for Android where the title of the active tab is displayed and inactive tabs only display icons. While this looks cool and minimal, I would advice to carefully consider discoverability as using icons alone is not the clearest option.
6 tabs and more
The maximum number of items for your bottom navigation shouldn’t exceed five tabs.
However, as your app grows, you might find yourself in a position where you need more than 5 tabs. A common solution is to introduce a “More” tab and place entry points to those additional sections there. Whilst this is a common pattern, I’d advise that if you do find yourself in this situation, reach out to your research team to facilitate a card sort, tree jack or other research methods to understand how to best organise your IA.
Scroll behaviour & position
On iOS the tab bar is always visible when you scroll. Android affords the option to dismiss it as you scroll.
Scroll position
On Android, the scroll position resets as you move between or return to tabs you’ve already visited.
On iOS though, you have an affordance to remember the scroll position as you move between tabs.
Please note that you need to do some additional work here like storing Y offsets which requires additional work and the way data is fetched also impacts the feasibility of this option (e.g. lazy loading makes this tricky). Speak to your engineers to understand any complexities that may be present and work together to find out a solution.
Menus
There are many ways to present multiple options associated with a single call to action (CTA). This normally trips up designers that are new to native mobile design.
Inline menus
An inline menu is a compact, lightweight menu that appears close to the element that triggered it, without blocking the user.
Android uses the term dropdown menu, which sometimes confuses designers as they think of a <select> element.
In iOS (version 14 and up), you have the option of a similarly themed inline display option called a pull down menu.
Contextual menus
Contextual menus are triggered by a 3D touch or long press on a list, photo or any element that you’ve configured to reveal additional actions wrapped in a contextual menu. Both platforms keep the experience consistent and use the same menu style as inline menus.
iOS by default offers a preview of the element that triggered the menu. You can add this on Android as well, however you’ll need to do additional work so discuss the options available with the engineers in your team.
Edit menus
Edit menus are used when you need to provide your customers with support for cutting, copying, pasting or even undo and redo actions in your native app. Both platforms reveal a menu where the tap happened.
Pickers
This is the component you’d use to display a list of options for your customers to select. In the web world, this is your <select> element.
There are also specific date and time pickers available for both platforms that make selecting dates and times easy. Here’s a breakdown of the options you have available at your disposal.
Date selection — iOS
With iOS 14, you’re able to present your customers with a compact version that takes up little space and expands to an modal view for easy selection.
There’s also an inline version that will expand inline to display a full calendar.
Date selection — Android
Date pickers by default appear in a modal, however you have the affordance of typing in the date or tapping the calendar icon to switch to a modal view.
Time selection — iOS
You have one option which has been updated for iOS14. A time picker now opens with the keyboard allowing you type the time in instead of a traditional wheel experience.
Time selection — Android
Two options available here. By default the time picker appears with the keyboard similar to iOS. There’s also the option to use a “dial” entry that opens in a modal which displays a clock face that allows your customers to drag the dial to change the time.
Sheets
Sheets are perfect when you want to present your customers with additional supplementary content or multiple secondary call to actions or entry points (e.g. Maps displaying a list in line with the places highlighted on the map, Now Playing information, etc…). This is one of the areas where it can sometimes get a little confusing when you’re designing end to end as the guidance varies across platforms.
Android sheets
Sheets on Android are used for a variety of things like presenting contextual actions (edit, share, delete, etc…) or for handing off to other apps (e.g. open in Mail, Notes, etc…) to name a few. It’s an elegant component that scales well for different use cases with 2 display options:-
Non blocking sheet
Allows your customers to interact with the primary content in the background while the sheet is open and visible. It’s best practice here to include a collapse (because its non blocking) action if your sheet can be scrolled or expanded full screen, allowing users to dismiss it easily.
Blocking sheet
Displayed with a dimmed background, this sheet requires users to either select an option to proceed, swipe down on the sheet or tap the dimmed area to dismiss it.
Ideal when you want your customers to carefully consider the options available and focus on them. It’s best practice here to include a close (because its a blocking modal) action if your sheet can be scrolled or expanded full screen, allowing users to close it easily.
iOS sheets
Much like Android, there are two options available.
Card sheet
From iOS 13 onwards, the default way to display modals is with a “card sheet” that can be dismissed by swiping down or tapping a close label or icon. The default presentation is fullscreen with the primary content being “pushed back”. You can still force a full screen modal, you just have to instruct the OS to do so — discuss with the engineers in your team to set it up that way if desired.
Lastly, the only main difference here compared to Android is that iOS forces one display mode which is fullscreen.
Activity sheet
As show in the example above, this sheet is used exclusively for sharing or handing off to other apps in the ecosystem. They’re really powerful as they provide a hub to a variety of actions in a quick and efficient manner.
There are some services that are bundled by default like Messaging, Airdrop and Printing. You can add more and also customise how you populate the right data for custom services. Discuss with the engineers in your team to understand complexity, feasibility and any blockers.
Bottom sheets are fast becoming the preferred way to wrap multiple secondary actions or entry points to other flows in apps. Here are a couple of additional examples from apps in the wild
Keyboards
Keyboards are another common area that designers get confused on when designing for native mobile. You have the flexibility to display different keyboard types and customise the ‘return’ key.
It’s best practice to use native keyboards as much as possible as they’ll automatically be configured to the region your customers have configured their devices to. This is important as this is what your customers will be accustomed to when they need to input data in your native app.
Learn more about the customisation options you have available in each platform:
Android: https://developer.android.com/training/keyboard-input/style
iOS: https://developer.apple.com/documentation/uikit/uikeyboardtype
Switches
A common misconception when designing end to end is mistaking switches as a replacement for checkboxes on native mobile. Resist using switches in place of checkboxes as they don’t map 1 to 1.
A switch is associated with an immediate result — just like in the real world where flipping a switch would turn a light. Checkboxes on the other hand only take into effect after your customers tap a submit button.
Looking around each platform it’s easy to notice where switches are used and their immediate effect when toggled. A few easy areas to learn from is when you turn on Airplane mode or toggle WiFi in system settings.
Empty states
Don’t neglect your empty states. They’re absolutely critical for communicating with your users. Apps often require users to connect to a service to display content, add content themselves, search for content, depend on mobile networks or leverage device capabilities. Therefore your empty states can serve as informative pieces to educate your customers on the state of the application. Here are a few important empty states to bear in mind:-
- Inform customers to connect to a service to display data
- Inform customers to add data
- Nudge customers to enable system services (bluetooth, airdrop, microphone, etc…) to use your app
- No internet connection available or airplane mode is on
- No connection could be established with your server to display data or refresh data
- No data to display due to an empty list (e.g. an empty Inbox)
Chevrons
The all popular interesting > symbol (it’s called a chevron or caret). This is something that confuses designers that are new to native mobile design. iOS uses chevrons liberally whereas Android doesn’t really care for them. As a result you can sometimes see them on both platforms.
Historically chevrons were introduced to promote discoverability (much like those heavy gradient bezelled buttons in iOS 1.0), however as touch screens become more prevalent, I’ve learnt that discoverability isn’t as much of an issue as we all still think it is.
Customers will naturally tap on rows, with or without supplementary information on them. Only use chevrons when absolutely necessary or if you learn that the native mobile app and the target segments you’re designing for really benefit from them.
Transitions
Part of why mobile apps are so enjoyable to use are the transitions between screens. Transitions add a sense of depth, structure and dimension to your app. It’s highly beneficial to understand how and where to use these transitions as you design your mobile journeys. Here are some of the most common transitions you’ll find in most apps:-
Slide in / out
A view is pushed in from the right, most commonly used to enforce a parent — child relationship, and is commonly paired with a back button. It is important to call out that you can go as deep as you want (a pattern called nested doll navigation) but you should balance that with usability and ease of use.
Fade
Reminiscent of 60s TV, this is probably the most popular transition on both desktop and native mobile. The end screen is faded in over the start screen. A common usage of this transition is for presenting dialogs, alerts, dropdown menus, toasts and snackbars.
Fade transitions are usually quick and efficient. Avoid long durations here as they become counterproductive and more distracting.
Pop
Another common transition, where the end screen is scaled and faded in to occupy the full viewport on top of the start screen. Here, you’re playing with the Z-axis and using that axis to essentially “swap” screens. Most common in iOS with the peek and pop transition.
Try a 3D touch (or just a long press) on one of the thumbnails in the Instagram explore page to get a feel of this in a real world app.
Expand
This transition is used for navigating users to a detail page using an item that’s already displayed in a collapsed or preview state. Most commonly seen with list items or cards but not restricted to just those elements.
Try tapping on a featured card in the iOS AppStore to get a feel of this transition in a real world app.
Persistent element transition
A little more complex but seen everywhere is the persistent element transition. As the name implies, this transition “connects” the element(s) from the start screen to the end screen or through a series of screens like an onboarding or registration flow.
Summary
These are just a few guidelines to help you as you embark on your journey designing for native mobile. In the end of the day you’re the designer responsible for the end to end experience, so trust your gut, follow your instincts, don’t be afraid to ask questions or challenge the norm. Always remember to respect the platform, leverage the device and stay up to date with new additions and changes!
