Interaction design project

Designing a solution to address overcrowding in public parks — iOS app

Park Finder

Overview

About the project

During the spring and summer of 2020, as COVID-related restrictions began to loosen, people flocked to one of the few remaining social spaces: public parks. As a result, the city of Toronto was contending with overcrowding in some of its more popular parks. This was likely compounded by the fact that green spaces can be hard to find - if a park isn’t already on your radar, you’ll probably only discover it by coincidence.

To address these problems, I wanted to design a tool that would tackle both overcrowding in parks and the challenge of discovering new public spaces.

Scope

user research, user personas, user flow, sketching & wireframing, visual design, prototyping, user testing

Duration

June - July 2020

Tools

Adobe (Illustrator & Photoshop), Sketch, Flinto

View the app

The problem

Many younger, downtown-Toronto residents don’t have access to a backyard. During COVID-related lockdowns, they were therefore relying on public spaces to socialize. However, there was no way to check real-time crowd sizes. Park visitors who wanted  to maintain social distancing might have been stuck once they arrived at an overcrowded space.

Providing these park-goers with a quick tool they can pull out of their pocket to either plan ahead or to find a nearby and crowd-free alternative might help to alleviate some of the overcrowding problems in parks.

Fundamental questions

To get to know my potential users better, I wanted to answer these three fundamental questions:

1

Who is using green spaces in Toronto right now?

2

What are they doing in those spaces?

3

What are their motivations for being there?

Research plan

I chose to observe four parks of varying sizes throughout one week and to make note of who was there and what they were doing. I also planned to "unofficially" keep tabs on various other parks during my daily dog walks.

While observation would tell me who and what, it wouldn't tell me why. I therefore planned to interview a small sample of people who would be representative of the demographics I observed. A few in-depth interviews would give me greater insight into park visitors' motivations.

Results

1

Who is using green spaces in Toronto right now?

People aged 25-45, either "young professionals" or young families.

2

What are they doing in those spaces?

Socializing in groups or relaxing by themselves. Most of the groups socializing in bigger parks were with friends, whereas people in smaller parks were part of a young family unit. About half the visitors had bicycles, suggesting that they travelled to the locations.

3

What are their motivations for being there?

If in a group, people are at the park to socialize. By themselves, people come to a park for a change of pace or scenery.

I'll discuss my results and related insights in greater detail below.

Insight #1:

Young families already have preferred parks

Park visitors I observed largely fell into two demographic groups: 25-35 and 35-45.

The two demographic groups were predictably segmented based on the location of the park. The younger group tended to visit parks located nearer to busier streets and subway stations.

Meanwhile, the older group tended to visit what I'll call “neighbourhood” parks — smaller-sized parks or schoolyards in residential areas. These neighbourhood parks functioned as the local meeting spot. I noticed the same families returning to these parks repeatedly and socializing together.

I concluded that it was not worth pursuing the 35-45 demographic. These families would have had little motivation to find new parks since their local spots were never overcrowded and were already providing their necessary social space. So, I turned my focus to the younger demographic exclusively.

Insight #2:

People prioritize convenience and familiarity

My interviews confirmed my hypothesis about what my primary user would look like: people who have been forced to use parks as the primary socialization space during the pandemic.

One interview subject described going to the same park every day and called the park,

a meditative break from the city.

This subject lived a five-minute walk from a large park and rarely visited others unless it was to meet friends. In those cases, they’d meet at a central, accessible location, like Trinity Bellwoods or Christie Pits. (This explains frequent overcrowding in these two very popular parks.)

Another subject described going to High Park most frequently since they lived nearby, while also firmly describing it as not a favourite park.

People also shared the same unifying complaint about certain parks: overcrowding. They had no other complaints related to their park experiences.

Ultimately, most people’s motivations for going to a park are very similar. They’ll likely visit whichever location is most convenient. For someone going to a park on their own, that will probably mean the biggest and nearest park (as per my High Park subject). For someone meeting friends, that will mean the park that is well known and centrally located.

The user

I thought creating user personas would help both formally define my user and prevent scope creep.

Based on the research I’d collected, I decided to create only one persona. Because all the motivations I found were so similar, I didn’t think additional personas were necessary.

In creating my persona, I focused on including only details that I’d been able to observe and that were relevant to the project. I also chose to keep the format to a narrative-like structure, according to recommendations in About Face, which I found helped to foster a better sense of empathy with my prospective user.

Natalie is 26 years old, works as a digital marketer at a local software company, and lives in downtown Toronto. She moved to the city for school, then stayed for work, so her family lives back in her hometown.

With ongoing social isolation recommendations in effect, Natalie’s normal routine has been thrown upside down. Although under normal circumstances she spends time in parks during the summer months, now the park is where she spends most of her time outside the home. In addition, with her family living back home and no homeowner friends, she doesn’t have regular access to private outdoor space (i.e. a backyard).

After a day spent working from home, Natalie needs a break from her apartment. She’ll walk to the local park to read or people watch. She enjoys the green space and change of scenery. When she’s missing her friends, she’ll meet a few at a time for a socially distanced walk or picnic in the park. When meeting friends, she’ll often use her bike and bring it into the park with her.

