Air Rights Database

A comprehensive site to search and explore available transferable air rights in New York City.

 

Following the development of Vivacity's Property Portal, users requested a platform to understand a property's leftover development potential. In New York City, these are called Air Rights. These excess square feet of development can be sold to other adjacent property owners, they can be transferred within specific marketplaces, or they can be bought from landmark buildings. Users had similar complaints before we built our Property Platform. They had to navigate multiple sites that presented only partial information. Resourceful databases, like the NYC Department of Finance's transferred air rights database, could only be accessed in tabular form. In summary, air rights information was not accessible at the point of a property. So with a similar methodology, we built a one-stop-shop for a property's air rights information.


Project Specs:

Duration: 9 months

Development Stage: In Production

Tools:

  • ArcGIS Javascript

  • City Engine

  • React JS


Deliverables

Web App


Roles

UX Research

UI Prototype

UI Design

Web Map (GIS)

Back-End 3D Content

Overview

We built the Air Rights Database to search and find available air rights. I wire-framed the design similar to Property Portal. Users familiar with that platform could interact with the web app with a low learning curve. I decided to keep the web app's 3D scene as the main component. Users intuitively wanted to select adjacent buildings.

In addition to showing unused square feet, all selected buildings had links to the Department of Finance and the Department of Buildings to verify the information presented to the user.



Problems

Users wanted to understand how much of the neighbors' undeveloped square footage they could buy. Buying new square feet is common in NYC and allows developers to build larger (often taller) buildings.

1. Users had to go to multiple sites to cross-verify if a property had unused Air Rights.

2. One of the critical factors determining whether what was on record was correct was having a correct interpretation of the maximum develop-able building on the lot.

3. No intuitive tool on the market showed the spatial intricacies of buying Air Rights.

Solution

We built the Air Rights as a separate app, a plug-in to the Property Platform app. I designed and built the Air Rights Database using Property Platform’s design framework.

1. Users could now go to a single website to obtain all due diligence information regarding air rights.

2. Users could compare existing zoning for the property using Property Platform without having to retype the address.

3. A onboarding experience helped users get familiar quickly with how the tool and the rules for transferring air rights in NYC worked.

 

Research & Development

 

I listened to our users who requested the additional features from the Property Portal web app. Vivacity also interviewed lawyers familiar with acquiring air rights to understand better the spatial dynamics of aggregating air rights to a portfolio.

I also looked into what other competitors had developed and found the tool needed spatial query functionalities. The competitors' tools were not intuitive and lacked the complex spatial queries that air rights transfers required. 

Air Rights are complicated transactions.

For a buyer to understand the potential development rights of a property they are interested in, they must understand the underlying zoning of each of the properties and be able to figure out the complex transactions that need to take place to consolidate the purchase of developable square feet.

Available Open Data

The data available on NYC Open Data's website is hard to navigate and query. Users also do not have a clear view of the available square footage for the property.

Property Sharks’s solution

Our main competitor, Property Shark, did not have an easy way to query the map for a specific property. Users do not have a search function for addresses or the Building Block Lot Unique ID (BBL).

Property Shark’s Problem

The map also has zoom limitations. At best, it only gives you a high-level understanding of available Air RIghts per neighborhood region.

Design

The app’s tabular information of available Air Rights was designed following the criteria users wanted to see when exploring the potential purchase of neighboring Air Rights. Users told us that they only wanted to see buildings and properties that had available Air Rights. Buildings with no Air Rights were not significant. 

In some exceptional edge cases, a property may geographically sit in a marketplace where Air Rights could be sold outside the adjacent limit rule set by NYC City Planning. 

I designed the UI for simplicity, and a special button appears when the property sits inside the marketplace. The toggle button reinforces the idea that the property sits in a marketplace and allows the user to see all the properties that have available air rights to purchase.

I moved from pencil and paper to digital sketch to Adobe XD quickly. Using the same design patterns from Property Portal helped expedite the design process since that app already defined many interactions.

Onboarding

Some user’s complained about the new app’s interface. We developed a simple onboarding experience based on the friction points users told us they encountered:

  • Selecting new Air Rights on the map.

  • Deselecting Air Rights on the map

  • Toggling on Marketplaces

Production App

Summary

 

The Air Rights database launched nine months after Property Platform. The app was added as a “plug-in” and was successful among our power users.

Lessons:

  1. Listen to user input when developing new plug-ins and features. We still did user research for what seemed like a simple user ask. We created a whole new app to correctly design an experience for a feature request.

  2. I learned that existing design patterns could help expedite the design development process. I could jump quickly from sketch to High Resolution without over-explaining my design ideas to our small team of developers since they were already experienced with the existing design from Property Portal.

  3. Even with users being familiar with the UI of Property Portal, we still had to design a new on-boarding experience. Always listen to user feedback.