Geofencing

BigFix MCM, Modern Client Management, is where admins manage policies and devices. Competitors like Omnissa and ManageEngine had geofencing, so the product team asked us to add it. The first phase was focused: let an admin draw geofence zones on a map and use them to control devices, for example by sending a notification or locking a phone when a device leaves a zone.

The hard part was where this had to live. Geofencing sits under the Admin tab, the one part of MCM that keeps a left side menu open at all times. It does not collapse, so whatever I designed had to fit in the space next to it. A geofence screen needs a map, and a map wants room, so most of the early work was finding a layout that kept the map usable in a narrow column.

There were other limits too. iPhone only supports a couple of geofence shapes, so we settled on circle and polygon. A zone had to cover at least 100 meters. And because this is the on-premise version, there was only so much we could do technically. So the goal was never to invent something flashy. It was to make geofencing feel like it had always been part of MCM.

The feature settled into three parts. Manage Zones is where you create and list geofence zones. Manage Settings is where you define what should happen: the notifications, policies and device actions. But a zone and a setting are separate things, and an admin needs to connect them, so I added a third section, Deploy Zones and Settings, which maps a setting onto a zone.

I called it Deploy rather than Manage on purpose. In MCM you already create policies and actions in one place and deploy them somewhere else. Reusing that word meant admins did not have to learn a new mental model.

Creating a zone is the core interaction, so it got the most attention. The few fields, name, shape and search, sit above the map, and everything spatial happens on the map itself. Search sits right on top of the map so what you pick drops straight onto it. As you draw, the coordinates are calculated and shown on the map, and the zoom, delete and my-location controls sit on the opposite side so the coordinate panel never covers them.

Every zone lives in one table: its name, location, shape, status, the settings and devices attached to it, and who last touched it. A zone is active the moment it is created; to turn it off you edit it from here. Because geofencing was new, I added a help note to each section that explains the less obvious columns, like what active and inactive actually mean, with a link out to the full documentation.

The third section ties it together. You pick a zone, pick one or more settings, name the mapping and deploy it. Deploying is what makes a mapping live, and its status reads enabled or disabled. Keeping zones and settings separate means an admin can build ten settings once and reuse them across as many zones as they need, instead of rebuilding the same thing each time.

Across all of it, the rule was consistency. I reused MCM's existing components and patterns instead of inventing new ones, matched terminology to what admins already see in the product and in competitor tools, and kept scrolling to a minimum so small tasks stayed small. On the dashboard we surface the thing admins actually care about, devices that are outside their geofence, along with which devices are compliant and which geofences apply, so it can be acted on without digging.

Geofencing shipped as the first phase of the feature in MCM: create a zone, define a setting, map them, deploy. The interesting part of this project was not a bold new idea, it was the opposite. Designing something genuinely new inside a rigid enterprise shell, with a menu I could not move, shapes I could not add and an on-premise version I could not stretch, and still making it feel native. Working inside those limits taught me more about enterprise UX than a blank canvas would have.