ParkPass

Designing a better guest vehicle registration experience for big-city apartments. Inspired by my real-world experience with an awful parking management app.

Company: None (Case Study)
Project Role: Lead Designer
Timeline: Late Summer 2020
Tools: Adobe Xd, InVision

ParkPassHeroImage-1

Introduction 💡

The ParkPass Case Study was a start-to-finish app design case study I performed after a series of bad experiences with a guest parking management app I use every day, Pass2Parkit. This Case Study allowed me to showcase my Design process and thinking, while highlighting what I've learned through my work in Product Design at Oracle.

Approach 💭

This was a thorough, start-to-finish UX Design Case Study. I began by evaulating the inspiration app for this project, Pass2Parkit. I conducted User Research in the form of interviews and surveys, after which I brainstormed what a new parking management app would look like based on my feedback and comments from the research. From this brainstorming and sketching session, I developed a user flow and wireframe for the new app. I further developed this wireframe into a high-fidelity prototype, building out the app's look and feel while also testing out interactions. I then took this new prototype back to my interview subjects, who provided feedback on the new design.

01     -     Inspiration

About a year ago, I moved into my new apartment in Austin, Texas. While there was a lot to love about the new place, one thing I really didn't love was the app I'm required to use to allow guests to park in my building. The app is frustrating, confusing, and many simple features don't even work. Every time I'd use the app I'd think to myself  "man, there has to be a better way to do this". And then I remembered - I'm a UX Designer! I can find a better way to do this! And now here we are, with ParkPass. Enjoy. 

Design Process

As mentionied in the introdution, the Happenings App prototype was the culmination of a semester-long project for SI 487 - Interaction Design Studio. Throughout the course of the project, we...

02     -     Pass2Parkit Guest

Currently, my apartment uses an app called Pass2Parkit Guest to manage guest vehicles. To put it politely, this app leaves a lot to be desired. It's difficult to use, buggy, and is missing fundamental features required to allow users to register their vehicles. But hey, don't take my word for it - almost twenty people rated the app 1 Star on the App Store - I'm clearly not alone in my frustration.

Problem Statement Definition

The first step taken for this project was the defining of the problem statement. Each group member came into the first meeting with a specific problem that they wanted to address, and the following problem in particular stood out: staying up-to-date with on-campus events.

At the University of Michigan, there is currently no tool available that helps students discover organizations or events based on their interests.


Having clearly defined our problem, the next step was to look at the competitive landscape - who has attempted to solve this problem already?

Screen Shot 2020-09-14 at 3.29.06 PM
Screen Shot 2020-09-14 at 2.35.25 PM
Screen Shot 2020-09-14 at 2.42.56 PM

You get the point. Not good. The negative user reviews, along with my (personal) negative experiences with the app, strongly indicated that big changes to this app were necessary for it to meet the needs of its users.

03     -     User Research - Interviews

While it was great to have the User Reviews and my own experiences with the app as a point of reference for the development of the new app, any good Designer will tell you that user experiences vary widely, and I couldn't assume that the experiences of other users would be the same as mine. Therefore, before moving any further, I needed t confirm whether the sentiments expressed by me and in the user reviews presented themselves in research at scale. I began my research by interviewing current users of the app. I selected three people I know who had used the app within the last month. One of the users, Jacob Zimmer, is a resident of the building - he registers his guests' cars on their behalf when they visit. The other two users - Varchas Raman and Hannah Rotchel - are guests, and use the app when they visit the building. From each of these interviews, I was able to get insightful feedback about Pass2Parkit in the user's own words - feedback which would guide the design of ParkPass.

Competitive Analysis

When identifying potential solutions that attempted to solve the same problem, we considered all possible approaches, including non-digital solutions. After discussion, we identified six unique solutions that would be considered relevant to our problem space.

varchas_headshot

Interview #1: Varchas

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

Varchas uses Pass2Parkit frequently, as a guest, and doesn't want to have to memorize a phone number to be able to park.

