Explaining Labs’ development process using our newest product

Hannah Kates
Nov 30, 2018 · 6 min read

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.

Labs’ typical development process is iterative and driven by frequent input from users

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

Diagram illustrating publicly accessible space on private waterfront property

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

Brainstorming the universe of likely users and goals

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.

User stories captured in the user design session

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

Sketches from the user design session are used to identify priority functionality

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

Wireframes help us communicate with users and make app architecture decisions.

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.

The dark green shows the footprint of the publicly accessible space (new dataset!) while the light transparent green shows the full boundary of the private property.

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.

Demos are an important forum for us to get honest feedback and suggestions from users throughout the build process.

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.

NYC Planning Digital

Notes on data, engineering, and design @NYCPlanning

Hannah Kates

Written by

Urban planner focused on using civic tech and data analytics to help cities operate more efficiently, sustainably, and equitably https://planninglabs.nyc/

NYC Planning Digital

Notes on data, engineering, and design @NYCPlanning

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade