A stacking plan (also called stackplan) is a visual representation of a building showing a breakdown of space. Stacking plans serve many different user types and use cases but are typically brightly colored and information dense images— often optimized for a printed tour book.
Here are some stacking plans out in the wild:
Commercial real estate (CRE) centers around property data. It’s no surprise that stacking plans are a ubiquitous information display pattern in the industry and that entire companies exist to serve stacking plans. What is surprising, however, is that there’s no standardization of this pattern both in terms of visual design (see above) and in terms of their underlying data models. Moreover, companies aren’t using the aggregate data stored in stacking plans to gain insights or make predictions about leasing trends.
Part of the problem is that the existing workflow for creating and updating stacking plans is almost completely manual. A tenant rep broker in the New York market said of his current process:
“ I’m spending four or five hours or three or whatever it is [updating] a single building [stacking plan]. Each broker’s doing the same thing. So, you can multiply all those hours…the loss of hours, just being hidden in the firm is tremendous. You know, I’d say it’s upwards of 30% of the firm’s time, a really significant amount.”
Another issue is that in order to interpret the data in most stacking plans, you need to track down additional information like lease comps and availabilities — it’s not a one-stop-shop.
Last year, four of our internal product teams had OKRs related to creating that one-stop-shop stacking plan interface. These four teams all sit in different offices across the US and serve different users and stages of the real estate journey. Two teams share a design system but the others have completely different tech stacks and development processes. To make sure we didn’t end up building four incompatible variants of the same feature, I helped organize and lead a 3-day Stacking Plan Summit with 20+ participants.
We spent the first two days conducting collaborative sessions to:
- Understand what users are trying to do with stack plans,
- Uncover what data is important for accomplishing those tasks,
- Define data services, and
- Explore visualization solutions.
On the last day, we identified key opportunities for collaboration and co-investment and aligned on shared initiatives, goals, and clear accountability. We came out of the summit with a shared understanding of the problems, a schematic for a shared UI pattern, a rough timeline for feature delivery, and shared product metrics:
Along the way we learned that even though stacking plans may be used in different ways by landlord brokers, tenant rep brokers, landlords, and market researchers — they leverage the same core property data. But the difference between a standard stacking plan and a great one is the latter tells a data story about a building.
For example, our New York tenant rep broker from before uses stacking plans to help new tenants narrow down options according to their space needs. It’s not enough for him to show a prospective tenant how much available space is in a building right now. What’s more effective is for him to use that same availability data alongside lease comp data and current tenancy data to paint a picture for the prospective tenant about the kinds of workplaces the building houses.
We came out of the summit with a schematic for a modular stacking plan component that can help different applications tell different data driven stories. Now, 5 months on, we have a shared stacking plan component closely resembling the workshop schematic:
(big shout outs to Marly El Khoury, Jürgen Mantzke, Anders Rosenquist, Alyssa Landry, and Sage Gatzke for their all their hard work on this feature)!
…but did we make a better stacking plan?
Early user testing of the built feature with landlord brokers indicates that we succeeded in our usability metric of “helping brokers and clients effectively interpret property data to make informed decisions.” But we’ve only scratched the surface of the harder feasibility problem of centralizing and validating broker-entered property data. Here’s a simplified schematic of the data problem:
For now, there’s still a goldmine of stacking plan data out there — the quest continues.