How many times have you used/how often do you use PasstoParkit?
I use it about once a week.
Describe your experience with the app.
I like that as a guest I can register my own car. I don't like that I have to put in someone's phone number every time, which I don't know off the top of my head. Also, you can't see if a room's parking allotment has been hit yet.
Highlight, for me, your biggest issues using the app.
Probably having to put in someone's phone number whenever I have to park. Also, the disconnect between the apps - when I register, the resident can't see that I already have.
What about the app do you like?
I like that I can register myself, and it's relatively quick.
Is there any feature the app doesn't have, that you'd like it to have?
If you're not trying to park for 24 hours, the ability to reserve a space for a smaller/shorter interval.

hannah_headshot

Interview #2: Hannah

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

Hannah uses Pass2Parkit frequently, as a guest, and wishes she could check herself out when she's done parking.

How many times have you used/how often do you use PasstoParkit?
I use it about twice a week.
Describe your experience with the app.
It's inconvenient, frustrating, and not user-friendly. The app isn't easy to navigate or intuitive, and it doesn't take into account the reality of guest parking (which is that you may have more than two guests over in a 24-hour period). There's no way to check out your car when you leave. It's hard to use and overall frustrating.
Highlight, for me, your biggest issues using the app.
You can't check people in and out. It's not easy to use and it's not intuitive, and it's ugly.
What about the app do you like?
I don't like anything about the app.
Is there any feature the app doesn't have, that you'd like it to have?
An ability to check guests in and out of the app, and perhaps a automated hotline that residents can text to register vehicles.

zimmer_headshot

Interview #3: Jacob

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

Jacob uses Pass2Parkit frequently, as a resident, and wishes he didn't have to enter login credentials every time he used the app.

How many times have you used/how often do you use PasstoParkit?
I have used the app many times. Roughly 1-3 times per week.
Describe your experience with the app.
Overall, not good.
Highlight, for me, your biggest issues using the app.
I have to log in from scratch every time - it doesn’t save my phone number or apartment for quicker registrations. Similarly, the app has no in-app way to save the information of cars that I check in - if a friend visits often, I still have to enter their information in completely from scratch every time. 
What about the app do you like?
Nothing particularly.
Is there any feature the app doesn't have, that you'd like it to have?
(1) A way to save my apartment/phone as the default so I don’t have to type it in every time. (2) a way to save registration info for cars of frequent visitors. (3) a way to check what cars are registered currently and when they expire, and delete unneeded registrations.

04     -     User Research - Apartment Survey

Personas & Scenarios

Identifying the “types” of users that we were designing an app specifically for was key in understanding how to frame our solution. For example, we went into this step with a broad understanding of who we’d be designing for - “college students” - but needed further understanding about the subgroups of users that fall under this umbrella term. How would their needs vary by age? What about organizational interests?

Identifying the users that we were designing the app for was key in understanding how to frame our solution.

After long and thoughtful discussion about who exactly we’d be designing for, we created user personas based on these prospective users. For each persona, we defined needs, goals, and pain points. Based on these factors, we went even further and developed scenarios for each persona. These scenarios are example use cases, each of which addresses specific aspects of the persona’s personality and aspirations. Below are the personas and scenarios we created.

After receiving valuable feedback from these interviews, I had a solid, research-backed understanding of the problems users faced when using Pass2Parkit. However, with a sample size of three (four if you include me) I still couldn't be completely sure that these sentiments and experiences would appear in a group of more users at scale. This is important, considering the degree of demographic overlap between the interviewees (for example, all users interviewed were between ages 20-25 and are frequent phone users, and all have college degrees in a technical field). So, as the next step in the research process, I surveyed the residents of my apartment, seeking a more diverse group of respondents.
Click here to see the survey.

Personas & Scenarios

Identifying the “types” of users that we were designing an app specifically for was key in understanding how to frame our solution. For example, we went into this step with a broad understanding of who we’d be designing for - “college students” - but needed further understanding about the subgroups of users that fall under this umbrella term. How would their needs vary by age? What about organizational interests?

Identifying the users that we were designing the app for was key in understanding how to frame our solution.

After long and thoughtful discussion about who exactly we’d be designing for, we created user personas based on these prospective users. For each persona, we defined needs, goals, and pain points. Based on these factors, we went even further and developed scenarios for each persona. These scenarios are example use cases, each of which addresses specific aspects of the persona’s personality and aspirations. Below are the personas and scenarios we created.

