ServiceNow Mobile Experience Requirements Workshop Questions

Workshop Objectives

A Mobile Experience requirements workshop gathers information about mobile use cases, user needs, connectivity constraints, and desired mobile capabilities. The workshop explores which employees need mobile access, what they need to do on mobile, and which mobile capabilities matter most.

Run the workshop with cross-functional attendees: field workers or their supervisors, HR or employee representatives, IT leadership, and the platform team. Plan a short series of sessions, with the length set by attendees’ availability. Use these questions as a guide.

Mobile User Personas

Who needs mobile access to ServiceNow: field technicians, remote employees, traveling executives, contractors? For each group, understand: how often do they need access, what tasks do they perform, can they access from a desktop, or is mobile their primary interface?

For field workers, understand work environment: are they indoors (shops, offices) or outdoors (construction sites, facilities)? Do they have reliable connectivity or intermittent connectivity? What devices do they currently use?

For remote or traveling employees, understand access patterns: do they need access during business hours, after-hours, or anytime? Do they need full functionality or just read-only access to status and reporting?

Mobile Use Cases and Capabilities

What primary tasks will users perform on mobile: submit requests (incident reports, leave requests), receive notifications and updates, approve work, or just check status? Prioritize by frequency and importance. The primary use case shapes mobile app design.

Do users need offline capability: can they access the network (though slowly), or do they work in areas with no connectivity (remote field locations)? Offline capability requires more development and adds complexity.

Do users need native mobile features (push notifications, camera, location services, biometric authentication)? These features improve usability but add complexity and security considerations.

Connectivity and Data

What is the typical network connectivity: always connected (office network), occasionally connected (field with WiFi access points), or often disconnected (remote field sites)? Connectivity affects app architecture.

What data needs to sync with the mobile app: work assignments, customer records, inventory, or just status information? Large data sets cannot all be cached on a phone; prioritize the most-accessed data.

How fresh must mobile data be: can data be hours old (overnight sync from last day), or must it be real-time (updates visible immediately)? Real-time sync requires always-on connectivity; older data allows offline operation.

Security and Governance

What security requirements apply to mobile apps: must devices be managed (MDM – mobile device management), must users authenticate with multi-factor authentication, must data be encrypted? Different organizations have different security policies.

What data can be cached on devices: is all ServiceNow data sensitive, or can some data be cached? Sensitive data should not be cached unless the device is encrypted and controlled (MDM).

What happens if a device is lost or stolen: must the app be remotely wiped, must the user be able to log out remotely? Design these controls before deploying mobile apps.

Integration and Notifications

Should the mobile app integrate with other platforms: Slack or Teams notifications, corporate email, or other messaging? Integration improves usability but requires additional development and security validation.

Do you need push notifications: should mobile users be notified of events (work assignment, request approval, alert)? Push notifications improve responsiveness but require planning (how many notifications, when should they be sent, do users want them?).

Design Decision Impacts

Deciding to build custom mobile apps means significant development effort and ongoing maintenance. A simpler alternative is a mobile-optimized web interface. Evaluate tradeoff: custom apps provide better user experience and offline capability but cost more.

Deciding to support offline capability requires caching data on devices and complex sync logic. This adds security considerations: is cached data encrypted? What happens if the device is lost? Offline is valuable for field workers but adds complexity.

Deciding to require mobile device management (MDM) means all users need managed devices. This affects users with personal devices (BYOD). Consider whether BYOD is allowed or if only corporate devices can access mobile apps.

Turning workshop answers into decisions a build team can use

A workshop on mobile requirements is only as useful as the list it leaves behind. Many sessions produce a long column of wishes: offline access, push alerts, a camera button, a map of the depot. The build team cannot schedule a wish. What it needs is a short set of decisions, each with a named owner, a stated reason and a note of what would change the answer. The order below is chosen so that early answers remove later questions, because the answer to one question often settles many of the ones that follow.

