Research

Our objective was to learn about our user’s transportation habits and what they thought about their carsharing or car rental experience, if applicable.

Domain Research

We first delved into the domain of carsharing in order to understand the industry’s climate and its competitors.

Competitors: Zipcar, Turo, Car2Go, Getaround, Enterprise Carshare, City Carshare, Enterprise Car Rental

We decided to also compared these companies to car rental companies and to ridesharing since these services fill the same user need and are the most used alternative to carsharing.

Insight: a lack of rewards program

What was interesting to us was the lack of rewards or points program to promote customer loyalty. We filed that interesting fact away for future reference, but we knew there was an opportunity to incorporate this feature that was missing from all other carsharing services.

User interviews

We’ve interviewed several people we know and several we don’t who’s had experience using carsharing services. Our interview results showed that users who used carsharing enjoyed the experience, however some pain-points with the service deterred them from utilizing the service more often.

A surprising insight we got from the interviews was that carsharing did not fit into user’s current habits of getting around. Between walking and using public transit, ridesharing or commuting in their own car, there was no real need to carshare. Those who said they used carsharing only used it once a month.

Based on the survey we sent out, respondents also stated that they were satisfied with their current mode of getting around. Over half of them did not know what carsharing is.

Now that we know about the domain and how the users feel about carsharing, the question now becomes: what are the problems we can solve with the app?

Define

After our interviews, we synthesized our testing by mapping our findings.

We found through our research that:

• Carsharing was not widely adapted into people’s lives
• Half of the people who used carsharing owned a car
• Current carsharing users are deterred from frequent use of the service because:

1. There weren’t enough locations nearby
2. the prices were too high, hidden charges
3. Vehicles often unavailable for last minute reservations

From there, we created a persona that embodied these user goals so that we can better empathize and focus our project scope with the user in mind.

Peter:
The occasional user
Need cars to be available for emergency
Owns a car

We knew that based on the pain-points we found that we were only able to solve design and not business problems. A major finding from our research points out that about half of those we had surveyed and interviewed did not know what carsharing is, which was a problem we knew we could not solve since it involved marketing, educating the customer, and adaptation of car sharing into their travel routine. We realized that convenience and ease of use was something we did have control over with our app, and we focused on that going forward.

Keeping in mind the goals of Peter, we went forward with these design principles that, if incorporated into our designs, would solve the pain-points that users voiced in our interviews.

Design principles

Flexibility

Users will be able to easily make and change reservations from their device of choice.

Empowerment 

Enable freedom of choice by introducing and clearly presenting meaningful, relevant options so that users feel confident, in control and inspired to explore their city.

Transparency

All cost and fees will be upfront to evoke a feeling of trust in the user.

Mobile-first 

All options and features will be optimized for mobile platforms and easily accessible, even when on-the-go

To narrow our focus, we crafted a problem statement that would be the compass to our project. It would include the essence of our design principles and user goals. We first thought our goal is to incentivise our users to use carsharing more often, with more of a business orientated angle:

How might we build a more empowering, versatile and habit-forming carsharing platform that incentivizes our customers to incorporate car-sharing more frequently and habitually into their travel routines?

This was a good start, but we wanted to be more user-centric for our project scope. We asked ourselves the question: What does the user want? How are we solving the user’s pain-points in a way that was different from the other competitors in the market? By asking those hard questions, we changed our statement so we were viewing the scope of the problem from a user’s perspective.

"How can we put users in greater control of carsharing reservations and costs, so that they will incorporate it more frequently and regularly into their travel routine?"

Diverge

To jump-start our process and get the creative juices flowing, we did a few rounds of Round Robin where we came up with many rough sketches of ideas in a short amount of time. We then used silent dot voting to see which ideas were the most favorable among our team. We did this in order to come up with different concepts we might use moving forward into paper prototyping.

One of the strongest concepts from Round Robin is the reward feature:

It was during this exercise that one of our teammate came up with the idea of a reward system where the user earns points or accumulate unused minutes in which they can redeem when making a reservation. The idea first stemmed in her head from the competitive analysis, where we found that there was a lack of rewards system among carsharing companies. This rewards system was greatly appreciated by everyone on the team and became the most voted concept. We decided to concept test this in our paper prototypes.

I was surprised at the effectiveness of using silent dot voting as a way to generate and force rank the ideas of a team. It was a great way to efficiently bring forth the best concepts and made us take time to consider each concept. Because it worked so well, I used this method with my other projects when our team needed to ideate.

We put together what the customer journey would look like for the potential product, with the highlighted feature of reservation extension.

We each sketched our own paper prototypes, all with this basic flow:
Find a car>view information about a car>go through reservation process>redeem reward minutes>confirm reservation

This way, we could test solely the ease of use and concepts of the prototypes.

