A New Field-Data Product for the Modern ArcGIS Platform

The team had a clear charter — build the field-data product for the next era of ArcGIS — and no shared picture of what that meant in practice. The product manager and I could have spent the first quarter building a roadmap from the requirements inventory of the three predecessor apps. We didn't. I proposed and facilitated a five-day Google Ventures-style design sprint at the start of the engagement, with the full cross-functional team in a room, treating the question "what is the field supervisor's one-stop-shop?" as a design problem rather than a product-management problem.

The sprint moved through long-term goal-setting, customer mapping, How-Might-We framing, lightning demos of analogous products, solution sketches, sticky-note decision-making, storyboarding, and a working prototype — the canonical structure from the Knapp/Zeratsky playbook, run faithfully because the team needed the structure more than it needed creative facilitation. The decider in the room — the product manager — got the supervote at the sticky-decision stage. The team left the sprint with one direction and a storyboarded prototype, not five.

What the sprint produced wasn't a finished design. What it produced was an aligned design. The product manager and engineering had been in the room for every decision, which meant the next eight months of scoping conversations started from a shared picture rather than from each function arguing for its own priorities. That was the real return on a five-day investment — not the prototype, the alignment.

The single most fragmented experience across the three predecessor apps was preparing a map to work offline — the workflow that mattered most to about half of all users and the one most likely to fail in the field. Each legacy app had handled offline preparation differently, and the settings that controlled it were scattered across authoring screens, sync screens, and the underlying web map definition. Customers spent training cycles teaching their crews where to find them.

I made the decision early — and pushed for it against some internal resistance — to make offline preparation the anchor surface of the new product. Not the map itself, not the authoring canvas, not the form builder. The offline preparation experience was where the new product's value would be most visible and most valuable to the customer. If we got that right, the rest of the product could differ from the predecessor apps in ways customers would tolerate. If we got it wrong, no amount of work elsewhere would matter.

The redesign centralized every offline-related setting into a single, sequential workflow inside the web authoring experience — extent selection, layer selection, basemap caching, sync behavior, and the diagnostic feedback that told the supervisor whether the map was actually viable offline. The supervisor saw the offline experience as one decision, not seven. That single workflow change was, more than any other, the thing customers cited when explaining why they'd migrated from Collector.

Forms were the second-most-fragmented surface across the three legacy apps. Field Maps needed a single, coherent forms experience — and the team's working name for it was Smart Forms. A form-authoring environment where supervisors could design the data-collection forms their crews would use, with conditional logic, calculated values, and rich field types.

The reconciliation problem was a structural one. The data model — feature classes, field definitions, domains — was template-first: you started from a schema and forms followed. But every customer interview said the same thing: people don't think in schemas, they think in forms. They wanted to draw the form their crew would fill out and have the underlying data structure follow.

We resolved this by treating templates as preliminary, scaffolded work happening underneath a form-centric authoring surface. The supervisor experienced the workflow as form-first; the system handled the template-first data model behind the scenes. That reconciliation is invisible in the shipped product, which is exactly the point — it was the hardest design decision in the product and the one that disappears when it's done correctly.

Smart Forms shipped inside Field Maps, then propagated. Aspects of the work later moved into the core ArcGIS web map product and other ArcGIS data-collection applications as adjacent teams adopted what Field Maps had built. The Smart Forms work was the highest-leverage design contribution of my Esri tenure — not because of how it looked in Field Maps, but because of how many other products in the platform it ended up shaping.

Field Maps shipped on Calcite, Esri's company design system. But Calcite wasn't a finished system being consumed by Field Maps — it was a system being defined, in real time, through its first product implementation: the parallel redesign of ArcGIS Online's flagship surface, Map Viewer. Map Viewer was Calcite's proving ground. Field Maps was the second product through the door.

That meant the team was designing against two evolving things at once. Map Viewer as a product, with patterns and interactions still being decided by a different team. And Calcite as a system, with components, tokens, and guidance still being authored as Map Viewer hit each new design problem first. Routing around either one would have orphaned Field Maps from the platform on day one of release — a Field Maps that didn't look or feel like ArcGIS, built on patterns that diverged from where the rest of the company was heading.

The decision wasn't whether to absorb the coordination cost — it was how to structure the team's working relationship with Map Viewer so that absorbing the cost was sustainable. I established standing coordination with the Map Viewer team for status and feature consumption, built reusable components alongside theirs where Field Maps needed something Calcite didn't yet provide, and made sure our team consumed each Calcite pattern as it stabilized rather than waiting for the full system to land. The short-term cost was meaningful — every release window had a Map-Viewer-and-Calcite alignment pass — but the return was a Field Maps experience that felt native to the platform on day one, and a working relationship with the Map Viewer team that compounded across every release that followed.