Mobile App Design Best Practices

Introduction

A direct one-to-one translation between Web and Mobile App design is often impractical for users. This is because of fundamental differences in screen size, input (touch vs mouse), and the context of use. For instance, a masonry layout of large image cards on web could be designed as a vertical card stack, a card carousel, or a list of items with thumbnails on mobile; a practical choice depends on the context. The following breaks down how to design for the unique characteristics of mobile devices and ways people use apps. This guidance complements general UX design best practices. When you start a mobile design project, ensure you follow the Mobile Design Process.

1. Core Principles

Use the Platform

The most important practice of app design is using the system components, patterns, and device capabilities of the iOS and Android platforms. This ensures a consistent structure, a fluid user experience, and distinct “app-like” feel, differentiating it from a browser experience. For instance, smooth and swift page transitions when swiping back are a hallmark of an app experience.

Given that many workers switch between Workday’s web and mobile platforms, it is also essential for the mobile experience to visually align with the Workday brand to build trust and coherence.

Workday’s Canvas Mobile components were built on platform conventions while mirroring Canvas Web’s style and language. They should be used whenever possible, alongside consistently referencing the ever-evolving app design guidance from Apple’s Human Interface Guidelines and Google’s Material Design.

Create Focus

Because of the small screen size and the user’s mobile context (e.g., on the go, unreliable connectivity), every screen and every task must be easy and straightforward; one purpose or action per screen, with minimal effort.

Design for Thumbs

The experience must be comfortable and forgiving to use with one’s hands holding a touch-based device.

Adapt to Context

Respect how people use their devices and have them set up. This means supporting device accessibility settings and helping users easily resume tasks after app-switching or interruptions.

2. Content Structure

Define a View Stack for Navigation

In a browser, a single webpage often contains a high volume of content where many things can be done on a single page. While it will resize and adapt to small screens, it is still a single webpage. In mobile apps however, the same content is typically broken into a “stack of view screens” users navigate between. Because users can’t see all content at once, it is essential that each screen be focused with a single purpose and placed in a logical flow.

The most common and effective approach is to break up content into hierarchical (e.g., parent-child) view screens based on its information architecture (IA); well organized IA is key. A good stack offers users a consistent navigation structure, helping users understand the overall scope of content and their current location. Create shallow stacks – users shouldn’t have to drill down more than 2-3 levels to reach core content as every screen adds cognitive load.

Important Note: View screens are for content with a consistent structure. Contextual content should be displayed in modal screens, as they are not part of the core view structure.

Typical Stack

• List/Summary Screen (Parent): A collection or summary of items (e.g., a list of reports or a dashboard).
• Detail Screen (Child): The complete information for a single item selected from the parent list (e.g., the full report content).

Larger Stack Example: Profile

• Summary Screen (Parent): Worker highlights with categories of information about the worker
• Menu Screen (Child): A submenu of a single category selected on the previous screen
• Detail Screen (Grandchild): The complete information for the single sub menu item selected on the previous screen

View screens can also be used for a workflow, if it’s the primary content. An example is a setup flow before getting access to a feature. Otherwise, flows that are self-contained processes, like creating a report, are displayed in modal screens.

Define Modal Screens for Contextual Content

Contextual content is dynamic or situationally relevant to the user’s current screen; it is not consistent content in the view structure above so it is displayed in modal screens. Modals provide a temporary, focused experience and must be dismissed or completed to return to the underlying view screen. Presenting contextual content as modals, rather than view screens, preserves the integrity of the navigation view stack.

Examples of contextual content:

• Self-contained processes: Tasks like adding, editing, requesting, or submitting information, with clear start and endpoints (e.g., Save/Cancel), even if there are multiple screens within the process.

• Complex inputs (prompts, rich text editing, filters) are also a type of self-contained process.

• Articles, contextual help, and announcements: These are dynamic information.

• Detailed instructions on a form: To provide more space for the form itself.

• Lines in a report or table: If dynamic, such as editable Expense Lines in an Expense Report, tapping a line is typically presented in a full-page modal. If the lines only exist as children to one parent view, then view screens are typically used.

Use full page modals for more focus and immersion and bottom sheets for a lighter-weight experience.

Non-Modal Popups