For my personal prototype, I explored using a pop-up system to remind the user to redeem rewards. It was more text-heavy than all the other teammate’s prototype. I also had a clear CTA to reserve a car on the home screen. Mine was also the only prototype that did not incorporate a map to initially find a car.

Most of the other team members prototype had maps and filters, both of which was not present in my prototype. All this factors greatly influenced users later on in our testings.

I struggled to draw out the paper prototypes initially. At the time I did not realize that the point of this initial paper prototype is to test out the concept and flow more than the actual copy. I realized in hindsight I spent a lot of the time on the details that wouldn’t really matter in a low-fi prototype.

My intention was to draw it out as perfectly as possible so the concept can translate well when it’s time to mock it out on the screen. From these initial sketches low-fi prototypes, I learned to iterate quickly and make mistakes so I could eliminate the bad ideas and improve upon the ones with potential.

Concept testing

10 participants
3+ hours totals
Paper prototype and after test survey

We took the feedback from the surveys the participants filled out after the test and made the necessary changes to each of our prototypes. We decided to have each participant fill out a survey because participants would have more time to think about their response and it helped us keep a record of each of each test

We not only learned to approach strangers to test our prototypes, we also learned to ask the right questions to promote more honest feedback from the users. It was at times difficult to accept problems when users fail to go through the flow of my prototype, but I learned to not take those problems personally or as a testament to my skills as a designer, but rather a process that all prototypes have to go through in order to become better.

It was humbling to see how users uncovered issues I never thought about. I see the merits of paper prototype since it tested only for the concepts rather than the color or layout. The feedback from users were immensely helpful, even when it was hard to acknowledge when they had problems with my prototype. The users, as they say, is never wrong. I enjoyed the challenge of making the interface as easy to use as possible, even for the segment of users who weren’t tech-savvy.

iterations

After two rounds of testing with paper prototypes, we made changes when mocking up our Axure prototypes. These changes were based on user feedback and the need to rearrange elements on the screen in order to maintain visual balance and hierarchy.

During this transition from paper to screen, I became aware of how much more detail was required in order to flesh out a mid-fi prototype. Everything was bigger on a paper prototype due to limitations of hand sketches and legibility. I recreated a new home page and car rental page because I couldn’t elegantly transfer the layout from the paper onto the screen. I now knew that this was also part of the iteration process, and when sketching paper prototypes I should also keep in mind that there would be a lot more room on the screen.

Car station locator

In the initial paper prototype, the nearby car stations were listed, showing distance and address.

In mid-fi prototype iteration, map and list view was incorporated as the home screen to help users better visualize the information and encourage interaction.

listing cars

Because low-fi prototype only allow me to convey the basic idea, so most of the copy are squiggles.

In the mid-fi, I need to prioritize and be specific about the information that is shown to the users about the car in list form. Icons are added and hierarchy becomes clearer.

I learned from this transition process of making mid-fi prototypes that it’s important to first get the key elements onto the screen, then adjust and fine-tune when there was time. I also realized that although some changes were normal when moving from paper to Axure it was not necessary to do an overhaul on the designs. Doing so not only took up a lot of time, but also was unnecessary since only user testing could validate the layouts. It is always a good rule to follow the saying “if it’s not broken, don’t fix it.”

converge

After we user tested our Axure prototypes, we converged by taking the average of all the user ratings on each, then decide upon using the highest rated prototype as a “base” since it objectively proved to be the most usable based on user’s opinions.

We recorded the scores given by each user we tested and averaged out the score for each section. We then determine what tested best by finding the prototype with the highest averages.

We then took the features that tested well and added it to the base prototype. There were something from each of our prototypes that were added to the converged prototype, so each of our team members felt like they each had a part in the combined product.

We all agreed that this was the easiest way to converge all our different ideas than “Frankensteining”-- taking parts of different prototypes and combining them into one - which was risky due to the fact it would be a whole new prototype without any user feedback.

This process of combining and converging our prototypes was the most difficult part of this whole project because we each had an idea of how the prototype should work and look. The averaging of user ratings was a way to cut through biases and choose the prototype that was the simplest from the user’s perspective rather than our own opinions.

iOS vs. android

A valuable lesson I learned from the converging process was the importance of learning about Android and iOS conventions. Little did I know I was designing for Android platforms in my prototypes because I was using an Android phone at the time, therefore conventions that I thought were obvious did not exist on iOS devices.

I was also used to seeing the funnel icon representing the Filter function. When I suggested that we put a funnel icon next to “Filter”, my teammate was confused about why I wanted to do that. It turned out that the funnel icon did not exist in iOS platforms, and since she had only ever used iPhones, and I Android, we had a brief miscommunication in regards to how something should look. After attending a workshop that pointed out the nuances of each platform, it became clear that each of the conventions rarely, if ever, cross over one another. I learned that it was absolutely vital to understand the guidelines for each platforms and stick with it in during the design process.

