Stargate Maps

Product Design, UX, UI, Information Architecture, Data Visualization

Using quick iteration and testing, we created a new design framework for a map-based interface to analyze real estate deals with data.

WeWork     2017

Lead Designer

Team: Design Director, VP of Product, Product Director, 12 Software Engineers


Stargate is WeWork’s data platform for real estate and development. We needed to create a map-based interface that used internal and third-party data to analyze new deals. 


We developed two versions to iterate and understand our users faster: one to prototype and test, and one to build a long-term framework to establish precedents for later features.


Research & Data

We started by identifying two data points that our real estate users used to evaluate their deals: amenity density and industry concentration. In addition to our own user interviews, we also worked with WeWork’s Research Team for specific quantitative data. Below are some initial prototypes, user goals, and storyboards.

User Goals

Market: Analyze market saturation and potential

What is the optimal density of WeWork locations that we can support in a single market without risk of cannibalization?
Area: Understand high-level insights to make informed decisions for new deals

Are we expanding into high-potential neighborhoods based off amenity density and distribution or the overall business profile?
Location: Compare individual metrics around existing WeWork locations, listings, and competitors

What can we determine about the viability of a potential or existing WeWork compared to neighboring buildings?


Scenario 1: User is searching for a WeWork location or place
User will start searching and select specific location. This will pull up a panel with relevant information about that location or place.
Scenario 2: User wants to compare two areas (polygons) to see which one is more optimal
Using the draw tool, the user will draw on a map an area. This will return a focused area on map that will include basic toggles (wework locations, competitors, listings, and amenities). User can toggle specific pins on and off using the toggle panel.
Scenario 3: User wants to investigate potential listings in an area

User can turn on listings (eventually we should explore how they can filter by specific listings).


Initial Prototyping & Testing

An older mapping product, Horizon, was built in legacy code but had enough of the foundation to quickly prototype new features in. We wanted to use this opportunity to get feedback from users and know what to design and build for in the next version. 

Some takeaways: the difference between read-only vs editable data was unclear, bar graphs didn’t display data accurately, and the “draw” interaction was hard to work with.


Information Architecture & Flow


Once we started collecting feedback on our prototype, we started to outline better interaction flows and categorize the data hierarchy (i.e. market-, neighborhood-, or building-level; internal or third-party; quantitative or qualitative).


Based on our development schedule, user flows were first limited to the individual component and how it interacted with the map. We later fine-tuned any flows that needed multiple panels to work together.


We designed a component framework that would provide the structure to support editing and gathering information with many different data points on a map. Having specific components would clearly inform  users where they could perform different actions on the screen. For our team, the components created a precedent on how to integrate future data sets into the interface. We also thought this approach would be the the easiest way to later build for mobile.


Final Product & Components

The new design addressed many of the usability issues from our prototype, while also laying out the groundwork for our team to quickly integrate new features. We went through many different iterations for the components, marker colors, and ways to display data, but ultimately arrived at the final versions below.

Copy was also really important: we needed to be specific about how metrics were calculated and inform users that some features only worked at certain zoom levels.


Shape States

Information Panel

Edit Panel



Maps ended up being the second most-used feature in Stargate and completely replaced Horizon. We were surprised to learn that many users who were not in real estate (sales, marketing, logistics, and community) were heavily using Maps to gather information about our buildings. They found the interface easier to use and understand than spreadsheets and databases. This was only the second version of this product but a really great way for our team to better understand how our users were using data to help their jobs. We even got some press:

“WeWork was already growing its footprint rapidly before it implemented Factual’s places data, but the company claims that its ability to assess more buildings accelerated its growth further. WeWork grew its number of locations by 95 percent between June 2016 and June 2017.

In addition to helping its real estate team evaluate potential locations, Fritsch says the Factual data platform has also been useful to its sales team. WeWork can open locations in optimal areas, but it still has to sell its product – office space – to customers or new members. The sales team can flaunt stats about the number of amenities in a given area to entice new members and fill up new locations. While the real estate group is using it to make high-stakes decisions, Fritsch says there are more salespeople looking at the data than employees on the real estate side.”

Here’s How WeWork Pinpoints the Perfect Locations for Its Co-Working Spaces in Neighborhoods (Entrepreneur Magazine, 2017)


(Data Visualization)


(Stargate Navigation)