On evenings and weekends, trying to find a good spot in a park can be challenging. Since most of her friends live in the core of Toronto as well, they like to meet in central locations that are easy to find and get to by bike or foot. She favours parks that have big, open fields since they provide plenty of places to sit, relax, and spread out. However, many of these parks are very popular and often become overcrowded. Natalie had stopped visiting Trinity Bellwoods long before it was on the news for this very reason.

Natalie also finds it difficult to discover new parks that fit these requirements. Often, she knows about a park because it’s either big enough to be a central landmark or because she stumbled onto it by accident. Natalie would like an easier way to find parks that fit her and her friend’s needs: lots of space to sit, fewer people, and centrally located.

The user journey

Based on my research so far, I mapped out what I thought the typical actions look like when Natalie is visiting a park, both alone and to meet friends.

I knew the tool would need features that address the question asked in both lists: "where should I go?"

At this point, I realized that I was defining a search tool. This naturally led me to realize that I could define my results (in this case, the right park) with search filters.

I decided to identify these filters to help me define the best format for the search tool.

Given that the user's goals are simple, the list of filters was short.

Next, I created a high-level workflow to match Natalie’s real-world behaviour to the app.

Sketching the solution

By this point, I was closing in on my preferred solution and wanted to begin sketching.

I knew that I wanted the user to be able to both plan their trip ahead of time and look up alternatives at the last minute. So, I decided that a mobile app would be the best way to achieve those goals. I also chose to design my app for iOS, because their predefined styles would allow me to put more focus on the functionality over the interface design.

Next up, I brainstormed some ideas for what each of those features (including the search feature) would look like. Finally, I moved to pencil sketches of what each screen of the app would look like as I continued to drill down to my final solution.

I considered various options, from a checklist of preferred features and a thumbnail list of reviews, but ultimately settled on a simple map-based interface. The main advantage of the map is that it's very efficient: with one screen the user can change the search parameters to a different location and see all their results at once.

Wireframing and testing

I wanted to test my design as soon as possible so that I’d be able to course correct easily. So I quickly transformed my sketches into a digital wireframe. I used a map of Toronto and animated the wireframe so that it would behave more like a real map-based interface.

On my first test, there were no issues except for one completely unexpected problem: users were stumped when it came time to press the “search this area” button and spent a few seconds looking around the screen, unsure of what to do next.

In response, I decided to eliminate the step altogether: now the results would simply pop up on the screen as the user ticks off their preferences, and reload once they pan the map over to a new area.

A quick test proved this to be really easy and intuitive. At this point, I’d whittled the app down to just a few screens.

Interface design and details

Feeling like I'd taken my wireframe as far as it would go, I decided to start working on the interface design.

I wanted a design whose aesthetics were drawn from nature to evoke what my interviewees talked about experiencing in parks: feelings of relaxation and ease. I also wanted the colours to match the park thumbnails that would populate the app. So I took inspiration from the picture of a popular Toronto park below and chose a somewhat muted green/blue colour scheme, which later shifted to green and a beige pulled from the map to create a soft monochrome effect.

More changes to the interface

Although I thought I was finished with the bigger elements, once I started designing the interface, I felt that the filter buttons looked clunky and weren't very scan-able. So I decided to add icons to help this issue.

After trying out a few variations I ended up opting for icon buttons with explanatory labels underneath, grouped by category. This new design allowed me to devote more screen space to the map.

Usability testing and the final product

To test the high-fidelity prototype, I gave the screens basic animations again (a pulsing location indicator, reloading pins, and a pan effect on the map) and put the test prototype in front of a few people.

Overall, iOS users had no problem with the app and found it easy to use. Interestingly, my android user stumbled on the “share” stage because they weren't familiar with Apple’s icons.

Also, for the fun of it, I gave the prototype to a few people outside of Natalie’s demographic and they were a bit confused — they were thrown off by the icon menu and didn’t immediately think to pan the map over to their preferred location.

Given that I had explicitly designed an iOS app for a specific demographic, I was very pleased with these results. Take a look at the GIF below for the final product!

Final thoughts

Real-world application

How would this crowd-tracking feature work in real life? In an ideal scenario, I’d have access to Google or Apple’s data tracking and be able to set a metric to gauge crowds (ex. x number of people per y square metres). A “good enough” solution is to use a library such as this one or use Google's API for Popular Times, which is currently pending release.

User specificity

I think it’s worth noting how well this app worked for a specific user type — iOS user, 25-35 — but caused problems for people outside that group. Although my current research suggests that other demographics might not be interested in the app, additional work would have to be done to make it usable for more people.

conclusion

Overall, this was a great exercise in restraint. It took a lot of patience, focus, and openness to both good and bad ideas in order to whittle away every unnecessary step. In particular, I was surprised by the constant temptation of scope creep. Ultimately, thanks to a determination to stay on task, the end result is a beautifully simple product.

Feel free to say hi!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.