Applicant Maps, our newest product
Making it easier to submit land use applications and saving staff time
We recently launched our most ambitious product to date, Applicant Maps. We partnered with NYC Planning’s Technical Review Division to bring this app to life. The goal was twofold:
- Make it easier for people to produce the maps required for applications to the City Planning Commission for land use approvals
- Reduce NYC Planning staff time spent checking and reviewing those maps
These maps can be time consuming and expensive to produce, requiring GIS experience and specialized software. Applicant Maps is a free, self-service tool that reduces this barrier to entry. The app guides users through a wizard where they define their project’s proposed land use changes in order to produce an “Area Map,” the most complex map required from applicants. An Area Map shows the applicant’s proposed development in context with the surrounding land uses, proposed zoning, current zoning, and transportation assets. The maps must follow a detailed and rigid set of map styling rules, so that they are consistent and easy to digest for specialists and the City Planning Commission that review the applications.
Not only does this new app make it easier for applicants to produce required materials, it will save NYC Planning staff time spent reviewing maps. Applicants often make small mistakes in their maps, requiring our staff to review them thoroughly and sometimes do several rounds of comments and iterations with the applicant. Applicant Maps generates maps that are fully compliant with NYC Planning’s standards, which helps to speed up this time intensive review process.
Applicant Maps has been NYC Planning Labs’ most ambitious and challenging project to date. This post recaps the design, user research, and build process, additionally sharing future plans to expand functionality.
User research, design, and build iterations
We’ll be honest; we significantly underestimated how complicated this product would be. To date, most of NYC Planning Labs’ apps have been data explorers, where users simply click around to access data. This app is the first we’ve built that requires users to complete a specific task that has very rigid requirements and do it correctly. It turns out coaching users who often don’t have GIS experience through the process of drawing precisely in a web browser is pretty challenging.
The experience of building this app underscores the value of iterative, agile development guided by frequent user testing. Many of our original assumptions were proven wrong along the way. We had thought Applicant Maps could be built in a month; instead, it took about 6 months. Much of that time was spent testing the app with users and revising our designs based on crucial insights identified with users.
Following our typical process, we kicked off the project with a design session where the development team and our partners in the Technical Review Division completed a series of exercises to help make sure human-centered design remained at the forefront of our decision-making. By first defining who the primary users are and the goals they want to achieve, we could then discuss specific features of the application and make some assumptions about how Applicant Maps should work. The goal was to prototype quickly, test those assumptions with real users, and iterate.
We began with a design that laid out all the project inputs on one page alongside a large map: inputting the project name, development site boundary, project area boundary, and proposed rezoning. Users were expected to populate all their project details at once, assuming they knew what terms meant and what they needed to complete.
To test this design, we recruited stakeholders from other City agencies and private sector consulting firms that frequently submit land use applications. In the first round of user testing, we quickly discovered that users needed more guidance. The design of the app laid out too much functionality at once, without enough context to help the user understand what they needed to do. This design might work for some power users who are already very familiar with producing these maps, but wouldn’t achieve our goal of making these maps easier for a broader population. Applicant Maps needed to be as self-explanatory as possible.
So we went back to the drawing board and developed a wizard work flow that coaches users through a set of questions, only showing them functionality if it’s relevant to their proposed project. This provided a much better user experience that ensured the final map had all its required elements. However, it also required a more complex application architecture — a necessary trade-off to ensure that users produced complete, reliable maps.
After we implemented the wizard, we did another round of user testing to validate those improvements. This round of testing helped us identify confusing language, written instructions that users ignored, and ways to improve the user interface for drawing project features. Based on these insights, we next strove to make visual cues more obvious in the app, such as making lines and points higher contrast and recording eye-catching GIFs that coach the user through the drawing steps.
After we made those changes, we did a final round of user testing before declaring Applicant Maps ready for use.
What’s next? More maps! And more user feedback!
There is high demand to expand Applicant Maps to produce other types of required maps. These maps are at the top of the list:
- Zoning Change Map
- Zoning Section Map
- Tax Map
- MIH (Mandatory Inclusionary Housing) Map
- Fair Share Map
Before we jump into building functionality for generating additional maps, we will be working closely with NYC Planning’s Technical Review Division to monitor the quality of the Area Maps produced using Applicant Maps. We’ll also gather feedback from applicants to ensure they’re having a positive experience with the app when creating maps for their projects.
If you will be using Applicant Maps, we would love to get your feedback! Tweet @nycplanninglabs or create GitHub issues for bugs or ideas.
