Day 2: Need Finding & Competitive Analysis
Saveen Chadalawada & Eric Kingsley
Need Finding
With our logo set, our next challenge was to figure out our user base. We began by brainstorming interview questions that would help us understand what a user would want to see in the application. Questions such as “How long does it typically take to find a parking spot?”, “What type of features do you think a parking application should have?”, and “If an app helps you find parking, would you, in turn, help others by sending a notification when you leave even if there is no incentive?” were recorded. In total, we came up with 10 questions that we felt would help us highlight the needs of the user.
A few group members immediately set off to gather data while others built a Google Form to collect data remotely. Over the course of several days, the team gathered a myriad of data sets from 17 potential users. Each team member interviewed approximately 3 people from each of the 6 different categories of users (student, grad student, staff, faculty, visitor, & disabled). Our next task was to parse through the data, find patterns, analyze, and develop strategies and specific app goals.
From the obtained input, it was clear the majority of responses were going to come from students. As expected, it was found that 75% of the survey takers are between the ages of 18 and 30 and 25% are 31 years old or older. Furthermore 60% of the responders answered that they were students.
For an app geared to people driving around campus and finding parking, we found that 13 of the 17 responses to be from commuters that drove to school. We also found that people generally try to find parking closest to their end destination. Popular parking destinations included the parking structures, Regents Lot, and Glider Port. This gave us insight into where the best places to prototype our app would be. In a comedic turn of events we discovered that students were complaining that there were too many B spots (Grad Students & Staff) and not enough S spots (Students). Grad Students and staff were complaining that there were too many A spots (Admin & Faculty) and not enough B spots. And our one faculty interviewee said there weren’t enough A spots to park in!
The main question we were gathering data for was how long, on average, it took drivers to find parking. From the results, approximately 50% of the survey takers didn’t agree with the 5–10 minute or the 10–20 minute options. We interpreted that it takes half of our responders more than 20 minutes to find a spot. This meant that our app could help solve a problem that a lot of people have and that it would have a huge user base.
The part that was most pleasing to us, was that all 17 people interviewed said they would take the small amount of time out of their day to alert other drivers of an open spot when they leave. On top of that, all 17 mentioned that they wouldn’t even need an incentive to let other users know which was one of our biggest fears. In contrast, however, we found that if the app doesn’t find the user a parking spot, they would be less likely to use the app and alert others when they leave. This means prioritizing that the app works all the time, every time for the user.
Competitive Analysis
In order to get a better idea of how our app should function, we looked up examples of how similar apps are laid out currently. Luckily we weren’t able to find an app exactly like the one we had in mind. The closest options were Monkey Parking, BestParking, and ParkMe — apps that reserved parking spots at a cost. Beep, on the other hand, would offer a crowd sourced alert system to allow people who are leaving a spot to alert people who are looking for a spot for free. Regardless, there were some key implementations that we noticed that would work well in Beep and also some ideas missing that would help Beep stand out.
Features that piqued our interest include the use of analytics to predict parking behavior in the future, the ability to find parking close to the user’s current location, and the ability to filter parking locations using some attribute. In our case, that attribute would be permit type as users with an S permit wouldn’t want to be alerted if a user in an A spot is leaving.
One major component that Beep must contain is the ability to notify users in real time. We were surprised that similar app “competitors” didn’t implement such a feature. In their defense, reserving spots doesn’t necessarily have to be in real time, while notifying would.
Finally, a component that we definitely want to stay away from is the ability to reserve parking spots. Monkey Parking was even banned in San Francisco for using a reservation system that users could abuse and exploit. We don’t promise a user a parking spot, we just want to make it easier to find by providing them knowledge of when another user leaves.
Conclusion
Overall, we got a lot of great data that is definitely going to help us iron out the kinks in our design. We need to prioritize a simple user experience with the app working. It also needs to be different enough from other apps so that it stands out from the competition. We also have a general idea of what features we want to add and what features we don’t want. It looks like we have our work cut out for us!