This section is for the facilitator and the executive sponsor who will sign off the output. It assumes the attendees are already in the room and the purpose of the session has been agreed. If only a handful of people will ever open the app, a full workshop may cost more time than the decisions are worth; one review meeting with the platform owner and a representative user can settle most of the points. For background on the product itself, the mobile experience overview is a useful starting point before the session.

Sequence the decisions before the feature list

Start with who the mobile user is and which tasks they must finish without a laptop. Every later answer depends on that, and the use cases enterprise teams usually start with are the place to look for candidate use cases to test against your own groups. A dispatcher reassigning work from a van needs a very different app from a manager who only wants to approve requests on a commute. Discussing features first produces a shopping list nobody can rank, because each item looks equally important in isolation.

A workable order runs: user groups and their primary tasks, then the connectivity each group has in the places it actually works, then the data each task truly needs on the device, then the controls the security team will insist on, and only last the optional extras such as messaging integrations and alerts. Keep a parking list for ideas outside the agreed primary tasks. Many are good ideas, and they become the second release instead of a distraction in the first.

What each decision should produce

The table below works as a decision log. Fill one row per decision before the session closes, and never leave the owner column blank, because a decision without an owner returns to the next meeting unchanged.

An ordered way to run the session

1. Send attendees a one-page brief naming the user groups you expect to cover, so they arrive with real tasks rather than general opinions.
2. Ask each group to walk through its last three working days in the field, step by step, before anyone mentions a feature.
3. Write every task on a card and sort the cards into must-have, should-have and later. Limit the must-have pile before the break, not after it.
4. For each must-have task, ask what the user does when the app is unavailable. The answer shows whether the task needs offline support or only a fallback route.
5. Read the decision log back aloud and have each named owner confirm their rows before anyone leaves the room.

Failure modes to watch for

A common failure is a room dominated by one user group. Managers talk about dashboards and approvals; technicians talk about gloves, battery life and patchy signal. If a group is absent, the output will describe the wrong app. Compare the attendee list with the user groups before the session starts and invite a representative for any group that is missing.

A second failure is treating security controls as optional until the build is nearly finished. When the security team hears about device compliance for the first time late in the schedule, the offline design has to be reopened, and the delay was knowable in the workshop. A third is mistaking a preference for a constraint. A technician who wants the app to load instantly may really need to see a job’s access instructions before reaching a locked site gate. Ask what the user would lose if the app were slower, and record that consequence rather than an aspiration.

How to tell the workshop has worked

The workshop has done its job when the build team can start designing without calling the attendees back to ask what they meant. Look for a short list of primary tasks with owners, a clear statement of which data may leave the server, and open items that each carry a date by which the owner will answer. If the output still reads as a list of things people like, the session stopped too early, and the decisions need another pass with a smaller group.

When not to run the full workshop

Do not run a multi-session workshop when the mobile need is narrow, such as a single approval type for one group of managers. A focused review of that flow, with the platform owner and two or three users, usually produces a better answer in less time, and the mobile service experience article covers the general ground without needing a full session. The full format earns its cost when several user groups share one app, when offline work is in scope, or when the device policy is still undecided.

How do we handle a disagreement between field teams and executives about which tasks come first?

Record both positions in the decision log with the business value each one claims, then ask the sponsor to rank them against the same test. A field task that protects a safety or service commitment often outranks an executive convenience, but that ranking is a judgment the sponsor should make openly rather than one the facilitator slips into the notes.

Should the workshop happen before the platform team chooses between a native app and a web interface?

Yes, because the offline and device answers drive that choice. If field tasks need local data and reliable alerts, the native route becomes more likely. If most users only need status checks, a responsive web interface may cover the need at lower cost.

What is the minimum record of the session that a build team can use?

The decision log, the parking list and the open questions with owners and dates are enough. A long transcript rarely helps, because nobody rereads it once design is under way.

Who should sign off the output?

The executive sponsor signs the decisions that affect cost or risk, and the security lead signs the device and data rows. Other rows can be confirmed by the business owners who raised them, provided the confirmation is recorded in the same log.

Next step

The guide to mobile roles and responsibilities shows who should own each row once the decisions are made.