surveypost

Posting about my survey in our community portal was met with positive feedback from residents.

Survey Results

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

I asked respondents the same questions I asked my interview subjects - what they liked about PasstoParkit, what they didn't like, and what they felt was missing. Additionally, I asked respondents to list out, in order, the changes they felt were most necessary to the app. By assessing these ranked lists, I sought to again pick up on patterns among respondents, and be able to prioritize changes and new features in the redesigned app. I received 11 responses to my survey. Overall, the frustrations identified in earlier stages of my research (user reviews and the interviews) were echoed here. On a scale of 1-5, users rated their satisfaction with the app at an average of 1.72. This low score was consistent with that of the score in the App Store and reflected the dissatifaction expressed by the users I interviewed. From the answers in the survey, patterns emerged - patterns that indicated the app features and bug fixes users wanted the most. The following are the top requests from the users.

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

surveydata

The survey results show that residents are overwhelmingly dissatisfied with Pass2Parkit.

Need #1: 

Users want to choose when to end a registration.

Need #2: 

Users want a new, easier authentication system.

Need #3: 

Users want a dashboard to see all registered vehicles.

These three features (flexible registration timing, easier authentication, and a centralized means through which to check currently-registered vehicles) were consistently noted to be of highest importance to Pass2Parkit's current users, and it would be these issues that I'd have my mind on as I transitioned into brainstorming . With these key features in mind, I had the research and data I needed to make informed choices as I began work on the new app's design. 

QOC & Wireframes

For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.

By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.

Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.

05     -     Brainstorming + Sketching

Using the research gathered in the prior steps, I began brainstorming what this new guest parking management app would look like. This part was a bit messy, but from the mess an architecture from which to begin building the app emerged. Here are some scans from my brainstorming session. When brainstorming, I like to just let my thoughts and ideas fly, without worrying about organization or structure. That should be apparent in the above scans of my notes. As you can see toward the latter half of the scans, the jumbled thoughts and ideas I had in the beginning formed into a high-level user flow, which I built out as the next part of this process.

Paper Prototyping

The development of the Paper Prototype was the means through which we took the rough wireframes and functionality ideas that we created with the QOC evaluation and came out with a paper prototype that effectively captured the big-picture interactions that we’d be implementing in our digital prototype. At this stage in the design process, we had some ideas defined.

Brainstorming-01
Brainstorming-05
Brainstorming-02
Brainstorming-06
Brainstorming-03
Brainstorming-07
Brainstorming-04
Brainstorming-08
Brainstorming-09
Brainstorming-10

06     -     Design Decisions: Round 1

Brainstorming helped me get my initial ideas about the problem out of my mind and onto paper, where I could think about them with greater scrutiny. This process also raised some key questions about fundamental aspects of the new app's design. Faced with these questions, I had to make design decisions - here are some of the key decisions I made following my brainstorming session.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Should residents and guests share an app?

In its current state, Pass2Parkit has one app that both residents and guests use to register guest vehicles. I questioned whether this was beneficial, or whether these two distinct user groups with different permissions would be better suited with different apps (think Uber Rider v. Driver).

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Shared App

Pros: Sharing an app would provide an almost identical experience for residents and guests. This would be good in a scenario where a resident at one building were to travel and become a guest at another (a hybrid user).

Cons: There are some key differences in the permissions granted to residents and guests. These differences would be easiest to reconcile with two distinct applications. Residents and Guest have distinct goals - it may pay off to provide each group with an app tailored toward helping them reach these goals.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Different Apps

Pros: Having two separate apps may make it easier to distinguish the resident and guest experiences. If a guest's primary need is to add their vehicle to the system, a standalone guest app that serves only this purpose would allow for the quickest and most intuitive experience for new guests.

Cons: The two-app system would become problematic in the scenario where a resident were to travel and become a guest elsewhere - this would require them to have both apps. This seems unnecessary.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: Shared App

