Designing for Mobile App UI Approaches

Introduction

WebView allows you to release a feature on web and mobile at the same time by embedding the feature’s web content inside native screens of the Workday mobile app. A good WebView experience relies on a Web UI that is not just responsive to the screen size, but designed to emulate the native app experience, like supporting gestures, larger type, and usable use of space. It’s easier and more efficient to design for WebView at the same time as designing for Web rather than try to rework a browser-optimized experience for the native context later on.

Before designing for WebView,

• Understand what a WebView is.
• Understand Mobile App Design Best Practices.
• Follow the Mobile Design Process.
• Find and test your WebView.

Using Figma

When designing for WebView, the components you use and layout changes you make will be driven by whether your web task is Bespoke Web UI or Generated Web UI:

For Bespoke WebView

• Approach: The App Designer owns domain expertise and partners with a Mobile Designer, who leads or pairs on the WebView design.
• Intent: The idea is to modify Web elements to emulate the look and feel of mobile components in the Canvas Mobile Library.
• Resources: Use templates from the WebView Templates and Best Practices Figma. If you are using any Canvas Web components, some already adapt to be device friendly, but others you may need to enhance, which are detailed in Canvas Component Considerations for WebView.

For Generated WebView

• Approach: The App Designer leads design, consulting with the Mobile Design team as needed.
• Intent: Because Generated WebView displays XO components, full mobile mocks aren’t needed alongside responsive and web mocks. Instead, focus on addressing any native vs. responsive differences in Navigation, Headers, Modals, Forms/Inputs, Layout, Accessibility, and Native Capabilities, which are detailed in the next section. Use Mobile Preview to find gaps in your WebView and apply this guidance to resolve them.
• Resources: Use the WebView Figma Library, which contains XO components that adapt to the WebView context, and the WebView Templates and Best Practices Figma. Some components already adapt to be device friendly, others may need improvements, and still others may have challenges that can’t be fixed right now, which are detailed in XO Component Considerations for WebView.

Responsive Design vs. WebView Design

Most designers are familiar with the concept of Responsive Web. Is WebView the same thing? Not quite.

Users see Workday’s web features in a desktop browser, a mobile browser (like using Safari on an iPhone), or in WebViews within the native Workday app. To account for app and device paradigms, there are two approaches to design:

• Responsive / Mobile Browser Design: Content resizes, but visually significant changes - such as optimized touch targets or increased typography sizes - are avoided. Navigation follows browser paradigms.
• WebView Design: Content resizes, AND visually significant changes for touch optimization (which may be “breaking changes”) are implemented. Content display should be optimized for less scrolling and and elements that conflict with native app navigation should be removed

