Marking your Parking

Marking Your Parking: A UX Case Study

This is a case study of a day’s sprint to create a native app where people can monetize their driveways, garages, and private space, as well as rent other’s. In an attempt to practice agile UX our team at the General Assembly UX/UI Bootcamp walked through this comprehensive design process.

Team: 2 people (me and a partner)

Tools: Sharpies, Post-its, Dry Erase, POP app, paper

Design Challenge: Create a native app that is “AirBnB” for parking solutions

Scenario: A parent that must park every morning near their child’s school in order to walk their children in. All street parking is permit only and there are no meters. There are plenty of driveways though!

1. Comparative/Competitive Analysis

  • Objective: to understand what features are in existing solutions and how our product could be better
  • Tools: sharpie/post-its/whiteboard/markers/Google/App Store (to search for competitors
  • Deliverable: Feature comparison grid

We searched for possible competitors, looking at most popular parking apps downloaded on the AppStore website, looking specifically those apps that seem to allow you to park in private driveways or lots. The three apps we chose to include in our analysis were: Just Park, Parker, and Monkeyparking.


Inclusion Criteria

  • GPS Map- for visual aid to help you estimate local distance from end destination (school) as well as for directional purposes when navigating towards your parking spot
  • Voice Navigation- to help guide you to your destination
  • Time Scheduling Interface-to help plan out weeks or months in advance
  • Timing Meter- to show you how much time you have left on your parking reservation
  • Contact/Messaging- ability to easily contact/message the owner of the parking rental in case of need
  • Account History- ability to view, or re-book previously used spots
  • Local Events- provided information on local events that might limit/effect parking scheduling
  • Payment Options: having multiple payment options (credit card, Paypal, Apple Pay, Android, Venmo) We used icons to indicate the different payment options available

We discovered that although these apps provide a “map” they do not all provide a time scheduler, a way to easily contact the owner, a time meter, nor an account history, and usually provide only one method of payment. Competitive analysis proved to show us what common features seemed to be essential, and help us brainstorm ways our app could meet user needs that the competition did not yet meet.

What’s the Problem?

Before going any further, we wanted to identify the problem. Although we were given a scenario and task, I thought it would be important to identify the exact problem we were trying to solve.

Problem: "making parking easy, when there are not many parking options"

There were apps that mirrored the Airbnb concept, but did not necessarily provide the seamless and complete assistance that Airbnb capitalizes on.

Since people will most likely be using it in an already potentially stressful situation, the app not only functionally has to be simple, it has to be visually simple, as well as providing the A to Z assistance one might need.

2. User Research:

  • Objective: identify user needs, pain points
  • Tools: user participants, pen and paper, survey tool
  • Deliverable: user survey and emergent themes/elements of what users need out of our app

Limited by time and resources, we brainstormed how we would conduct this part of the design process. We would have extensively conducted user surveys and interviews of people who use apps like these on a regular and also irregular basis, to both gain qualitative and quantitative data.

3. The User

  • Objective: identify our user, demographics, prior knowledge of content, culture, education level, habits
  • Tools: pen and paper
  • Deliverable: 5 w’s + H (who, what, when, where, and how) and a Persona

>WHO? Parents who need to drop off their kids at school, mild-tech capabilities (able to use most simple iOS and Android apps), is short on time and likes apps that make life more convenient.

>WHAT? (level of tech knowledge)Uses social media, uses Google Maps, prefers to buy movie tickets online before going to the theater.

>WHEN? Users will check the app before and after dropping off their kids (7:00 am and 2:00 pm), and at home when scheduling rides.

>WHERE? Will use the app on the road before school and after, also at home occasionally.

>WHY? The main motivation is to be able to have a reliable spot available for a small fee to avoid parking problems in neighborhoods where there is not much street parking, but there are a lot of driveways.

>HOW? They should be able to access the native app on their mobile device, as well as online.


As a part of identifying our user, here we focused on identifying touch points, pain points, needs & goals, and potential solutions.

We started with the description and drawing (icon version of my mother, note the hair flip). Our user “Chauffeur Charlotte” was a mom in her early thirties with two kids that are K-12 and go to different schools. She also works and an agency, so she has to schedule her mornings well which includes dropping off the kids. She has finally had it with finding no parking near her kids’ school and wonders if there is another option.

To summarize we discussed and identified every moment we suspect the user to meet frustrations in her day when she does not have an app to determine needs and possible solutions to our “user”. I thought about how early Charlotte would start thinking about her parking needs, and suggested the option of creating a simple mobile device app, but a more extensive website scheduler that allows Charlotte to plan out her whole week or month’s parking needs.

Deviating from just “mobile” to “mobile and desktop” allowed us to keep our mobile app simple by keeping all the logistics of scheduling a month’s parking itinerary online in a more editable space. The user would be able to see a full month’s calendar and schedule regular times according to availability shown on a map. The user would still most likely spend 15% of their time on desktop and 85% of time on mobile.

4. Storyboards/User Flows

  • Objective: to convey the idea of our native app through a storyboard
  • Tools: dry erase marker and whiteboard
  • Deliverable: user flow diagram and storyboard

This is particularly my favorite part of the agile process. Creating the story of the the user often brings up scenarios or issues that may have been overlooked in earlier processes. Really getting into the shoes of the user and playing it out, I think is an essential tool to discovering good design solutions, as in this case were we decided that the app should visually be very simple since our user would most likely interface with the application while distracted on the way in and out of the car. We therefore took out some of our initial capabilities to keep it clean and simple.

Personally, what I enjoy most about UX is the story element of the design process. But there is a story behind everything and it’s really the stories that draw in people and give people a memorable/delightful experience. With our native app, I was really motivated by the story of a parent trying to be more engaged with their children by dropping them off at school in person, rather than the curve. It reminds us there is purpose behind our work and creates a greater narrative to what design we are trying to develop.

5. Card Sorting

  • Objective: to sort different features of the app in an information hierarchy and focus on the most important needs
  • Tools: dry erase marker and whiteboard, post-its
  • Deliverable: filtered list of main features our app ought to have

Based on our persona and user flow, we considered which features we gathered on post-its were essential and which were niceties that obstructed the simplicity of our app.

Keep it simple.

6. Information Architecture (Sitemap)

We quickly sketched out a site map, putting in order the different screens that a user would go through to accomplish one cycle of reserving and parking in a spot. Starting from the user’s profile and ending with an reminder notice from your phone letting you know your reservation is almost over.

7. Wireframes

  • Objective: to layout the pages our user will interface with to gain a better overview of the app’s design
  • Tools: iPhone templates, sharpies
  • Deliverable: wireframes

8. Prototype Prototype Prototype

  • Tools: POP App
  • Deliverable: working prototype

We made a quick prototype with the app POP, which we used to take photos of drawn screens. We were able to walk through a demonstration of our prototype to the larger group, discussing the our process and why we made different design decisions. We got a lot of positive feedback, as our concept to provide an easy way for people to schedule our their whole month’s parking schedule was original.

Taking the project further:

I personally would conduct cafe studies and RITE (Rapid and Iterative Testing and Evaluation), making changes to my prototype after every interview. With the RITE process, you can quickly go through user research and many prototype iterations at the same time. Through it, I made some changes to the opening menu and added a “snooze” action where you can add more time to your reservation if need be.

Things I learned:

1. Don’t reinvent the wheel. A lot of things have wheels…like airplanes.

When we approached this design challenge, we were told to think about an “Airbnb for parking”. It’s true…there is no need to reinvent the wheel, but you can improve it and adapt it for different needs. If the wheel has major issues, then let’s apply some user research, get some different prototypes in there. If we need to solve a different problem, lets see first how others have answered similar problems. The creative process of building off of someone else’s great idea may start of feeling unimaginative, very inside the box, but I have learned when you rely on a solid UX strategy/technique, creativity will follow.

2.  You cannot take out REAL usability testing for a REAL product

For the purposes of this sprint, we explored usability testing on a “theoretical level”. However, you cannot take out testing from the design process. Different elements I learned from some simple usability testing led me to adapt the design to consider……

3.  I can’t believe UX it’s a job

Throughout this whole design challenge, I had so much fun. Even though I have been through the agile process countless times now, every time I enjoy it so much I can’t believe that UX is a job. The use of method, strategy, creative and critical thinking really stretches me and gets me excited to work. The experience of doing User Experience brings me joy, which is great cause then I can bring that joy to users.


Project Continued

After the bootcamp, I took the project further to create some wireframes and click-able prototype using Omnigraffle and InVision, based on the work we did that day.