I decided to maintain the shared app experience that's currently offered in Pass2Parkit. Having a shared app is one of the things that users responded positively to in my research, and I suspect that whatever experiential benefits would be gained by separating the resident and guest experiences would be overshadowed by the ensuing confusion about having two apps to accomplish essentially the same thing. Also, the scenario I mentioned about a resident becoming a guest elsewhere is a legitimate concern, and at scale would certainly become an issue.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

How should ParkPass authenticate guests?

In my research, users indicated their strong dislike of the current authentication mechanism for registering vehicles. As it stands, the current system requires the user (residents and guests alike) to enter the phone number and unit number of the resident to authenticate the registration. Respondents indicated that they disliked having to go into their contacts, look up the resident's phone number, and enter it into the app all before beginning to register a vehicle. Respondents said that remembering a phone number was difficult, meaning they had to go through this phone number lookup process every time they register a vehicle. Seeing this problem, I explored other options for authentication.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Two-Factor

Pros: This would be the most secure way to authenticate vehicle registrations. If the resident had to manually authenticate all new vehicles by clicking on a 2FA notification, there may not be a need for any other mechanism.

Cons: Two-factor auth requires a degree of coordination between residents and guests. In a scenario in which the resident is away from their phone, registrations wouldn't be able to go through to completion. 

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

PIN Code

Pros: The PIN Code would be much easier to remember than a phone number - hopefully to the extent that guests are able to remember it without having to look it up. This would be easier for the resident to remember and recall, as well.

Cons: This is likely the least secure authentication method - PINs, especially shorter ones, can be more easily compromised than, say, a more secure 8-digit password.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Password

Pros: This option would be the most secure option outside of 2FA - and the resident could set the password to be something memorable, so perhaps it may be easier for incoming guests to remember it.

Cons: Having a password doesn't address the primary concern about authentication raised by users in my research - remembering a long string of numbers. Even a relatively memorable password, I worry, would still lead to the same issues.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: 4-Digit PIN Code

I chose to go with a 4-Digit PIN Code - I suspected that this would be the easiest for residents and guests to remember. While the other two authentication mechanisms are more secure, I would argue that given the worst risk of compromise here is someone registering a car to a resident's spot (which can be undone and deleted by the resident), the usability benefits outweigh the security drawbacks in this case.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Who should have access to live parking info?

Another issue raised by my research - which I had an opportunity to address in this redesign - was who would be able to view the vehicles currently registered for a resident. Currently, guests AND residents are unable to view all currently-registered vehicles, meaning both parties have no way of knowing which cars are registered and how many available parking spots are left. So herein lies a choice - should everyone be able to view this information, or just the resident?

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Everyone

Pros: If everyone can see this information, guests will have a much easier time planning their visit and knowing in advance whether there's available parking spaces, without having to ask the resident and wait on a response. If, for example, a guest registered their vehicle the day before - they can check to see if their registration is still valid.

Cons: I can imagine scenarios in which residents may not want guests (or anyone with the PIN) being able to know who's visiting them at a given time - though I question how big of a security concern this really is.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Residents Only

Pros: This is certainly the most secure option. If there are reasons for which residents would want to keep this information about which vehicles are currently registered from other guests, this would mitigate that concern.

Cons: At the same time, this would remove a lot of utility for guests, stripping them of the benefits gained from being able to have full visibility in the parking situation for a resident.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: Everyone

I decided to allow everyone visibility into the parking system. I went with this decision primarily because of how strongly both residents and guests indicated they wanted this functionality in my survey. I can understand the questions about privacy and security, but if privacy about this information is that big of a concern, residents will always be able to change their PIN, effectively barring unwanted eyes from the system. Conflict with evil exes avoided... I think? 

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

07     -     User Flow Diagrams

In the previous step, I brainstormed how this app should work at a high level, and made key design decisions - identifying the fundamental needs of the users and weighing my options for how to accommodate these needs in a user flow. In the Wireframe, I thought intentionally about each step the user would take to accomplish their key tasks, how these steps would interconnect, and how to help guide users toward their goals in a quick and intuitive way. Below is the finished product. 

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

ParkPass Flow 2
ParkPass Flow 1

08     -     Wireframe

Conclusion