Non-modal popups are for presenting contextual content and actions that do not need to block the current view screen. These include tool tips, confirmations, input pickers, menus, non-blocking errors, etc. Reference Canvas to see how mobile popup components look and feel different from their web counterparts.

Takeaways

• Break content into a stack of views with a single focus or purpose per view
• View stacks are often based on Information Architecture (IA), so clear IA is key
• Create shallow stacks of 2-3 levels
• Use view screens for hierarchical content or consistent defined flows, and use modal screens (full page modals and bottom sheets) for contextual content
• Mobile modals must be dismissed before interacting with the underlying screen
• Non-modal popups (menus, snackbars, banners, etc) are for messages and interactions that don’t block the current view.

3. Navigation Flow

Once content is structured into a clean stack of views and modals, design how users navigate between them using the below standards.

Components to Use

Refer to Canvas for specific component usage guidance.

• Lists, cards, and popups including menus, bottom sheets, and top sheets : Used to navigate to child screens.
• Top App Bar: Used to dismiss the current screen (e.g., buttons to go Back or Close), or navigate a flow (e.g. buttons to go Next, Cancel, Submit, etc.), and also used for contextual action buttons.
• Action Bar: Used when a more prominent and reachable location is needed for important actions (e.g., Create or Submit)
• Bottom Navigation Bar: Reserved for Workday’s top-level destinations (e.g., Home, My Tasks, Menu), offering easily accessible navigation.

Navigating View Screens: Forward and Back

Also known as “drilling down” or “hierarchical navigation”, navigating to a child view stacks the screen on top of the previous screen using platform-specific transitions for both iOS and Android. Each view screen has a native Top App Bar on the top of the screen with a back button. Tapping “back”, swiping from the left edge, or using the Android device back button dismisses each screen, revealing the previous screen in the stack. Unlike typical browser back button behavior, navigating back in an app refreshes data only when a change was made; otherwise, previous screens maintain their prior states and scroll positions so that navigation feels instant and reliable.

Navigating to a Modal

Opening a modal, whether full screen or bottom sheet, also stacks but with a different platform-specific transition for both iOS and Android. On iOS for example, modals slide up from the bottom. The modal dims the entire screen and must be dismissed before interacting with the underlying screen. A Top App Bar is also typically used for dismissing and navigating inside the modal.

Navigating to and from Shortcuts and Links

Shortcuts and links provide navigation to other places in the app. For example, Home has “Quick Actions” to jump to specific tasks and reports. An announcement may also have a link to a task or report. Ensure the following behavior:

• Tapping a shortcut or link will navigate to view screens and modal screens with the same transitions as previously described.
• If the user is currently in a modal screen when they tap a link to go elsewhere, dismiss the modal screen first if the user will not need to return to it.
• Avoid adding links that go back. For example, in deeper hierarchies, it might be tempting to add a link to get back to a product area’s landing page. It’s best to avoid this complexity. If a back shortcut is unavoidable, it must behave like back navigation (e.g., dismiss screens to get back) rather than forward navigation to preserve the content hierarchy.

Navigating between Detail Screens

When users are likely to view multiple detail screens, such as view details of multiple Expense Lines on a report, or details of multiple announcements in a carousel, there is extra effort to go back and forth between the list and the detail views. Consider letting users switch directly between Detail screens using swipes or up/down chevrons, depending on the context. Ensure the view switches without stacking new screens so users stay correctly oriented in the position of “one level down” from the parent page.

Navigating Multi-Step Processes

Display stepped processes like forms in a full-screen or bottomsheet modal experience. Provide a clear way to dismiss the entire experience, as well as navigation between steps when applicable (e.g., Back and Next). When users navigate between steps, the view should switch without stacking screens to maintain the feel of a single, self-contained process in a modal. Exact button placement will depend on use case and build method limitations.

Navigating Tabs

Persistent menus like Tabs also navigate without stacking new screens. They allow users to switch between views at the same level of information hierarchy, within the same screen.

Hub Navigation

On desktop, a hub displays local navigation as a left-hand rail, with the selected page on the right. In the mobile app however, users land on the Overview page with the menu in a dropdown. When users select a menu item in that menu, a new screen stacks on top and displays just the task and a back arrow. Users must dismiss the page to get back to the Overview and Hub menu. Further reading: Design a Mobile Hub - Quick Start

Takeaways