When designing for WebView, your job as a designer is to ensure that your responsive design is adapted to native mobile paradigms so that it can blend in seamlessly with the native app environment. (See the following guidance in presentation form in the following RAD Experience Showcase (first 20 minutes of Meeting Recording Y1BB=P!4, Slides Your Next Feature is a Mobile Feature: Designing for a Hybrid World)

Navigation: Single-Page App vs. a “Stack of Views”

Pre-read: Content Structure Best Practices, Navigation Flow Best Practices

Responsive web and mobile use different navigation paradigms. Responsive web features may adapt complex content into different “views” with custom navigation between content. Native apps also break content into separate views, but the difference between responsive web and native is in how the navigation between these views is handled. Responsive web features tend to introduce custom navigation features - such as a navigation bar that appears only in smaller breakpoints - while native apps rely on native navigation between distinct views.

The reason this difference is important to WebView, is that if we try to insert responsive Single Page Applications into WebView as is, users would see both the Native Back Arrow and the custom web navigation together and that would create a conflicting experience. Luckily, the WebView framework itself already hides some of the conflicting web content.

Design Guidance: Partner with mobile design to define a proper mobile stack that feels natural within native navigation patterns and to prevent any conflicting navigation elements within the WebView. Refer to the “Navigation” items in our “Mobile Rubric” for further detail.

Headers: Native Top App Bar vs. Web Page Headers

The Native Top App Bar is a key element on every mobile screen that orients titles and local page actions, provides navigation between screens, and handles contextual actions such as search, selection mode, and banners. This Top App Bar appears at the top of every WebView screen and populates with the page title by default, replacing the web page header. The WebView framework also hides the following page header actions, as they are not directly relevant to mobile: export actions (Export to Excel, Export to PDF) and instance information (represented by related actions).

Page-level actions like search, filter, or selection in the page header pose a challenge. The Native Top App Bar only supports one-way communication with WebView features. Actions not directly manipulating page data (e.g., links, new modals) can go in the native Top App Bar. However, actions that directly manipulate page data (e.g., filtering, selecting) cannot be placed in the Top App Bar and must be inserted into the WebView page body.

Design Guidance: Best practice is to use the Top App Bar for short curated titles and place longer or customer configured titles in the body. Note that this can only be configured in Bespoke WebView currently; XO populates any page title in the Top App Bar by default. Actions that directly manipulate the page data should be displayed in the WebView page body. Refer to the “Page Header” items in our “Mobile Rubric” for further detail.

In-Page Modals: Ensure Overlays are Visible

Mobile and web modals differ somewhat due to content structure and screen size. Smaller web modals are often technically part of the page content, so a browser back button exits the entire page and modal together. In contrast, Mobile modals “stack” on the screen and must be dismissed first to return to the underlying screen, preventing disorientation on small screens. Currently, WebView modals cannot “stack” to emulate this behavior, so it is important to ensure that WebView modals have a visible overlay (called “dimming” in native contexts) to differentiate them from page content. Their overlay only dims the web content and not the Top App Bar (in contrast to native mobile). This cannot be modified on WebView, so it is important to add enough space between the Top App Bar and the top of the modal so the overlay is visible and users can differentiate between modal navigation (to close the modal itself) and Top App Bar navigation (which close the task as a whole).

Design Guidance: Ensure that in-page web modals display with enough margin to allow the overlay to be clearly visible in WebView. Ensure that full-page modals display as a new page in the native stack. Refer to the “Navigation” items in our “Mobile Rubric” for further detail.

Full Page Modals: Ensure Clear Navigation

Pre-read: Navigation Flow Best Practices

In native contexts, full-page modals are used for in-depth content or complex tasks, such as forms, multi step processes, prompts, or video content. On web, complex tasks may appear in full-page, card-size, or side-panel modals, while mobile forms appear in full-page or bottom sheet modals.

Full-page modals in WebView can display without an overlay and be mistaken for in-page content. They result in conflicting navigation paradigms, where the navigation in the Top App Bar closes the task, but the navigation in the full page header, displayed just below, dismisses the full page modal.

Design Guidance: Ensure that Full Page Modals display as a new screen in the native stack to avoid conflicting navigation paradigms and to make use of native navigation. Full page XO WebView modals are displayed as a new screen by default, but Bespoke full page modals must be configured to display as a new screen. Refer to the “Navigation” items in our “Mobile Rubric” for further detail.

Forms and Inputs: Design for Fingers, Not a Mouse

Pre-read: User Input and Interaction

On responsive web, forms and inputs assume a keyboard and mouse. An input field might be focused for keyboard entry at the same time it’s ready for a mouse click. Native apps, however, are optimized for a single input method at a time: either selection with a finger (like a date picker) or the on-screen keyboard (like a text field). You can learn more about native forms here. This is a subtle difference, but the problem it poses is that a standard web form in WebView may pop the keyboard up unnecessarily, often covering the screen after a user has already made a selection from a picker.

Additionally, a desktop’s single fixed keyboard is optimized for large amounts of text input. On mobile however, large amounts of typing can be much more difficult. To facilitate data entry, mobile offers different keyboards for different contexts, such as an alphanumeric, numeric, punctuation, or email address keypads, as well as custom action buttons for different contexts, such as searching, filling out a form, or writing an email.

Finally, desktop contexts generally afford enough screen real estate that form controls such as Submit and Cancel stay persistently visible without fixed placement. On smaller screen sizes, however, these important form controls may scroll out of view. Native iOS and Android generally place these actions in the Top App Bar to ensure that these important actions are persistently visible. In WebView, form actions cannot be placed in the Top App Bar since they control elements on the page. Instead, ensure that form actions are persistently visible at the bottom of the form and do not conflict with the device’s home indicator.

Design Guidance: Test forms in Mobile Preview or mobile simulators with the keyboard visible. Refer to the “Interaction” items in our “Mobile Rubric” for further detail.

• Use a single, correct picker or keyboard per input field (native if possible). See Component Considerations for WebView for recommendations for specific XO and Bespoke inputs.
• If possible, ensure inputs invoke the correct Keyboard and use the correct Return Key Type on native mobile devices. (Resources: Component Considerations for WebView, iOS Keyboards, iOS Return Key Types, Android Keyboards, User Action Button).
• Ensure that form actions are persistently visible at the bottom of the form and do not conflict with the device’s home indicator.

Layout: Predictable Content vs. Long Scrolling Pages

Pre-read: Layout and Organization Best Practices

Responsive web pages often simply resize and stack existing web content, creating long scrolling pages where the user has no idea what’s at the bottom. Native app layouts are opinionated and will often remove or shrink content (like large decorative images) to reduce scrolling and prioritize key information. Native pages also support horizontal gesture-based scrolling such as carousels, to maximize screen real estate. On mobile devices, users will scroll, but only if they expect to find useful content.

Takeaway: Adapt the page layout to ensure that users can understand the page’s purpose and find key content without scrolling. Follow app-specific spacing and gesture guidance. Refer to the “Content and Layout” items in our “Mobile Rubric” for further detail.

Accessibility: Connect to Native Settings

Pre-read: Usability (Accessibility) Best Practices

In the same way that browsers offer accessibility tools such as screen readers, screen magnification, text resizing, and custom color contrast, native devices offer users accessibility customization tools. To ensure an accessible WebView experience, ensure that your feature:

• Responds to device text resizing options (generally requires sizing in REM).
• Responds to device color contrast options.
• Can be used with a native screen reader.
• Has touch targets on interactive features that are at least 48px by 48px.
• Uses font sizes that are at least 14px.

Takeaway: Test your feature in a mobile simulator with relevant accessibility tools such as VoiceOver (iOS) & TalkBack (Android) and settings such as text resizing. Ensure that all interactive elements use proper touch targets. Refer to the “Accessibility” items in our “Mobile Rubric” for further detail.

Native Capabilities: Ensure Seamless Integration

Pre-read: Mobile Context Best Practices

A key benefit to using Workday’s native app over the mobile browser is that users can tap into native mobile features such as the camera, folder storage, photos, location services, and notifications. Examples of this include:

• Opening the native camera on an attachment widget
• Opening the Phone app when tapping a phone number
• Converting “Export to PDF” to share icons
• Defaulting a current location into a 311 request form
• Etc

Design Guidance: Determine whether your feature should make use of native features. If it should, test your feature in a mobile simulator to ensure native features are seamlessly integrated. Refer to the “Native Features” items in our “Mobile Rubric” for further detail.

Before Design

• Understand what is Bespoke Native UI
• Understand Mobile App Design Best Practices
• Follow the Mobile Design Process

Using Figma

Use the Canvas Mobile v1 Figma Library and consistently reference Canvas for correct component usage guidance. This library contains iOS and Android versions of Canvas components, meaning they were built on platform conventions for mobile-specific behavior, usability, and performance while mirroring Canvas style and language.

Before Design

• Understand what is Generated Native UI
• Understand Mobile App Design Best Practices
• Follow the Mobile Design Process
• Evaluate your current experience: Find and Test Mobile Features

Using Figma

For creating new designs or design adjustments, use the MAX Generated UI Figma Library