In iOS: the filter option is a button with the words "Filters" on it

In Android: there's a funnel icon to represent the filter option

UI

We then added color and style to our converged prototype. Each of us diverged once more to create our own style tiles. I created a look based on our persona of Peter, since he was the target persona based on our research.

Since I imagined Peter to be a family man with a desire to express his masculinity through the occasional splurge on rental vehicles, I wanted to create a dark UI to:

1. Invoke a masculine, high-class feeling to the interface and
2. Experiment with creating a dark UI for the first time

Since we found through our Competitive Analysis that there weren’t any carsharing services that had a high-end, luxurious style, I thought this was a great opportunity to experiment with the UI and try something I never did before. I enjoyed the process of creating the style tiles and creating Hi-Fi screens. Even though my main focus was UX, the opportunity to flesh out black and white wireframes with color was satisfying.

When we finished our key hi-fi screens, we presented them to our participants . After each prototype, we asked them to use adjectives to describe the prototype and to rank from 1-5 how the liked the layout and color. All the questions we asked were relevant only to the look and layout of the prototypes, since we were no longer testing the flow or the conce

We found that everyone responded differently to colors and interface design and has their own preference on how things should look. There were no clear winner or an especially popular prototype, though users preferred prototypes with light UI.

For our final round of convergence, we decided upon using my dark UI prototype because it averaged out with the highest user rating. I was hesitant about my team choosing mine because it was experimental and unconventional compared to the look of other carsharing apps. Looking back, it would have been a good idea to discuss a way to incorporate the more preferred light UI, even though they liked the look of my dark UI prototype overall.

For our logo, we stayed with Uber CarShare, which was the name we had for our fictional company since the beginning of the project. The logo showed C and an S in the negative space. We all really liked this logo, so we chose it as our final logo.

It was unclear in the project guideline whether to keep with the Uber look. However, I was satisfied with our product nevertheless because I learned a lot about dark UI conventions and had fun with creating the look of the app.

It was later known from the feedback after we presented our prototype that we broke some rules of UI in laying out cards and aligning elements to a grid because our team did not have a clear understanding of layout conventions. Since this was something that none of us knew, I wasn’t too bothered by it but it did made me aware that I should deepen my knowledge in UI conventions.

The solution

rewards

In the initial user interviews and competitive analysis, we found that users preferred to use rental car services over carsharing services because there are rewards and incentives for being a regular customer.

The trend we see from our data shows that users who have used carsharing had a great experience with it, but rarely is it their top choice when they need a car.

Therefore, to increase the rate of return from users and to incentivize them to make reservations, we created the rewards system.

This system allows users to redeem unused minutes from their previous reservation, thereby encouraging them to reserve with Uber Carshare the next time they need a car.

In addition to having the option to redeem rewards during the reservation checkout process, users can also view how much reward points they currently have, and when and how they have earned it.

Rewards have an expiration date as well, adding another level of incentivization to making a reservation.

extend reservation

A prominent pain-point our users have with the current carsharing services offered is the inability to change the reservation, and fees are incurred even if the car is returned late by a few minutes.

Because of this, we implemented the option to extend the reservation, with a 10 minute grace period. There is also transparency to how much extra additional time extensions would cost so users will know exactly what the total cost of the trip would be.

FInal thoughts

Future considerations:

• Explore the possibility of incorporating Uber Carshare into the different modes of transportation, so carsharing can easily fit into user’s current way of getting around
• The prospect of carsharing among millennials and whether this demographic is using carsharing or have the potential to become customers

Things learned brought into next few projects:

• UI conventions, especially iOS and Android conventions
• The ability to observe everyone’s working style, adapt to it, and communicate effectively
• Work quickly and fail often to get the best ideas out in a short amount of time
• Done is better than perfect
• One can never predict everything that a user does, so having issues come up during testing is normal and good thing because the feedback makes the product even better
• Respect teammates by acknowledging their ideas

Overall, this foray into my first team project was a great learning experience. Perhaps the most valuable lesson I learned throughout all of this was the importance of understanding different communication styles. I not only learned about my teammates’ styles but that of my own as well. No one on our team have worked this closely with a group for a design project, so we all adapted ourselves in order to efficiently communicate and contribute value to the work we were creating. I brought this knowledge into my other team projects, and kept an open-mind whenever someone had differing opinions or wanted to do things in an unconventional way. It was a difficult lesson to learn since I was so used to a certain process, but the end results were almost always indisputably better than my solo idea.

Great designs, I now learned, were never created by just one person. It took a team of creative individuals, each with their unique perspective and background, to make something truly brilliant. This project challenged me to think outside the box and helped me see that there was no one way of doing things. This constant striving for a better layout, user flow, and storytelling solidified my resolve to pursue the career of UX, because it’s one of the only industry where success is solely defined by helping others succeed.