Geofencing & Jailbreak Detection

Overview

Goals

Impact

The solution strengthened endpoint security, helping onboard 3 new enterprise clients, including one federal customer, and manage 500+ devices.

My role

For both features, I partnered with Product Managers, architects, and Android/iOS developers to understand technical constraints and platform-specific limitations. I iterated on designs through stakeholder reviews, delivered detailed developer handoffs, conducted UX walkthroughs, and collaborated with QA throughout implementation to ensure the final product aligned with the intended user experience.

MCM Admin persona

Both features are built for the same user: an MCM endpoint administrator who manages thousands of devices in a legacy console and wants secure, repeatable ways to deploy policies at scale.

Research

Before drawing anything of my own, I collected how other products handle geofencing. I started with a competitive analysis of Omnissa, ManageEngine, and other UEM platforms to understand industry standards, common workflows, and the terminology familiar to IT administrators. These insights helped define user expectations and guided the design of a solution that felt intuitive while fitting seamlessly into the existing BigFix MCM ecosystem.

Possible user flows

Everything an admin needed to do with a geofence, written down before any screens were drawn:

• Create a geofence and add a policy to it.
• Create a geofence and save it without a policy.
• While creating a policy, apply from a saved geofence.
• Edit an existing geofence policy.
• Deploy the geofence to devices, or add devices to a policy.

Conceptual sketches

The thinking happened on paper first. I mapped the whole task and both user journeys by hand, then a first structured wireframe, before any of it turned into a real layout. Scroll each sketch to see the full page.

Decisions post reviews

Two decisions came out of the stakeholder reviews, and they shaped where the feature lived and how it was structured.

Final user flow

Manage Zones is a dedicated space to create and manage geofence boundaries. Manage Settings is a separate section to configure reusable policies, notifications, and device actions triggered by geofence events. Deploy Zones & Settings maps a selected setting to a specific geofence, since zones and settings are independent entities.

• Kept zones, settings, and deployment separate to improve reusability and reduce complexity.
• Used “Deploy” instead of “Manage” to match BigFix MCM's existing terminology, leveraging administrators' existing mental model.

Discussion and validation from stakeholders

Reviewing the early explorations with stakeholders surfaced what wasn't working, and each critique fed the final layout.

Three sections, one flow

The feature settled into three parts an administrator moves through in order: manage zones, manage settings, then deploy the two together.

Manage Zones

Combining zone creation and management into a single Manage Zones section, so administrators can both create new geofences and view or update existing ones in one place.

• Prioritised zone creation by placing the essential inputs (Name, Shape, and Search) above the map, while keeping all spatial interaction on the map.
• Positioned the search bar above the map so a searched location is immediately visualised and used to create a geofence.
• Displayed coordinates dynamically as an administrator draws, with map controls for Zoom, Delete, and My Location.
• Included a management table listing every geofence with its name, location, shape, status, associated settings, assigned devices, and last-modified details.

Manage settings

Separating settings from zones so they can be created independently and reused across multiple geofences.

• A configuration flow where an administrator defines a setting once.
• Separate entry and exit configurations for Android and iOS policies, so devices behave differently when entering versus leaving a geofence.
• A Restore option on exit policies, letting an administrator revert to the original policy or apply a different one after a device leaves.
• Critical device actions such as Lock Screen, Reboot, Wipe, Lost Mode, and Factory Reset, to automate security responses based on device location.

Deploy zone and setting

The third section ties it together: pick a zone, pick one or more settings, name the mapping, and deploy. Deploying makes a mapping live, and its status reads enabled or disabled.

Dashboard and devices page

Finally, the things an admin cares about surface where they already look. The home dashboard flags devices outside their geofence zones, and the Devices page carries each device's associated geofence setting, compliance status, and zones.

The gap

The requirement focused on post-detection actions but did not define the detection workflow itself. I worked backwards from the expected outcomes to design the end-to-end detection experience, exploring how devices would be scanned, when detection should occur, and how the workflow could integrate seamlessly into the existing product.

Research and limitations

Competitor products did not provide a dedicated UI for Jailbreak Detection, making it difficult to benchmark interaction patterns beyond basic device detection.

So I first mapped the end-to-end user flow to determine where the feature should live, how administrators would interact with it, and where the UI should be introduced within the existing MCM ecosystem.

Product flow

Talking through how an admin would actually use this, two journeys kept showing up: one where the compromised device is already known, and one where it has to be discovered by scanning first. I designed the feature so both paths were fully supported, so an experienced admin was never forced to scan when they already knew the answer.

Feature placement

Since Jailbreak Detection is an administrative security capability, I positioned it under the Admin module alongside Geofencing, ensuring it aligned with the product's existing information architecture and users' mental models. Reusing familiar navigation patterns reduced the learning curve and created a consistent experience for administrators.

User flow

The detailed flow shows the two ways to detect a jailbreak: acting directly on devices the dashboard already surfaces, or discovering affected devices by scanning, either on a schedule with policies and actions attached, or immediately as an instant check.

Early wireframes

I wireframed both journeys end to end before touching any visuals. The first board is the direct path, selecting a compromised device and choosing an action like quarantine. The other two are the scan-first path, where I worked through scheduling a scan, reviewing the results, and applying actions to whatever came back non-compliant.

Devices page

Direct scan Action

I initially explored configurable scan scheduling, but after discussions with engineering, we removed it in favor of automatic daily background scans, aligning with competitor products and reducing unnecessary configuration. For immediate verification, administrators can perform an Instant Scan on a specific device through the Actions menu.

Setting up enforcement

The part that stayed is compliance enforcement, where an admin decides what a jailbreak actually triggers. Everything lives in one list, and creating a setting walks through targeting device groups, choosing whether to act on compromised or potentially compromised devices, and picking the actions themselves.

Reflection

The result: retention of existing clients and the acquisition of two new federal customers.