Business Problem

ServiceNow customers are looking to power on-the-go solutions — such as Field Service Management (FSM) — using the latest native mobile technology such as GPS, push notifications, camera, etc.. Mobile Studio is an existing solution that provided basic and simplified workflow, but limited capabilities that forced developers to jump into Platform. From there, configuring such features tend to be very cumbersome with plenty of repetitive tasks along with tedious training and incomplete documentation. While our users were using Mobile Studio to configure their solution, It would only get through 75% of the configuration before you have to dig into system files and configure. Mobile App Builder is an aspirational product that became the go-to tool not only for mobile, but set an example for other products within ServiceNow that garnered positive attention.

Know our users

Over 10 ServiceNow customers participated in a usability research session to go through the experience, pain points, and preference for using Mobile Studio. The user profiles below summarized the key findings. Each persona represents the profile, goals, and struggles.

• Primary focus are ServiceNow Developers, whom are familiar with ServiceNow’s platform and knowledge of working through building mobile workflows. Those users generally range between system developers who want to create workflows, and analysts who want to create reporting.

• Since we’re looking to support citizen developers, whom are users that can create without knowledge of ServiceNow’s platform, we recognized that designing the product to scale and layer tools was essential and part of the art. For me, new users are essentially citizen developers, and so onboarding needed to be a priority to not only garner trust from existing users, but begin educating new ones to have Mobile App Builder be the preferred tool of choice.

Pain Points & Opportunities

☹️ Mobile Studio doesn’t support all capable features of the mobile platform.
→ How might we set up our builder to quickly support feature parity?

☹️ Mobile Studio and Platform introduces advanced terminology that’s only unique to ServiceNow mobile platform.
→ How might we align terminology with first-party products and what’s common within the industry?

☹️ Mobile Studio works in parallel with native mobile teams for feature development, causing last-minute stress on our engineering team to deliver something functional and bug-free.
→ How might we modify our release cycle to adopt new features within months after dependent teams finalize the code?

☹️ Mobile Studio users heavily rely on documentation to navigate and understand what they’re configuring.
→ How might we provide guidance text to explain configuration on the spot?

☹️ Mobile Studio doesn’t provide enough visuals to understand what users are configuring.
→ How might we introduce examples of specific areas of the screen?

☹️ Mobile Studio takes about 2 hours to onboard.
→ How might we introduce a narrative of walking users through the build, preview, and validation?

Research & Workshops

Upon surveying 1200+ participants in a terminology conducted by the research team, it was clear existing Mobile Platform terminology had challenged users with understanding what they were configuring. From either made up names, to names that carry different meanings, and even names that represented a compound of items, the standardization of these terms were essential not only to reduce friction, but also to remain consistent with other builder tools within ServiceNow.

Results

• 5 rounds of research with 22 participants

• 3 rounds of research with external customers (organizations ranging between 3.3k - 400k employees)

• up to 93% reduction in development time to adopt features from dependent teams.

• 70% feature parity with existing team resourcing (eng, product, design)

• 84%-95% of participants felt Mobile App Builder did a better job than the current tools they used to configure mobile apps. Gap referred to the complexity of the mobile configuration architecture, which was escalated up to the product team and used for further funding.

• 100% retention of returning existing users (measured using the SN's early access program).

• Improved completion rate as there's one single load time among dozens of records (O*n vs O^n),

• Improved success rate through wizards, reduced avg time on task, and improved number of created screens.

• Post-launch praises from BUs and developers ⭐️⭐️⭐️⭐️⭐️