I can't overstate the importance of this step - effectively creating a user interface from a collection of user flows is no easy task, and one that must be done with care - especially when considering the insights gathered from my user research. If I were to rush this part, all that I'd have done up to this point would have essentially been for naught. If we're not accommodating the demonstrated needs of users when redesigning an app, then what are we really doing? This is all to say that, as I built this wireframe, I made sure to carefully consider the feedback and requests gathered from users during my research - while leveraging the user flows I created as the blueprint. Here is the resulting wireframe.

ParkPassWireframe1
ParkPassWireframe4
ParkPassWireframe2
ParkPassWireframe3

09     -     Design Decisions: Round 2

Building the wireframe allowed me to really start putting all of my research and initial designs to work, and it gave me a fantastic foundation on which I could build a usable prototype. This step also forced me to make some choices. Faced with these choices, I had to make decisions - here are some of the key decisions I made while constructing the wireframe.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

First-Time User Flow - Should residents and guests get the same experience?

We've already established that the resident and guest experiences in ParkPass are going to be different. But I hadn't yet determined exactly how different. This really came to light when designing the first-time user flow. I found myself asking, should residents and guests both go through the same onboarding experience, or should their first-time experiences be different?

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Shared First-Time Experience

Pros: Sharing the first-time/onboarding experience would ensure that all users of the app are getting the same information when being introduced to the app, and ideally understand its utility and capabilities in the same way. This would also be good for resident/guest hybrid users - meaning that the experience would be consistent whether they were a resident at their apartment or a guest at someone else's.

Cons: I can see the lack of differentiation between resident and guest experiences being confusing for users, especially at the beginning of their ParkPass experience. There shouldn't be any questions about their role as a user and how they can accomplish their goals in the app, and I worry that combining this first-time experience would cause confusion about the roles of residents and guests.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Separate First-Time Experiences

Pros: Separating the first-time experiences would make it very clear to the user what their role is. This clarity would help users understand that, "as I guest, I can do this, this, and this..." and "as a resident, I can do this, this, and this". Residents and guests are distinct user groups with distinct permissions and goals, and reinforcing this notion would provide a clearer
introductory experience.

Cons: There may be a good amount of overlap between these two first-time flows, as they would be likely to cover (mostly) the same information. Also, for our hybrid (resident/guest) users, there is a strong potential for confusion if sometimes they're the resident and sometimes they're the guest.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: Separate First-Time Experiences

I decided to separate these two first-time user flows. While the hybrid user scenario is a legitimate one, the majority of users of ParkPass would fall into one of the two user groups, not both. I see value in reinforcing the user's role as either a resident or a guest when they go through the first-time user flow. Separating these two experiences also opens the door to fast-tracking the first-time flow for guests, asking as little of them as possible so that they can accomplish their goals quicker.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Adding a new vehicle - text fields or wizard?

When registering a new vehicle, multiple pieces of information are required - the vehicle make, model, year, color, and license plate number. When beginning to wireframe this part of the app, I had to decide whether to direct the user to a list of text entry fields (as does the current solution) or create an "Add Vehicle" wizard that quickly walks users through the add vehicle process.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Text Fields

Pros: Having all of the text fields in front of the user will give them an idea of what information about a vehicle they may need to have ready/on hand if they don't already have it. Having the information laid out this way (in a list of labeled text entry fields) also allows the user to review the information for their new vehicle registration at a glance.

Cons: This can seem like a inefficient experience - having to click between different text entry fields. For similar experiences across other apps, wizards have become more widely adopted. This text field experience can feel old and busy, and having to click into different text entry boxes can be difficult for some users.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Wizard

Pros: This would likely be the most intuitive experience for the user. Wizards make knowing what information is needed at a given moment very clear, and reward users with a feeling of accomplishment. They also reduce confusion users may have about the process.

Cons: It would be difficult to design a wizard that allows you to go back and review the information you've already entered quickly, without having to click back through the entire wizard. I also worry that, for users who regularly register vehicles, the wizard would be repetitive. These high touch hand-holding experiences are good for new users, but power users would likely get frustrated having to click through the same group of wizard pages every time they register a new vehicle.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: Text Fields

