Mobile

Introduction

Mobile access is more valuable than ever, with 38% of Workday’s monthly users coming from mobile devices as of September 2025. Introducing features into the mobile app is also significantly easier with tools like Mobile Preview, improved design resources, and the option to use WebView to embed web tasks into the app. Because of Workday’s intertwined technology, considering the web and mobile experience simultaneously is crucial. Use these comprehensive guidelines to understand, prioritize, and design features for the Workday mobile app alongside the web experience.

What is Mobile at Workday

There are two ways workers access Workday on their mobile devices:

• Mobile App (25.6% of monthly Workday users): The Workday Mobile app, available in app stores, offers key Workday features in a superior, more performant, and fluid experience due to OS-based technology and device capabilities. It’s free but requires customer enablement. Workday has separate iOS and Android apps maintained by corresponding platform developers, with the iOS app also supporting iPad. The Mobile Experience Design Team governs the apps’ design.

• Mobile Browser (12.4% of monthly Workday users): Workday’s web experience is viewable in a mobile browser, with many features being responsive. Responsive UI design adapts a single web design to various browser sizes, sometimes specifically for mobile browsers for better readability and gesture control. Historically, Product Experience, UIPlat, and Canvas Web Design teams have handled Responsive UI.

Mobile Value

Desked and deskless workers alike appreciate the Workday mobile app for these top reasons.

• Portable, Instant Access: Workers, and managers in particular, situationally depend on mobile access for its convenience, such as when they are “on the floor” at work, at home, or on the go and need to do something for themselves or for their team in the moment. Mobile access affords them flexibility, privacy, and autonomy. Additionally, Frontline-specific workers and managers rely on mobile because they are more likely to have limited or no access to computers at all. In fact, 5.7M users (almost 15% of all Workday users) are “mobile-dependent”, meaning mobile is the ONLY place they access Workday.

• Time Savings: The mobile app is quicker to sign in and quicker to action for many user needs, especially simpler tasks. For example, it’s 78% faster to complete an expense report, 30% faster to check pay, and 32% faster to check in/out than doing these actions on a desktop computer.

• Simplification: Mobile-specific affordances reduce steps and complexity to get things done, and enable interactions only possible on a mobile device. For example, gestures make interactions fluid and efficient, camera enables receipt scanning and adding a profile photo, push notifications accelerate time to complete required actions, and microphone is essential for name pronunciation and dictation.

Example problems solved:

• Delayed Actions: such as time to fill jobs, approve requests, complete learning, give feedback, and see Announcements

• Privacy Concerns: worker reluctance to do private tasks on shared computers (find and apply to internal jobs, check pay, benefit enrollment).

• Worker Distraction: in settings like retail and hospitals, workers get preoccupied with planning when and how to take care of HR tasks when they have limited access to a computer. This distracts them from their primary jobs

• Excessive HR/IT Help Tickets for the same simple requests (ie, get payslip)

• Excessive Effort for HR to help workers that are home sick, on leave, at the bank

Features that Belong in the App

• Features that leverage mobility
  • Providing useful content and actions on the go, like time-sensitive notifications, real-time data, location-based content, etc.
  • Allowing use of device capabilities like camera, voice, swipe, etc
  • Providing privacy
• Quick actions (<30 seconds) or longer actions that are usable
• Features with significant usage on Mobile Web–moving to the app provides better performance and UX. PMs have this data, and it’s also available in Tableau.
• Features for people that depend partially or wholly on mobile (workers and managers, especially Frontline in Retail, Hospitality, Manufacturing and/or Healthcare industries, doing tasks for themselves and their teams)
• Anything that can be made usable on a small screen

Instead of considering whether a whole Job-to-be-done or Critical User Journey should or should not be done in the app, consider each step of your user’s journey individually to decide. This will ensure that the mobile app has the “right parity” with desktop that feels complete to users.

Plan for the Mobile App Now, Not Later

In the past, Product teams prioritized building web experiences first, sometimes including responsiveness and gesture support for the mobile browser, but would often deprioritize or delay introducing features in the mobile app because of unclear value or high cost.

Today, it is far more valuable and easier to introduce features in the Workday mobile app at the same time as on desktop. Today’s workforce is increasingly dependent on mobile devices due to the rise of remote and hybrid work, the expansion of the gig economy, and new technologies. Mobile performance and versatility has made tasks that were once only usable on a computer increasingly easier on mobile. And now that Workday Product Teams can use WebView to add features to the mobile app, Workday has greatly reduced the high cost and dependency on the Mobile Organization to deliver features.

So unless your feature truly requires significant real-estate from a user point of view and cannot be made usable on mobile, there is likely user value on mobile and you should plan your mobile experience at the same time as your web experience.

The Importance of Simultaneous Web and Mobile Design

Because of Workday’s intertwined technology, mobile design at Workday is best done at the same time as web. This is because design and implementation decisions for web features often dictate or break the mobile experience and can be extremely difficult to change later. For example:

• When a feature is Generated on web and mobile (ie, shares an XO task), a change to the XO task will break the mobile experience if it uses a component that mobile doesn’t support well.
• When a Web feature is displayed in the app via WebView, the mobile experience will break if the web content contains components that don’t adapt to mobile or if they have navigation links that conflict with the app back buttons.
• When a mobile feature is a different Task ID from the web version (common when the mobile feature is Bespoke), any web-only enhancements will create disappointing functional gaps for mobile users.

Whether designing a new feature or enhancing an existing feature, these constraints are more easily accounted for and addressed more efficiently if designed at the same.

How Mobile Features are Built

There are three ways that features can be built in the Workday mobile app. Your Product and Engineering partners will often control the final decision on which method to choose, but User Experience does vary between them and should be an important factor in the decision.

WebView (for Most New App Features)

This option allows Product Teams to introduce features into the mobile app without needing Mobile Development. If teams have an existing web task with quality responsive design (whether it’s Generated XO UI or Bespoke UI), the Mobile WebView Framework can seamlessly embed the Workday web content inside native screens of the mobile app.

• Generated WebView: Refers to Generated (XO) web tasks displayed in Webview

• Bespoke WebView: Refers to Bespoke web tasks displayed in a WebView

It’s important to know that Responsive design is not the same as App Design, so Product Teams using this option may need to create WebView-specific designs to ensure their Responsive UI is usable when displayed within the app experience.

• Short video comparing Responsive vs WebView Design (pw: Y1BB=P!4). A must watch!

• Preview Your Feature in Webview to see how it looks out of the box

• Designing WebView

• Developer Documentation for more about how it works.

Bespoke Native UI

Bespoke Native development is reserved for high-value features that need interactions or performance that cannot be achieved with the other development options. Bespoke development relies on the Mobile Engineering teams to build Native Mobile UI custom per platform (iOS and Android) in platform-specific development languages (Swift and Compose). In the past, Bespoke UI was mostly coded from scratch and not reusable. Now, Bespoke UI can use Canvas Mobile components and tokens.

• Designing Bespoke UI

Generated Native UI (aka MAX)

This is an option for Product Teams with an XO task and should be used when other options are not possible. Much of the app was originally built many years ago with Mobile Application Xpresso (“MAX”), which automatically converts XO tasks to native mobile UI at scale by rendering predefined MAX widgets. It’s important to know that not all XO components have a corresponding mobile MAX widget. Additionally, while some of these widgets have been uplifted to match Canvas mobile components and styles, investment in MAX has been largely scaled back so enhancements are hard to come by and certain elements may be less usable or stylistically out of date. Product Teams using this option must always test how their task renders on mobile to see if it’s supported and usable and update their XO task accordingly.

• How to test your task in MAX to see how it looks out of the box

• Designing Generated UI

Comparison

Each option comes with pros and cons related to use case, design flexibility, and development effort.

For a simple way to choose based on the experience you want, use the following simple decision tool: Mobile Implementation Decision Tool

Mobile Design Process

For any RAD Experience Designer starting a project, incorporate these steps into your normal design process to determine if the mobile app is relevant to your project, and to plan accordingly.

Required

1. If you’re enhancing an existing web feature, see if it already exists in the mobile app. Web changes can break the mobile app experience or create functional gaps, so you must plan to do no harm.

2. If you are introducing a new feature, see if any part of it belongs in the mobile app.

3. If you answer yes to either above, continue the Plan section.

Plan

1. Get a Mobile Specialist Partner

   • Reach out to Philip Donal Dwyer on the Mobile Experience Design Team. He will assign a Mobile Specialist to help choose a build method, provide guidance on design and testing, provide design for Bespoke features, and review designs.

2. Choose a Build Method (for new features)

   • Work with your PM to choose how to build the feature on mobile. If the task already exists on web, you may be able to “preview it on mobile” in WebView or Generated UI and use the Mobile Rubric to determine what enhancements might be needed

3. Plan Design Roadmap

   • For features being delivered on web and mobile, work with Product PM to ensure time for simultaneous design, even if development isn’t simultaneous.

4. Define Design Roles

   • For Bespoke Native and Bespoke WebView features (refer to build methods): the Mobile Specialist will pair or lead design, and the Product Designer will lead domain knowledge

   • All other projects: the Product Designer will lead design with the Mobile Specialist consulting and reviewing

5. Have a design kickoff

   • Product PM identify Mobile PM as well as any applicable Engineering partners

Design

1. Understand App Design Best Practices

2. Use the correct figma libraries and guidance specific to how the UI is built

3. Create designs for both iOS and Android, including iPad where applicable.

   • Maintain consistency; only create differences when necessary for platform-specific elements (e.g., iOS vs. Android pickers) or for usability (e.g., readable content width on iPad)

Review

1. Evaluate the quality of designs with the Mobile Rubric.

   • All features must meet the minimum requirements. They can be captured in a Mobile Rubric Jira

   • Features that specifically leverage mobility (real-time info or actions on the go, device capability, privacy) or is a Workday Front Door (login, onboarding, or an L0-L2 landing page) must plan to meet all requirements.

2. Secure design approval for any new components or Bespoke design using Canvas Mobile Office Hours.