• Navigation transitions use platform-default motion behavior and is based on the type of screen you are navigating to: a view screen or a modal screen.
• Navigating “stacks” each screen, and users dismiss each screen to return to the previous screen
• Avoid providing shortcuts to go back. It is far less cognitive load for users to use standard back/forward navigation in a well-defined 2-3 level hierarchy.
• Navigating back does not refresh data unless a change was made
• Switching views at the “same level” (e.g. between Detail Screens, between tabs, between steps in a multi-step modal form) transitions content within the current screen without stacking new screens
• Further reading: Mobile vs Browser Navigation Examples (Figma)

4. Layout and Organization

Components and Styles to Use

Refer to Canvas for specific component usage guidance.

• Tabs, expandable containers, lists, tables, carousels, cards: Used to organize content and provide navigation to secondary views. The mobile versions look and behave differently from web versions.
• Smaller page margins than web: 24px (space.x6).
• Consistent spacing between elements: 16px (space.x4) between related elements and 24px (space.x6) between sections, with adjustments based on content.

Small Screen Usability

Users know to scroll, but only do it if the content seems promising. And while scrolling is a fundamental gesture, unnecessary scrolling is inefficient and increases cognitive load. To ensure content on each individual screen is easy to find and discover:

• Ensure each screen has a single purpose. This means you may need to break your content into a “stack” of views, where primary content is the first view, and secondary content is moved to subsequent views.
• Streamline decoration. Reduce or shrink low-information value images and decoration so there is less vertical scrolling to higher value content. Example: use a list with thumbnails instead of stacked image cards if the images have low information value.
• Ask yourself if content below the fold is predictable. If it’s not, organize content so that sections are visible above the fold using tabs, accordions, drilldowns (list or table where tapping a row goes to a secondary view), or carousels.
• Use the full screen. Body elements such as cards, inputs, and lists should take up the full screen width within the page margins while backgrounds, artwork, and scrollable layouts like carousels and tables must extend to the screen edges.
• Ensure nothing interactive conflicts with the status bar and system gesture zones. Refer to iOS safe areas and Android edge-to-edge for examples.
• Do not place vertically scrolling body elements inside a view screen in order to avoid conflicting with vertically scrolling the view itself
• Design for the screen sizes and orientations in our Figma libraries
• Design whether the layout needs to change when users increase their device’s accessibility settings.

5. User Input and Interaction

Gestures

Support gestures to enable fluid and efficient interactions and ensure you minimize any unnecessary taps or mistakes:

• Use standard gestures instead of inventing new gestures to ensure familiarity and reduce user cognitive load
• Let users swipe to navigate back and dismiss modals that don’t require action
• Let users tap outside of popups like menus and keyboards in order to dismiss them
• Allow users to easily undo or clear data
• Use large enough tap targets (48x48 minimum)
• Place actions used most frequently in the more reachable middle and bottom areas of the screen
• Don’t design hover interactions
• Allow drag and drop and pasting, if relevant

Forms

To provide a focused, temporary experience with minimal effort:

• Present forms in a modal (bottom sheet for simple selections or full page modals for longer forms)
• Mobile inputs are optimized for touch; choose each input based on the type of content, such as currency inputs, prompts, and time pickers.
• Use the correct virtual keyboards based on input type, such as phone or email. The most common are in the Canvas Figma Resources for iOS and Android, and more can be found in Apple and Google guidance.
• Present complex inputs (e.g., ones involving search, folders of choices, or rich text editing) in a bottom sheet for focus and to avoid overlapping scroll areas.
• Consider if voice, camera, or gestures like drag and drop would be more efficient than inputs.
• Offer a selection instead of text entry when possible
• Use smart defaults and formatting (or non-formatting)
• Per Apple, “get information from the system whenever possible. Don’t ask people to enter information that you can gather automatically — such as from settings — or by getting their permission, such as their location or calendar information.”

6. Performance

Users are less forgiving of poor performance in a mobile app than in a browser. This is because the effort of downloading and installing an app carries an implied promise of superior speed, smoothness, and responsiveness worthy of that effort. Users view a slow app as a failure of the product, but assume a slow website is just network issues. Experience Teams need a plan in place to measure and meet the following standards and designers must use these best practices to optimize their designs for good performance.

Speed