I went with the list of text entry fields this time around. Users didn't indicate that the text entry interactions were problematic in my research, and I do see there being a strong benefit to being able to go back and check what you've already typed for a registration without having to click back through multiple pages of a wizard. I see the list of text entry fields as the quickest, least invasive option.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

4-Digit PIN Controls - prominent feature or hidden in settings?

The PIN Controls for the resident don't have any precedent in the Pass2Parkit app, so I had no current state on which to assess this decision. I knew that I wanted residents to have full control over their 4-Digit PIN Code, but I was faced with deciding whether to make this a featured functionality within the app or store this 4-Digit PIN Control deep into the settings.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Prominent Feature, Easy Access

Pros: Having easy access to the PIN Controls would make it easy for both residents and guests to, at a glance, have the 4-Digit PIN needed to register a vehicle. Given that my research demonstrated such a strong desire for an easier (more memorable) authentication mechanism, this seemed like a huge draw.

Cons: For users who wouldn't want to change their 4-Digit PIN often (or at all), featuring this functionality so prominently may seem unnecessary to them (if it's a feature they seldom plan on using) and clutter their experience.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Secondary Feature, In Settings

Pros: Hiding away the 4-Digit PIN controls would declutter the interface for the users that don't plan on utilizing the functionality. This could allow them to focus more on the goals they initially had set out to achieve.

Cons: This would make it harder for residents and guests to quickly recall and access the PIN should a guest need it. It would add potentially unnecessary steps to a process that users have already indicated they have frustrations with.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

Decision: Prominent Feature, Easy Access

The clear choice here was to enable easy access to the 4-Digit PIN controls - this decision was informed by how strongly users felt about their issues with access and authorization in the Pass2Parkit app. Providing easy access to these controls could help expedite registration processes for users, another pain point brought up during research.

Digital Prototyping

The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.

The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.

The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.

10     -     High Fidelity Prototype

Conclusion

With the wireframe squared away, design decisions made, and the demonstrated needs of users considered, it was time for the fun part. I'd laid out the structural elements of the new app, and it was time to make everything look good. I made sure I used the flows and page structures from wireframe as the foundation for the high-fidelity prototype - preserving as many blocks, containers, and elements as possible. If you compare the high fidelity screens to the ones in the above wireframe, you'll notice the high degree of overlap and consistency between the two interfaces. Beyond the structure, I had an idea of what I wanted visually - slick, clean, modern - but did a lot of experimenting with elements like color, fonts, shading, and much more... ultimately landing with the following screens.

Prototype_Xd

11     -     Interactions + User Flow Testing

Conclusion

I had laid out the hi-fi screens for the new prototype, and went a step further to build out the flows and interactions in Adobe Xd. In doing so, I was able to ensure that the prototype I had created functioned as I intended. In going through and testing out the flows, interfaces, and buttons in the prototype, I was able to identify some navigational weak points and made changes accordingly. Plus, getting to show you all these animations is really cool.

ParkPassFirstTime
ParkPassGuestHi
ParkPassAccess2Hi
ParkPassNotifs2Hi
ParkPassNewCarHi
ParkPassEdit2Hi

12     -    Needs Assessment and Follow-Up

Conclusion

I finally had my completed high-fidelity prototype. The flows were done, the interface was done - it was ready for Behance. However, before calling it a day, it's important to make sure that your creation actually accomplished that which you'd set out to accomplish initially. A lot can change over the course of a project build - this is especially true in the large-scale enterprise environments in which I'm used to working. Back in the Research portion of this project, I had identified three key features and fixes that users of Pass2Parkit wanted to have. Overwhelmingly, feedback from my interviews and user surveys indicated that users of the app wanted the following: the ability to check a car out when a guest leaves, a new authentication mechanism that doesn't require a phone number, and a dashboard to see all currently-registered vehicles for a unit. Let's review how ParkPass addressed each of these demonstrated needs.

Need #1:
Users wanted to choose when to end a registration.

