I started desiging this app because I wanted to grow as a designer, so I decided to design a mobile app to solve a problem that many of my friends had come across in their lives.

Many of my friends were attending universities that were not in their hometown and needed ways to to back and forth between school and home since they did not have their own car. For many students, their solution to this problem was to rely on student-run Facebook groups. However, these groups always seemed more like a temporary solution as they were unstructured, uncoordinated and had no search function. Plus, due to the lack of vetting, there are regularly posts about misconduct, such as no-shows, rude behavior and leaving without paying.

For these reasons I decided to try and design a rideshare app that would be a much more professional and permanent solution to this problem.

Shotty is an iOS app that connects drivers and riders in their area based on user set search criteria. Shotty also offers a two-way rating system much like Uber to ensure the safety of the service for both riders and drivers. The focus of the app is on postsecondary students, but it by no means is limited.

Role: Sole Product Designer

Responsibilities: User Research, Interaction Design, Prototyping, Visual Design

Tools: Figma

Timeline: October 2019 - February 2020

In order to gain more insight and details about student transportation experiences, I created a survey and sent it out to my friends and family as well as a Facebook rideshare group. In total, I received 82 responses.

These responses were separated into three categories: riders, drivers, other.​​​​​​​

Other in the context of the survey meant anything from people who take public transit or get driven by family or friends. Even though I did not explicity design the app to convince people to use ridesharing apps, the information still provided very useful information about people's perspective on ridesharing apps.

The responses from the survey helped me create user personas that aided me in designing the app for a targeted audience.

Below is a table summarizing general complaints and observations from the research and potential in-app solutions.

     - Vetted drivers

     - Good customer service

     - Not enough users to be reliable

     - Slow handling of payments for drivers

     - UI is a bit confusing

     - Automatically shares driver's phone number upon ride match

     - Can assess someone based on their Facebook profile

     - Generally active

     - No proper search function 

     - Unorganized posts make it difficult to find relevant information

     - Hard to enforce code of conduct

     - Posts are not structured and often lack details

     - Possibility of missed matches due to Facebook's message request system

After contemplating several ideas for a name, I chose the name Shotty!, slang for who gets to sit in the front passenger seat of a vehicle. To ensure consistency, I created a logo and a rudimentary design system.

I used the script front Arkipelago because I believe it captured the more laid-back and casual essence of calling "shotty!" when riding in a car with your friends.

I chose a green color to be the main colour as I felt it related nicely to green traffic lights and the idea of catching a green light while driving. Besides the other grayscale colours used, the app keeps the use of colours to a minimum in order to maintain a clean appearance.

At first, I created a user flow to split the app between drivers and riders, but soon realized that this would not be needed as the screen could change depending on role. The driver would be using the app as a driver and the rider as a rider.

Research I conducted into marketplace businesses indicated that the app would need to concentrate on either the supply or demand. For this design I chose to concentrate on the riders, with the idea that rider demand would eventually drive up driver supply (no pun intended).

For ease of use, the home screen contains the search function. The "find passengers" option was also removed since it was a redundant feature. The rides screen shows past and upcoming rides while the inbox only shows conversations. The setting screen was merged into the profile screen to reduce clutter in the bottom navbar. And lastly, to increase visibility, the notification screen was connected to all top-level screens.

Throughout the design process, I asked friends to provide feedback on the prototypes I had created. This allowed me to validate changes I had made and iterate on the design.

What ended up being the most useful was having a friend screenshare so I could observe their actions as they tried to navigate through the app. As they explored the app, I took notes on areas that seemed to cause confusion based on their actions or their explicit feedback.

In the future, I believe it would be best to standardize my testing between users, but simply observing their actions was also extremely valuable.

My way to solving the issue of riders needing to trust drivers and vice versa was to implement both a rating and endorsement system. The reasoning for this is the fact that unlike Uber, riders and drivers use the same app, so it would not make sense to have a single rating system for two different kinds of users. Ratings would be given to drivers by riders and riders would receive endorsements from drivers.

Below is the user flow in which a user would leave rating for a driver. To prevent spam, driver reviews may only be completed after a ride is complete and may be anonymous.

Although rider endorsements are not part of the prototype, the idea behind them is as follows:

After a ride has been completed, a driver can give the rider a thumbs up or thumbs down and optional comments. These of course can be anonymous.

My goal with these review systems was to provide information to both drivers and riders that would help them make decisions about who they accept a ride with. Any users with too many low ratings or valid reports may be removed from the app to protect the community.

The driver vetting system would require some level of verification. The design includes a rather generic placeholder verification system as requirements would vary depending on the location.

There is no rider vetting as it would create a barrier to entry that may dissuade many potential riders, but that does not mean that driver safety is not important. This is similar to how current cab companies operate. The cab driver is vetted, but the rider is not. However, if the rider were to have continuously behave poorly, they may be banned from the service. The same approach applies to Shotty.

In terms of the interactions between drivers and riders, the interaction that the app was modeled on is the Facbook rideshare group interaction, but in a more concise and streamlined manner. 

This is what the initial flow for matching riders with drivers looks like:

Steps 5 and 6 are crucial because riders often send out more than one request to ensure that they are able to get a ride. Afterwards, these riders may recieve several offers from drivers, but will only need to choose one. To manage this scenario, the rider gets the final say. This is why steps 5 and 6 were added to the flow. However this this flow has a significant amount of added back-and-forth between rider and driver, which may dissuade some from using the app.

The other option is to simply provide the driver with the final say. Once a driver offers a ride, a match is made and all the rider's other overlapping requests and offers are cancelled. This means that the flow would stop at step 4.

For this design, I opted to let the driver have the final say to minimize the back-and-forth between rider and driver.

This is what the user flow ends up looking like:

This method also incentizes drivers to respond to ride requests in a timely manner or they risk losing potential riders.

Another aspect of the app that needed careful tuning was privacy. In the context of this app, that meant not requiring or publicly displaying any non-essential information. This resulted in the decision that driver information is hidden until a ride match is made.

This decision was made because research indicated that riders very rarely factor car models into account when looking for a ride.

Another area where information may be hidden is driver reviews as riders have the option to remain anonymous. Phone numbers are also not required.

I chose to not include an in-app payment method as research showed that many drivers were frustrated about the app's slow transfer of payments. Since payments should occur no later than at ride's conclusion, I wanted to avoid delays in payment by leaving payment up to the users.

Another reason for not including an in-app payment system is the fact that people may be hesitant to enter their payment information into an app due to the possibility of data leaks. However, the lack of in-app payments does open the possibilty for conflicting reports as to whether a driver was paid or not. This aspect is worth revisiting when monetization comes into question.

All in all, I feel like desiging this app to tackle a problem my friends were having in real life helped me learn a great deal of things about UI/UX and product design. Beyond the UI design practice and improved technical skills, I feel like I have a much deeper understanding of the design process and the shortcomings of the approach I took and the methods I used.

Document my processes to make case study writing easier

Save old versions for reference and to show growth and change in project

Standardize testing for more insightful results and information

Thanks a bunch much for reading!