The industry standard is for pages to load in under 2 seconds. Ways to reduce actual and perceived loading time include:

• Optimize assets by using compressed images and SVGs to reduce load weight; avoid unnecessarily high-resolution images that are larger than the display size.
• Use skeleton loaders to create the perception of speed, but only if they match the loaded state. For example, do not use a skeleton for a full list if the loaded list is often short.
• Progressively load content, such as with “lazy loading” content above the fold first, or move less used content and features to secondary views.
• Minimize complex graphical effects, blurs, and layers
• Keep animations short, smooth, and simple (see “Smoothness” below)

Responsiveness

The UI must respond instantly (>200ms) to touch. Ensure all touch targets (buttons, links, and icons) have an immediate visual state change (e.g., a color shift, subtle press effect, or shadow change) upon touch, confirming the tap was registered instantly, even if the action’s result takes a moment to process. Canvas components should have these built-in, but if designing a new component or bespoke interaction, adhere to platform-specific motion guidelines from from Apple’s Human Interface Guidelines for iOS and Google’s Material Design for Android. Avoid creating custom or bespoke animations, and utilize the standard easing, durations, and transitions provided by the respective platform.

Smoothness

Motion helps mobile users stay oriented and understand how content is related. Unexpected transitions or content shifting can cause errors and disorientation, so you must intentionally design for a smooth experience and test it:

• Only use skeleton loaders that match loaded content and transition to it smoothly.
• Design loading so that content won’t shift as it loads so users don’t accidentally tap the wrong item.
• As with responsiveness, avoid creating custom or bespoke animations, and instead utilize the standard easing, durations, and transitions provided by the respective platform.

Refreshing

Never refresh a page when users navigate back unless data changed. This is because navigating back is a constant app experience and it needs to be seamless and efficient. It’s also a platform paradigm so users intuitively expect this experience. By not refreshing unnecessarily, users see their previous states and scroll positions and the experience feels instant and reliable. Unnecessarily refreshing creates loading delays and frustration and over time, this repeated annoyance will lead to users perceiving the entire app as slow and unstable.

In your designs, specify that all pages retain their states and scroll positions when navigating back without data changes. If any cases need to refresh to display changed data:

• Preserve original scroll position, even if whatever changed is not “above the fold”
• Only update what changed in a smooth, visually stable way
• Provide adequate visual feedback of the change. For example, showing, removing, or changing the state of an item. If the item might not be visible, display another indication, such as a snackbar confirmation.
• Do not display a loading indicator when going back unless it’s necessary for showing a change.

7. Usability

Size and Space

Workday uses larger font sizes and smaller, consistent space between elements to ensure readability on a small screen. For example, body text is typically 18pt. For iPad, ensure body elements don’t stretch beyond a readable width of 624px.

More coming soon.

Accessibility

• Fonts must be a minimum of 14px (12px in rare cases) on mobile and respond to device accessibility settings.
• Touch targets on interactive elements are at least 48 x 48px.
• Avoid truncation; wrap text instead. If text must truncate, there must always be a way to access the full text.
• Design whether layout needs to change for larger accessibility settings. As a rule of thumb, use the threshold of AX1 for iOS (this represents larger accessibility sizes) and >1 for Android when designing a layout change. For example, a section title with a right-aligned button may be truncated at larger settings without a layout change; to avoid truncation, allow text to wrap and stack the button below the title instead.

More coming soon.

8. Mobile Context

Mobility and Device Capabilities

Design features that provide useful content and actions on the go, like time-sensitive notifications and real-time data. This allows users to monitor important processes and swiftly execute. With permission, use data from users’ device and environment, such as their location, camera, biometrics, voice, etc. Capabilities are always evolving with new technology so it’s best to refer to Apple and Google documentation directly:
Apple’s Human Interface Guidelines
Android’s Material Design

Privacy

Because mobile phones are inherently more private than desktop computers, privacy masking is generally only needed for security-related elements like passwords.

Sharing

Users often want to forward content to other people or apps, so provide the standard mobile share menu, when applicable.

Interruptions

Mobile usage is prone to connectivity issues and fragmented attention. Include in your design:

• How to resume an interrupted task
• When should a state be saved vs refreshed
• When should users be able to save their state
• Offline/Loading Errors using loading dots, banners, and empty states.