3 Weeks in the Life: Creating the Waterfront Access Map
Explaining Labs’ development process using our newest product
We recently finished our quickest project yet — over the course of 3 weeks, we built an interactive map showcasing NYC’s progress towards expanding public access to the waterfront. Since this was a nice, short project, we thought it would be a good example to document and use to explain our typical Planning Labs development process. This post outlines the full collaborative process.
Side note: We were able to build this map so quickly thanks to prior work modularizing functionality we use to build these map apps. These include Labs Layers API (used to serve and style spatial data layers), Labs UI (makes it easy to build legends and other design features), and Labs Ember Mapbox Composer (simplifies the process of building a Mapbox GL maps in Ember.js).
Project Ideation
One mechanism for creating more public space along NYC’s waterfront is via Waterfront Zoning (Article VI, Chapter 2) that requires developers to create public space on certain waterfront private property when redeveloping. This zoning was adopted back in 1993, but many members of the public don’t know about this policy and the new public spaces that are now available to them. NYC Planning’s Waterfront and Open Space team wanted to find a way to better share information about these waterfront public access areas that have been created and approved over the last 25 years.
Pre-build: User design session, wireframing, and data gathering
After we agreed to partner with the Waterfront team on this product, we began research by conducting a design session with members of both the Waterfront team and Urban Design team who are all closely involved with the waterfront zoning program. The user design session is comprised of two activities and takes about 2 hours.
User Design Activity 1
The goal of our first activity is to clearly define the main purpose and intended audiences of the app (before jumping into visual design). We begin by explaining the concept of user stories and asking the participants to frame their ideas using this template: “As a [type of user] I want [my goal] so that [my reason].” This helps the participants more effectively communicate and understand what problems they are trying to solve and why.
We ask the participants to brainstorm the categories of users and their respective goals while documenting the ideas on a whiteboard. Once everyone in the room is aligned on the rough universe of user stories captured the board, we have the participants individually write out more specific, detailed user stories on sticky notes. Then everyone reports back in a round-robin format. This helps us refine and better conceptualize individual use cases. This user-centered activity is a critical precursor for identifying the scope, intended functionality, and design of the product.
User Design Activity 2
Once we’re all aligned on the users we want to serve and their goals, we do a second exercise where we ask the participants to individually sketch out their ideas for the application interface. We then each share our sketches, discuss which commonalities or unique ideas we like, and explain rationales for what different features would help the user accomplish. By the end of this session, we have a shared mental picture of what functionality the app should have.
Wireframing and Translation to GitHub Issues
After the user design session, we synthesize the ideas into wireframes for the app design. This is an important step, because we present the wireframes to our product owners (the Waterfront team, in this case) to make sure we’re aligned on the design vision. The wireframes are also used to guide critical technical aspects of the application development, helping us identify the right app architecture and think through which steps are needed to build it. During this process, we begin populating the GitHub repo with issues for the first build sprint on the project, estimating their level of effort, and prioritizing them by impact on the product’s success. We reference and update these wireframes throughout the build process too.
Data Gathering
During the wireframing process, we outline and gather the required data inputs the app will need. Sometimes these aren’t already available on NYC Open Data, so we have to track them down. We often run into cases where there’s data we want, but it doesn’t exist yet.
This came up during the Waterfront Access project, where we all agreed it would be ideal to have spatial data capturing the actual footprints of the publicly accessible space, rather than only showing the entire property boundary which is much larger and includes space the public can’t access. We discussed ways this data could be created and suggested geojson.io for easily drawing new spatial data. Chris Wassif from the Waterfront team enthusiastically jumped on this task and created an awesome new dataset of public space footprints for all the active Waterfront Public Access Areas. Cheers to new, more accurate open data!
Build: Sprints and demos with users
We organize our application development tasks into week-long sprints. At the beginning of each sprint, we have a planning meeting with our product owners where we communicate and confirm our planned priorities for the sprint (captured in GitHub issues organized using Waffle.io) and clarify questions or potential roadblocks.
On the Friday culminating each sprint, we do a demo of the app. In this demo, we show the latest progress on the app and ask attendees to give feedback on ways it could be improved. We send an open invite to everyone at NYC Planning. Since the Waterfront Access Map is relevant to planners at other agencies (Parks, Economic Development Corporation) and community organizers, we also invited these other external stakeholders to join.
These demos provide us with a lot of valuable feedback on design, language, and new features that would be helpful. This user input gets incorporated into the build priorities for our ensuing sprints. The number of sprint → demo → sprint → demo cycles depends on the scope and complexity of the app. For more complex apps, we also mix in user testing sessions with individual users, but those weren’t needed for this Waterfront Access Map app.
Final tweaks leading up to official launch
Before the official press release announces the project, we hold buffer time for the Communications team to review the app and put together their talking points. We also do polishing of all text and styling. For language and styling edits, it’s often easiest to gather everyone (product owners, communications staff, and Labs developers) in a conference room with a large screen and to do live code edits. It’s a lot simpler and faster to look at the app together and make real-time adjustments while all decision makers are in the same room.
Retrospective with our product owners
After the product launch, we sit down with our product owners to reflect on the development process. We identify things that went well and things that could be improved around communications, coordination, scheduling, etc. It’s important to capture these reflections while they’re still fresh in mind. In the retrospective for the Waterfront Access Map, we discussed how it could be helpful to make the demos more structured with specific prompting questions. We also identified that data updates were a pain point, and we should explore options that would allow our product owners to access and update critical datasets on their own without the Labs team needing to make edits for them.
We hope this was useful for understanding how Labs’s development process typically works. Please comment if you have questions or want us to cover specific topics in more depth.
