ServiceNow Mobile Experience Best Practices

Design for Mobile User Workflows

Best practice: design mobile experiences for mobile use cases, not desktop scaled down. Mobile users often work in different contexts—field workers in remote locations, managers traveling between meetings, support staff in noisy environments. Their needs differ from office-based desktop users.

What good looks like: field workers can quickly access relevant information without lots of navigation, managers can approve decisions from anywhere with one-handed operation, support staff can resolve cases without switching between screens. Mobile UI is optimized for touch (buttons are large, gestures work), fonts are readable in low light, and workflows are streamlined (fewer taps to common actions).

What to avoid: cloning desktop interfaces to mobile (too much information, too many clicks), requiring fast internet (mobile apps should work in low bandwidth), and using fonts too small for field workers wearing gloves (can’t tap accurately).

Optimize Performance and Reliability

Best practice: mobile apps must perform well even on older devices and slower networks. Many field workers use older devices or unreliable connectivity. Apps that work only on fast, new phones are unusable in many environments.

What good looks like: app loads quickly, actions complete without a long wait, app works in offline mode for common actions (view cached data, create records), and app recovers gracefully from network interruptions (doesn’t crash or lose data).

What to avoid: assuming all users have fast internet (many don’t), using large images without compression (eats data), complex animations that stutter on older devices (makes app feel slow), and assuming always-on connectivity (plan for offline scenarios).

Implement Offline Capability Thoughtfully

Best practice: support offline scenarios where users can work without internet and sync later. This is essential for field workers in remote locations. However, offline adds complexity—data consistency, conflict resolution, sync failures. Implement it thoughtfully.

What good looks like: users can view cached data and create records offline, app syncs when connection returns, conflicts are resolved automatically (or escalated if can’t be auto-resolved), users see clear indication of sync status. Offline works for common use cases; rarely-used features can require online.

What to avoid: offline without sync (data changes locally but never reach the server), offline without user awareness (user creates records offline thinking they’re saved, but they’re only local), and complex conflict resolution that requires user intervention for every sync.

Streamline Approval and Signature Workflows

Best practice: if your mobile app handles approvals or signatures (common use case), make it streamlined and secure. Users shouldn’t need multiple screens to approve a single record, and signatures should be genuine (not fakeable).

What good looks like: approval decisions are one tap, signature capture is straightforward (draw on screen or via biometric), audit trail records who approved when and what changed. Users understand they’re committing to a decision.

What to avoid: unclear approval workflows (user doesn’t realize they’re approving), weak signature implementation (screenshot as signature isn’t secure), no audit trail (can’t later verify who approved).

Secure Access and Credential Management

Best practice: mobile apps must authenticate users and protect sensitive data. Many mobile use cases involve field workers who may lose or have phones stolen. Security must be strong without being burdensome.

What good looks like: biometric authentication (fingerprint, face recognition) where available, PIN or strong password as fallback, automatic logout after period of inactivity, and ability to remotely wipe lost phones. Sensitive data is encrypted on device.

What to avoid: storing passwords in plain text, keeping session alive indefinitely (lost phone can access data forever), and requiring complex passwords that users write down (security theater, actually reduces security).

Test on Real Devices and Diverse Conditions

Best practice: test mobile apps on actual devices (emulators are useful but not sufficient), diverse network conditions (fast wifi, 4G, poor coverage), and realistic usage scenarios (bright sunlight, cold weather, hands wet from field work).

What good looks like: app works on devices that are still in use in your organisation, including older ones, works on slower mobile networks, readable in bright sunlight (not white text on white background), and app is usable while wearing work gloves (buttons are large enough).

What to avoid: testing only on brand-new flagship phones, testing only on wifi, and skipping testing on devices/networks where your users actually work. Field worker experiencing poor app performance in hot sun is reality; your nice test results on new phone aren’t.

Measure Adoption and Gather User Feedback

Best practice: measure mobile app adoption (are users actually using it) and gather feedback (what works, what doesn’t). Use this data to prioritize improvements.

What good looks like: track mobile usage (how many users, how often, which features), survey users quarterly (what’s working, what’s frustrating), and measure business outcomes (does mobile use correlate with faster resolution times, higher satisfaction). Act on feedback—prioritize improving most-used features and fixing most-complained-about issues.

What to avoid: assuming adoption is high because you built mobile (actually measure it), launching mobile once and never improving (gather feedback and iterate), and building features users don’t need (prioritize based on actual usage, not assumptions).

A Release Gate for Mobile Changes

Treat each mobile release as a gate that requires written evidence, not as a demonstration. Three questions decide each release: does the workflow work for the people who use it, can the change be undone quickly, and can the signing owner point to the evidence behind both answers. The table lists the evidence that supports each decision.

Accessibility Problems That Show Up Only on a Phone

Accessibility faults are easy to miss in a desktop review and obvious in the field. Check that screen reader labels describe what each control does rather than where it sits or what color it is. Confirm that text grows with the device’s text size setting without pushing buttons off the screen. Test contrast in bright light, which is often where the app is used, and make sure tap targets are spaced far enough apart that a gloved finger does not hit the wrong one. The portal accessibility review guidance is the place to look for accessibility checks across a complete browser-based task.

A Staged Rollout Instead of One Switch

Release to one role at one site first. A staged rollout exposes a faulty layout to a small population and keeps the support load proportionate. Decide in advance which signal widens the release and which one stops it. A rising number of reopened records, a spike in sign-in errors, or one blocking defect in the approval path are all reasonable reasons to stop. Write those thresholds as conditions the owner can point to, rather than leaving them to judgment during the release call.

Labels, Time Zones and Locale Checks

Mobile users often read dates, currency and status labels in a different context from office staff. A date that displays correctly on a laptop can show a different day to a user in another time zone when the mobile form uses a different display format. Review every label on the mobile form, including empty states and error messages, with a real user from each locale in scope. Error messages deserve particular attention, because a phone user who sees an unhelpful error usually cannot scroll back to see what they entered.

Checks in the First Working Cycle After Release

1. Compare the completion rate for the workflow with its value before the release.
2. Read every support ticket that mentions the app, and tag each one by cause.
3. Confirm the rollback owner is reachable through the whole cycle, not only on release day.
4. Walk one completed record back through the audit trail to confirm who changed what, and when.
5. Record the outcome in the release log before the next change is queued.

When a Release Should Be Held Back

Hold a release when a fix to one workflow would change a layout that another workflow uses, when the evidence rests on a single tester’s device, or when the rollback has never been rehearsed. A held release costs little time. A broken approval path that nobody can reverse costs far more, and it erodes trust in the app for months.

Questions Release Managers Raise

Do we need to test every device model?

No. Test the device families and operating system generations that users actually carry, and state that scope in the release record, so the gap is a known gap rather than a surprise.

Who signs off a mobile release?

The product owner signs the workflow, the security lead signs the access evidence, and the release manager signs the rollback plan. A single signature covering all three hides which risk was accepted.

Can a small fix skip the pilot?

A text-only change can. A change to a field rule, a form layout or a notification condition should not, because those are the changes that behave differently on a phone than on a laptop. Record which changes count as small in the release log, and use the release acceptance criteria as the reference for the evidence each change needs.

What if the desktop and mobile versions must differ?

Document the difference and its reason in the design record. A deliberate difference is manageable. An accidental one is where most support tickets come from.

Related guides: ServiceNow Mobile Experience Testing and Acceptance Checklist.