312 Park is a service provided by the city of Chicago to help drivers in the city find parking spaces, keep track of their car and add time to meters remotely via a smartphone app. It helps drivers avoid unnecessary stress and parking tickets by letting them check location-based parking regulations and receive automatic alerts and notifications. 312Park leverages government data to recast the City as a provider of services that citizens actually want to use.

For our 14-week Service Design workshop at the Institute of Design, we were challenged to develop a plan for a new government service provided by the city of Chicago. There were four specific constraints: the service must utilize the city’s proprietary ‘big data’, it must generate revenue in a way that is not punitive, it must improve the experience of living in the city, and it must evolve with the user over time.

Our team chose to focus on the experience of owning a car in Chicago. We conducted primary research and quickly discovered that parking is the biggest pain point for drivers in the city. Parking regulations in Chicago are extremely complicated and arcane. Street signs — if any — are notoriously cryptic and difficult to understand. City parking meters, which are now leased to a private company, are poorly designed and far from user-friendly. In addition, Chicago has some of the steepest metered rates ($6.50 per hour downtown) and parking fines (starting at $50 for an expired meter) in the entire country.

To solve this problem we saw opportunity in combining existing datasets — like historical traffic flows, Illinois vehicle registrations, parking meter transactions and zoning maps — with user-provided or generated information. The City of Chicago is proactive about collecting data and making publically available (data.cityofchicago.org) and there exists large amounts of data that could be leveraged to help people navigate the parking landscape. To provide a timely and responsive service, we decided this general data must be cross-referenced with user-specific data — like geolocation, car registration and permits.

There are a few Chicago-based apps (ParkWhiz, SpotHero) that point drivers to available spots in paid garages, yet, there are none that attempt to solve the problems of street parking. In designing 312Park, we strove to address the major issues of street parking, as revealed by our research, in the most intuitive way possible and plan for interactions with other parts of system. For example, by storing accurate information pulled from the City’s own databases for each parking session (date, time, location, duration, zone, etc.) and supporting a report function, 312Park allows a driver to contest a wrongfully given ticket.

Throughout our work, we were also mindful of proposing an implementable system. We constrained 312Park to existing technology platforms as well as to infrastructure already in place in the City and its technical capacities. This meant taking rigorous consideration of all the different interests of the existing stakeholders that our solution would touch.

Our initial idea for this challenge was around a way to aggregate citizens’ interactions with various city services. To that end, we started by interviewing a range of Chicagoans to hear first-hand about their experiences with libraries, waste collection, public parking, etc. We also visited the Secretary of State and City Clerk’s Office to conduct observational research and speak to employees about the most common interactions they have with citizens. After this first round of research, we quickly found that there was an overwhelming amount of frustration and negative emotions directly related to owning a car in Chicago. The team decided to focus on this opportunity space more deeply.

After some quick secondary research to familiarize ourselves with existing technology and other offerings in this space, we fleshed out our core offering through service scenarios. Specifically, we made a very lo-fi video to externalize key moments (page 22 of Supporting PDF). As we worked through service journey, we created a map to show data interactions and pivot points (page 23) which later became the foundation for an detailed service blueprint of the entire 312Park experience (page 17). The blueprint describes how people engage with the service at each touchpoint and shows where necessary public and personal data comes from. From the service blueprint, we identified critical touch-points in the overall experience to be prototyped (page 25). These paper prototypes were invaluable in communicating our offering to users and the low fidelity empowered interviewees to mark things up and give candid feedback (page 24).

In addition to Chicago drivers, key stakeholders we considered included the City of Chicago, Chicago Parking Meters LLC, the Illinois state government, and other private parking garages.

312 Park presents a powerful opportunity for the City of Chicago to disrupt the current relationship it has with citizens. The majority of people we interviewed had a negative attitude towards City government, much of which was fueled by memorably bad experiences with driving and parking. They felt like the City was ‘out to get them’ — that parking regulation is a malevolent and wholly punitive endeavor, rather than the City’s earnest attempt to manage a scare resource. By offering a service that takes greater responsibility for citizens’ adherence to parking laws and shifts the burden of knowledge off of drivers, the City of Chicago can recast itself as the facilitator of great everyday experiences instead of mean-spirited meter-maids. For many people, driving and parking in the city is a daily activity. Providing a low-cost tool that eliminates much of the stress of car-ownership could have significant impact on quality of life for Chicagoans. Rather than be perceived as greedy, with 312Park the government could prove to citizens that it's trying to be a fair player. Parking regulation is necessary to keep city streets safe and organized, but it doesn’t have to be a source of misery if drivers are given the right information at the right time.

To identify the most important and meaningful leverage points we began by listening closely to our interviewees. In addition, parking is a pretty common experience, so we were able to rely on our own stories and the anecdotes of friends and family as well.

The number one complaint was that the rules around parking are opaque and the signage the City provides only creates more confusion. We discovered that lack of knowledge and clarity of the rules leads to other pain points. For example, if you can't understand the signs you have to pull over frequently to read them and waste time. Additionally, if you find a spot but have to was to confidently verify the rules, the odds of getting a ticket are higher.

Building off of the first insight, we found that just having access to information about parking rules is not enough. The information must be contextually relevant because the rules are variable based on season, day or week, time of day, and of course, location. The solution to this problem was to cross-reference the City's data with the user-generated information so that the app could provide relevant information just-in-time.

The last major insight that drove our design was all of the work-arounds that users have for keeping track of their car, the time on their meter and the changing parking rules. From slips of paper, to text messages, to photos, everyone we spoke to had a system for keeping parking information top-of-mind. This inspired us to incorporate an intuitive 'push' tracking system and provide users with time and location based notifications so they no longer had to rely on their memory or work-arounds.

The service script is derived the from natural sequence a driver takes to find a parking spot. Even before heading out, the user can enter an address to see a "heat map" of projected parking availability in that area. The map shows relative ease or difficulty of parking with a familiar red, yellow, green color-coding system (see page 9 of Supporting PDF) and allows users to estimate the cost.

Once a driver has found a potential spot, hitting "Park" on the app will references the location, day of week, time of day and vehicle permits with the database of Chicago parking rules. It will return a contextual recommendation to the driver: safe to park, park with caution, or don't park here (page 7). If the parking spot is no good, the app will suggest others nearby.

When the user (and his or her device) leaves their car, a parking session is initiated via geolocation (page 8). The session data includes the location of the car and relevant rules (page 10). For metered sessions it also shows the amount of money paid and time remaining (page 13). Because the app has access to credit card transactions, users can add time to their meter remotely (page 12).

After each parking session the app stores and aggregates all the data. Users can run reports of their parking history and export them to email. The report allow drivers to see trends in their usage and even provide evidence to dispute parking tickets.