Establishing a Maps Platform

Architecting the shared geospatial primitives and data layers for Outside’s multi-brand ecosystem.

Role Principal Product Designer

Scope Platform Architecture

Outcome Team Charter & System Model

01 // The Friction

The "Tower of Babel" Problem

Outside’s portfolio (Gaia GPS, Trailforks, MapMy) is built entirely around maps. Yet, despite maps being our core competency, we treated them as isolated, disposable features.

There was no shared vocabulary. "Layers," "Tracks," and "Waypoints" meant different things to different engineering teams. This led to massive technical duplication—we were solving the same rendering and data storage problems three times over, with inconsistent results for the user.

FIG 01. DEFINING THE OBJECT. Before building a platform, I had to align stakeholders on the evolution of a map: moving from a "Static Image" to a "Functional Interface" that supports complex user workflows.

02 // The System Model

Decomposing the Anatomy

The Insight

"We couldn't start with screens or APIs. We needed a Conceptual Model first. We had to decouple the 'Experience' (what the user touches) from the 'Functionality' (the data services)."

I created the "Map Anatomy" framework to act as the contract between Design and Engineering. This framework separated the application into two distinct layers:

The Experience Layer: Viewport controls, UI containers, and interactions (Product-owned).
The Data Layer: Tilesets, user location services, and object definitions (Platform-owned).

FIG 02. THE MAP ANATOMY. This diagram became the foundational document for the platform team. It clearly demarcated which components should be centralized (bottom) and which should remain flexible (top).

From Anatomy to Services

With the anatomy defined, I worked with engineering leads to map these abstract concepts to concrete Shared Services. We identified that while UI might vary between apps, the core primitives—Search, Route Storage, and Offline Management—should be universal.

FIG 03. SERVICE MAPPING. Translating the design anatomy into an engineering service architecture to support unified route storage and tile rendering.

03 // The Vision

Enabling Cross-Product Experiences

The ultimate goal wasn't just code efficiency; it was user value. By centralizing the data layer, we unlocked the ability to pull context from across the network.

I visualized how a unified backend could enable a user to plan a route in Gaia, see live trail reports from Trailforks, and track their progress on an Apple Watch—all sharing the same "Truth" from the database.

FIG 04. THE FUTURE STATE. A vision of "Context-Aware Mapping," where data from the entire Outside network enriches the map experience regardless of which specific app the user is holding.

04 // The Impact

Infrastructure as Design

This work successfully shifted the conversation from "pixel tweaking" to "platform funding."

Team Funding: The "Map Anatomy" clarity directly supported the business case to fund and hire a dedicated Maps Platform Engineering team.
Unified Data: We identified the critical need for a "Canonical Trails Database," initiating a multi-year effort to merge the Gaia and Trailforks datasets.
Gaia Adventure Modes: The framework laid the groundwork for Gaia’s new "Adventure Modes," allowing the interface to reconfigure itself based on the shared primitives we defined.