Real-Time Location Product for Enterprise Field Operations

The first phase of Track Viewer research focused on first-responder workflows. We interviewed police departments, fire crews, and EMS dispatchers, and the design hypothesis the team rallied around was high-stakes incident detection — using the sensors in modern mobile devices to identify crashes, falls, and abnormal vital signs in the field, and surface them to operators on the web dashboard in real time. The web design started consolidating around an operator console pattern: a live map of personnel locations, an alert lane that surfaced sensor-triggered events as they happened, and the workflows for the operator to acknowledge, route, and resolve those events. Months of work were oriented around that direction.

When legal review came back with the determination that crash-detection and incident-detection features carried liability exposure Esri couldn't absorb for first-responder customers, the product had to redirect. The sensor-driven alert surfaces, the operator-console framing, and the first-responder-specific workflows all came out of scope. What we were left with was the underlying platform capability — real-time location of personnel, configurable views, historical track analysis — but no longer the flagship use case the design had been built around.

The design work the pivot required wasn't a rewrite from zero. It was a careful audit of which decisions had been first-responder-specific and which had been general enough to survive into a broader product. The operator-console framing went. The alert lane went. The sensor-trigger surfaces went. What stayed was the administrator's mental model — who is tracked, who can view, what time windows are visible — which turned out to be the actually durable part of the product. Track Viewer shipped as a more general real-time location product, used by utilities, transportation, government inspection programs, and field service organizations whose tracking needs didn't carry the same liability profile. The pivot worked because the team had been disciplined about separating the configurable foundation from the use-case-specific surface; what we lost was real, but it was the top layer, not the whole stack.

The lesson the project taught me about this kind of redirect — the kind where a constraint outside the team's control reshapes the work — is that the question isn't whether to grieve the lost direction. It's how quickly you can identify what survived, and how confidently you can rebuild the narrative around it. The team that gets stuck on the lost direction loses months. The team that finds the durable layer underneath ships.

The architectural decision that shaped Track Viewer most, beyond the pivot, was one the team made deliberately before the pivot ever happened: keep the product scope narrow on purpose so the platform services underneath it could be general. The real-time location services Tracker was built on were being designed for reuse across the ArcGIS platform — Workforce was going to consume them, Field Maps was going to consume them when it eventually absorbed Tracker's capabilities, and other products downstream were going to consume them in ways the team couldn't fully anticipate yet. If Track Viewer's design pulled too hard on the services to fit Track Viewer's specific needs, those services would become Track-Viewer-shaped and harder to reuse. If the design stayed within what the services could offer as a general capability, the services stayed general.

That constraint translated into specific design decisions in the web product. I held the line against feature requests that would have required service extensions specific to Track Viewer's UI — custom aggregation, custom time-window logic, custom event types — and pushed those decisions into the configure-on-web surfaces where the administrator could compose general capabilities into specific outcomes for their organization. The web app didn't tell the services what to do; it told the administrator how to express what they wanted within what the services already supported. That's a less interesting product story from a screenshot perspective, but it was the right one for the platform.

The payoff arrived later, in two places. Field Maps consumed Tracker's services when it absorbed the tracking capability into the unified field-data product — the services were already general enough to slot in without rework. And other ArcGIS products that needed real-time location functionality picked up the services without having to negotiate around Track-Viewer-specific assumptions baked into them. The Track Viewer team's discipline about scope is invisible in the shipped Track Viewer product, but it's why the platform got real-time location infrastructure that survived the product itself.

Track Viewer and the Tracker mobile app were two surfaces of one product, built by two teams. The Track Viewer web team I sat on owned the administrator experience; the Tracker mobile team owned the field user's device experience. The design relationship between the two surfaces had to be designed as deliberately as either surface on its own — and it had to be designed across an org boundary, not within one. The administrator built a track view on the web, defined who was tracked, what time windows were visible, what permissions applied to which viewers — and the field user's mobile experience was a direct consequence of those configuration decisions. A web decision that didn't account for what the mobile user would experience created a broken handoff; a mobile design that didn't account for what the web could actually configure created a feature the administrator couldn't deliver. The two teams shipping independently was a structural risk to the product, not a neutral org fact.

I built a direct working relationship with the mobile designer on the Tracker mobile team and ran standing design reviews where both surfaces were on the table at once — not "I'll show you the web, then you show me the mobile," but "here's the workflow end to end, and here's where the seam between the two surfaces is sitting." Those reviews ran outside the formal cross-team coordination the product managers and engineering leads were doing; they were a designer-to-designer working forum that existed because the product needed it. The decisions that came out of those reviews were rarely about either surface in isolation; they were about where the seam belonged. When the administrator turned tracking on for a group, what did the field user see on their device? When the administrator changed the time-window policy mid-shift, what state did the mobile app land in? Those seams were the actual product, and getting them right across two teams meant the two designers treated the work as one deliverable even when the teams shipping it didn't.

That cross-team paired-design model is what I carried forward into Field Maps when the products consolidated. The configure-on-web / consume-on-mobile workflow Field Maps inherited from the Field Apps line wasn't an architecture diagram I learned on Field Maps — it was a working practice I'd already developed across the Tracker team boundary, ready to apply at higher scale on the consolidated product, where the web and mobile work eventually came together on a single team.