Users were almost universally frustrated that once a vehicle was registered to park in one of their spaces, that vehicle was "locked" into that space for the next 24 hours. This is wildly inconvenient for a user that has, for example, one guest over in the morning, and then two more guests (all with vehicles) over in the afternoon. Without a way to end registrations, the space that the morning guest's car is taking up would remain filled throughout the day, preventing one of our afternoon guests from being registered (we have a two vehicle maximum on guest vehicles at a time). With the design of ParkPass, I remedied this issue by simply adding an "End Registration" button. This simple fix was an easy one to improve the experience of so many users.

ParkPassMockupHD1
ParkPassMockupHD2

Need #2:
Users wanted a new, easier authentication system.

Pass2Parkit is unique in that the one app faciliates this functionality for both residents and users - this was something I wanted to make sure I held onto as I was developing ParkPass. Many users indicated that the login and authentication mechanisms in Pass2Parkit were troublesome. In order to register a guest vehicle, a user needs the phone number and room number of the resident that they're visiting. The phone number, in particular, was the source of the most difficulty - it's simply hard to remember a phone number, especially if you're a frequent user of the app and need to use it often, this can be annoying. That's why I opted for using a PIN-based authentication system instead of a phone-number based one. A 4-Digit PIN is much easier to type or remember than a whole phone number - plus, I gave the resident the ability to change their PIN, should they want to limit parking permissions for any reason.

Need #3:
Users wanted a dashboard to see all registered vehicles.

Despite the fact that the need for this feature should be obvious, in the Pass2Parkit app there is currently no central place to go to view all of the vehicles currently registered to a residence. This is problematic for both Residents and Guests - neither is able to quickly open the app and see if there is an open spot to give to a guest. Beyond this, there isn't any continuity for residences across experiences. Meaning, if a Guest registers their vehicle on Pass2Parkit, this registration is NOT reflected in the Resident's app experience at all. This is a huge problem! Centralizing these disparate experiences was fundamental in ensuring continuity across users - and letting everyone know how many guest spots are taken and available.

ParkPassMockupHD3

14     -    Final Thoughts

Conclusion

It was great getting to redesign an app I use so often, and I'm confident that the final product of this case study goes above and beyond satisfying the needs demonstrated in my research. This was a great exercise in User Research and Experience Design, and it gave me an outlet through which to practice and improve upon my design skills while #WorkingFromHome. However, this project isn't completely done. I will be reaching out to Pass2Parkit and its developers, Think3Logix LLC, to see what they think of my design critique. I can't think of a better outcome for this case study than actually being able to influence positive design changes for this app I use almost every day. I'll be updating this page if anything happens with them - right now hoping for the best. Thanks for taking to time to read this, I hope you enjoyed it and were able to get a better perspective on my design process!

I'M CURRENTLY...

I'm currently a Design Fellow at Coho focused on leadership and product-building in the role of a First Designer. Recently, I supported Product Design, Product Management, and User Research at CloseFactor as their First Designer / Design Lead.


Currently working at Oracle in Austin, Texas as a Cloud Engineer. I use my background in UX and Product Design to help companies implement innovative technical solutions while demonstrating the power of cloud-based applications. 


Currently supporting Product Design, Product Management, and User Research at CloseFactor, building the world’s first go-to-market operating system.

I'M LOOKING FOR...

WHAT'S ON YOUR MIND?

I'm looking for my next full-time role. It most likely looks like...
a Founding, First, or Lead Product Designer role at an early-stage startup or  a Senior+ Product Designer role at a growth-stage startup or public company
I'm also available to work on a fractional basis.


You're here for a reason - if you're just looking around my portfolio, enjoy. If you're interested in working with me, feel free to reach out to me via email or Linkedin - I would be more than happy to talk about my experience with you. I'm always open to hearing about current and future opportunities.


You're (probably) here for a reason - if you're just looking around my portfolio, enjoy. If you're interested in working together, feel free to reach out to me on Linkedin or via Email - I'd be more than happy to talk with you.

CONTACT ME

CONTACT ME

All rights reserved. Handmade by John Falcone in 📍 Austin, Texas. © 2023

All rights reserved by John Falcone. © 2020

All rights reserved.
Handmade by John Falcone in Austin, Texas. © 2023