Crafting the Ridejoy Mobile App

Jason Shen -

GUEST POST: Suelyn Yu is an interaction designer at frog (see her portfolio) and worked closely with the team at Ridejoy to help craft our iPhone application. I feel very lucky to have worked with such a kick ass designer and I think this case study should prove useful for any startup that’s looking to build a mobile app. Now, on to Suelyn!)
– Jason

Background

Do you remember the last time you were traveling on the highway? I do. There are usually countless cars all around me, and yet most of them are full of empty seats. I often wonder to myself, “Why isn’t there a way for people headed in the same direction to travel together?” One company, Ridejoy, aims to solve this problem by helping people share rides anywhere, anytime.

As an interaction designer at Frog, I’ve designed to encourage people toward pro-social, offline actions. When Ridejoy was preparing to build an iPhone app, Kalvin, one of the co-founders, reached out to me for help. I worked with the Ridejoy co-founders; Christine Yen, who built the app; and Seth Warrick, who created the brand and visual design.

It just launched in the US App Store.

iPhone Design Problems

After running Ridejoy.com for several months, the team learned a great deal about their current user base. In developing an iPhone app, we wanted to do far more than just “port” the site over to mobile – but instead, craft a new experience.

We identified 3 key challenges:

  • How we get drivers and passengers to post more rides?
  • How do we speed up the process of making driver and passenger matches?
  • How should Ridejoy facilitate “arrangements” between drivers and passengers?

Challenge 1: Encouraging Posting

For a rideshare service to be successful, it needs to be able to draw from a large pool of rides when matching up passengers and drivers. We know that many people are driving by themselves or are looking for an affordable ride, but if they don’t post their travel plans on Ridejoy, there is no way for these people to get matched up.

The hard part of asking people to post their rides convincing them it is a worthwhile effort. We need to effectively communicate the value and the process of ridesharing.

The team started by listing all the reasons drivers would want to rideshare. Based on the list, I sketched what we could show drivers before they posted. I made wireframes of our favorite 5 concepts, and showed them to potential drivers. We learned that drivers were motivated by (1) passenger photos, (2) large numbers of potential passengers, and (3) the money they could earn.

Early concepts on how to get a driver to post.

These insights lead to the design of our “Popular Destinations” flow. In the app, you can browse Ridejoy’s most active cities and profiles of drivers and passengers going there. I imagine users flipping through these screens when they don’t have a trip in mind, or before they are comfortable with ridesharing.

Challenge 2: Speeding Up Matches

People don’t like waiting. Ridejoy looked for ways to reduce the time it took to find a match. From the website, we know that the more detailed a post is, the less back and forth coordination. The trouble is, people don’t want to spend time writing a detailed post.

To unpack this conundrum, we started by listing all the details a driver or passenger would want to communicate. After much debate, we whittled it down to 4 required inputs. There are also optional inputs and ways to indicate how flexible or fixed your plans are. For example, you’re required to input a departure date. This can be a range of dates like a weekend, or one specific day. If you when you are leaving, you can also add the time as a range or specific time.

Wireframes of inputting ride details, departure date, and departure time.

However, browsing ride posts isn’t like browsing a list of flights. In addition to the matching when and where, you also need to be comfortable riding in the car with the person. To address that, we require your profile suggest filling in perks and preferences to post. Do you want a chatty or quiet ride? Do you have a AAA membership or wifi tethering? Adding these specific details sets up efficient conversation because you’ve already answered the most common questions people might have.

Challenge 3: Facilitating Arrangements

Rideshare has traditionally been an informal and sometimes tedious back and forth between two individuals. When Jason found a ride to Oregon, he exchanged 20+ text messages with his driver. Ridejoy, as a trusted third-party, needs to naturally broker this exchange to build accountability into the system.

Asking and answering questions will always be necessary in coordinating a ride. The hard part understanding when you are both “good for the ride.” The last thing you want is someone flaking out after a long conversation. We wanted to design a simple way to confirm a ride.

For inspiration, I looked at how other collaborative consumption apps, such as Airbnb and Yardsale, designed offer systems. After trying multiple layouts and flows, we landed on a light confirmation sequence built on a familiar messaging interface. Either drivers or passengers can initiate the confirmation. Once the passenger has paid and the other person accepted, the ride is confirmed!

Diagram explaining how drivers and passengers move through the system over time.

The process of messaging and confirming rides can happen among multiple people, and across multiple rides. You might be driving one passenger down to LA, and two different passengers coming back.

This lead us to the dashboard– a place to view all your rides, alerts, and a trip itinerary of confirmed people.

Wireframes of the evolution of the dashboard

Lessons Learned

I’ll end with some lessons I’ve learned from designing this app:

  • Prototype. Test. Prototype. Test. Our team spent hours debating user needs and hypothetical solutions. Testing a quick prototype, whether it is click-through wireframes or a quick build, with real users (who are not part of the team) helped us make decisions faster.
  • Play out the interaction models. We tried out a few navigation models. Tabs? Side-bar? Dashboard? We sketched out each model, pinned them up, and discussed which one was the best for the Ridejoy experience. We had to play out the scenarios fully to truly understand how they would work.
  • You just gotta ship. As a designer who wants to perfect the details, I had a hard time with this. I don’t know if people are going to understand how to autopilot their offers. I think we can improve our “no upcoming rides” screen. The feeling of wanting to fix “one more thing” will always be there so recognizing that and shipping anyway is an important thing to do.

Overall, I think we were pretty successful in addressing the 3 key challenges, but ultimately it will be up to our users to determine if that is truly the case. I’d love to hear any feedback on this design process or the app itself. You can reach me at: suelyn.yu@gmail.com