Role: UX Researcher for Ridecell

UX Research Project Lead:

Eileen Ellis

Launch Team:

Brian Suckow, Luis Huapaya

Customer Success Team:

Brian Lo

Product Team:

Haley Burns, Ashok Sundararajan, Tina Summers

Engineering Team:

Steve Warner, Arun Elangovan, Ryan Thomas Correia Ortega, Sujata Mehta, Abhishek Chawan, Bhargav Reddy Ankireddygari, Alex Blokker, Paul Wicks, Karen Feng, Hachim Hamidi, Aniruddha Kadam, John Nguyen, Chetan Gaikwad, Alexei Sorokine, Santoshi Kattamuri, Farzaneh Nourmohammadi, Michael Nickey, Brent Scarafone

Data Engineering Team:

Peter Situ, Kim Le

Design Team:

Matthew Anderson, Mark Stanton, Stefan Ganchev, Eva Aschenbrenner

Clients:

Penske Dash was a carsharing service created by Penske Corporation that operated publicly in Washington D.C. and Arlington, Virginia from October 2019 to April 2020. Penske Dash offered A to B carsharing with the option for members to park and end rentals on the streets and in partner lots/garages in the Washington D.C. and Arlington areas. The service was closed after 7 months of operation due to the change in the economy amid the COVID-19 virus.

www.penskedash.com

Colonial is a parking operator serving the markets of Washington D.C., Suburban Maryland, and Northern Virginia. Its location types include open lots, parking structures, and subterranean parking garages.

https://www.ecolonial.com/

Ridecell is a SF-based B2B2C startup that offers a tailorable platform for companies that want to enter the new mobility market, namely carsharing, ridesharing, and fleet operations. Launched out of Y Combinator, it has raised a total of $73.8M including its Series B round that closed in November 2018. The company currently has offices around the world, including the US, India, Spain, Germany, and France. Ridecell also owns Auro, an autonomous vehicle company, that operates out of Milpitas, CA.

https://ridecell.com/

Research Prior to Travel

• The terminology that would be used to categorize the different parking types for both Ridecell and the client was set as one of the first steps in planning the research. The nomenclature was selected by researching architecture white papers and construction and parking company websites.

• The Ridecell Research Team identified which parking lots/ structures/ garages to visit on the ground based on their locations as part of the urban landscape, type, carsharing service rental availability, and team and client schedules.

• Current pain points users face was researched by looking at Yelp reviews of specific parking garages/ lots/ structures, reviews displayed on the Colonial parking website, and cold calling the garages to speak with attendants.

• Knowledge was gained about existing competitors like Zipcar, Getaround, and Maven by exploring their official websites. Since the Penske Dash service was not yet in the market, Zipcars and Getaround vehicles located in selected Colonial parking garages/ lots/ structures were reserved for testing purposes.

• A cognitive walkthrough of the user journey was conducted to set up the research recording structure in Airtable. This was important as the findings needed to be recorded on foot or in the vehicle while parked and driving, so the mode of recording had to fit those research team needs.

Research In-Market

• In-market competitor testing and evaluation was conducted. In addition to the carsharing services tested during the immersive research, the Ridecell Research Team also tried Car2Go and Free2Move to understand the already existing freefloating models available to users in Washington DC and Arlington, VA.

• Think aloud protocol was used by the Ridecell Research Team to narrate thought process across different steps of the user journey (our team did not have the budget to speak to actual carsharing users in-market at this point).

• Intercept interviews with Colonial garage attendants and valet staff were conducted to understand how they worked with the already available carsharing services at their parking location, and what positive points, pain points, and needs their customers had in using those services.

Research Prior to Travel

• The Penske Dash Launch Team Manager and Customer Success Manager were interviewed to learn what feedback had already been received from the client pertaining to the research subject.

• A remote workshop with the Penske Dash client team was conducted to:

  • Understand Penske Dash’s current damage reporting process including types of damage (including cleaning), how Penske Dash does reporting internally, how they manage and resolve issues, what data needs to be stored, what information they need to access periodically (analytics), and applications for different types of services.

  • Review information Ridecell has already received from Penske Dash about damage reporting, to receive clarification, if needed.

  • Bring up use cases and test hypotheses with the customer according to the conversation.

  • Understand Penske Dash goals for damage and condition reporting, including what they are aiming to do in the future i.e. plans or processes that are already underway.

  • Prioritize Pain Points/Proposed Changes brought up through the workshop.

  • Develop criteria about what Penske Dash needs Ridecell to consider when designing the solution.

• Stakeholder interviews were conducted with different Ridecell internal teams including Product, Design, Engineering, Launch, and Customer Success, to understand what they would like to learn from the user research trip and to gain buy-in for the process and results.

• Cognitive walkthroughs were conducted with the main Penske Dash product designer to locate gaps and pain point areas in the flows the research team would test, according to different scenarios such as: different travel methods to the garage location, during and outside of garage business hours, whether the user was registered or not, whether the user was signed in or not, if the user was away from the vehicle being reserved vs. at the vehicle, etc.

• Since Ridecell was not allowed to use the actual Penske Dash consumer app and service (vehicles, Colonial partner parking garages) for testing, I needed to coordinate with engineering team to reserve and learn how to set up our in-vehicle carsharing hardware product, identify Ridecell white label apps to test with, reserve a QA environment to ensure that the service would not be disrupted while in use, and gain buy in and support when the research team traveled onsite in case we needed to troubleshoot stability issues.

• Other scoping and research was conducted to set up the research trip, including:

  • Scoping and managing the research budget including: travel costs, recruiter costs, respondent incentives, vehicle rental, office space rental, parking garage payment.

  • Worked with the Ridecell legal, insurance, and procurement teams to ensure regulatory, client, and company compliance.

  • Recruiting Ridecell team members to support the research work in-field.

  • Identifying, selecting, and managing research recruiting vendors, and developing user research assets such as screeners, discussion guides, legal documents (NDA and recording releases), and incentive payment receipts.

  • Other research and setup for the research project, including renting a similar vehicle through Turo, selecting a comparative parking garage in an area near to a Penske Dash partner garage, reserving a nearby Breather office space for part of the testing.

Research In-Market

• Conducted 17 user research in-person interviews with in-field usability research tests, at 2 hours per respondent.

  • Respondents were limited to the markets of Penske Dash in Washington D.C. and Arlington, Virginia, and were segmented according to 4 main types:

    • Intender (previous car renter from a traditional car rental agency like Hertz, Enterprise, etc., but not a current carsharing user)

    • Current Penske Dash Users

    • Competitor Users (does not use client product Penske Dash, but does use competitive products like Car2Go, Free2Move, Zipcar, etc.)

    • Former Penske Dash Users (have used it at least one time before but have not used it in the past month or longer)

  • The research structure was as follows:

    • User Research Interview. The respondents met the Ridecell user research team at the Breather office location and were interviewed to gain insights about their background, vehicle rental and carsharing experience, etc.

    • Simulated Lab Usability Testing including Task-Based Analysis. The respondents were asked to complete a series of tasks while in the office space, including registering for the service, reserving the vehicle, and reporting damage on the vehicle via the in-app damage reporting flow. Respondents were also prompted to gain feedback on specific features, placement of buttons, terminology, etc.

    • In-Field Usability Testing including Task-Based Analysis. Respondents were asked to locate the test vehicle on foot using the Ridecell white label app. The test vehicle was parked in a nearby parking garage that mimicked the Colonial partner parking garages with barrier arms. During this process, the Ridecell research team asked the respondent a list of questions, and asked them to complete tasks including beginning and ending the rental.

Offering the Service in High Vehicle and Foot Traffic Areas May Not Be Ideal

While it seemed like offering the service in high traffic areas close to multiple modes of public transportation made sense, our research found that these areas in D.C. were often hectic due to the urban design of the area, the types of parking that were available in the area, and the high foot and vehicle traffic. Therefore, there was a high chance that the service may not be utilized if located in those areas.

User Experience Implications

For a user with little driving experience, who may be using the service for the first time, or who may be familiar with the locality on foot but not necessarily via driving, having the service in a high traffic location may cause stress and result in a negative view of the Penske Dash service and brand.

Business Implications

Since the Penske Dash partnership with Colonial entailed that Penske Dash would need to pay for the parking spaces it uses at Colonial locations, it was important that locations with a high probability of utilization were selected, especially during the first phases of the service launch. If the service was launched in a low utilization area, the money paid to Colonial for the ability to park there would be a sunk cost.

Locating the Vehicle is One of the Most Important Parts of the User Journey

Through the research, the team found that one of the biggest pain points the user may encounter upon use of the Penske Dash service was having to locate the vehicle when parked in a parking lot/ garage/ structure.

An example of this was with the Union Station Parking Garage (shown above). It took the research team so long to locate the Getaround vehicle that was reserved for the research test (it took over 30 minutes), that the team was almost forced to cancel the reservation. Despite the fact that Union Station offered both Maven and Getaround services, complications arose because there were multiple parking garages, multiple entrances to the parking garage containing the Getaround cars, lack of knowledge from the staff that the carsharing service even existed in their facilities, lack of signage leading to and within the garage, etc. In the end, it was decided that the Union Square Parking Garage should be excluded from the Penske Dash service due to the difficulty in being able to find the vehicle.

User Experience Implications

By clearly communicating the positive points and pitfalls of competitor services across different types of Colonial parking, we were able to give details to the client, outside of the Ridecell products, as to some recommendations to make it easier for users to get over the initial hurdle of finding their car.

Business Implications

Since the business revenue is driven by vehicle rentals, if a vehicle is not rented because it is difficult to locate, the ROI on that particular vehicle would be low. At worst, the underutilized vehicle may in fact cause the service to lose money as no money would be generated to offset costs, and more costs would need to be incurred to have someone come to rebalance the vehicle (move the vehicle to a more desirable location) and/or have to pay parking fines as there are often limits on how long a vehicle can be parked at a particular location on the street. By putting focus on these initial steps of the user journey, the possibility of low vehicle utilization because the renter simply couldn’t find their car would be greatly reduced.

The Driving and Parking Experience Should be Considered

In addition to the physical location of the Colonial parking garage/ lot/ structure, the user experience of actually driving the car in and out of the space, as well as finding where to park, needed to be considered when considering partner locations for launch. This not only means that the size and placement of the parking spot needed to be evaluated, but also the surrounding architecture of the parking space, wayfinding for driving within and exiting/entering the garage, and instructions and availability of support staff when confusion arises.

User Experience Implications

A feeling of intimidation may arise from just the prospect of conducting difficult driving maneuvers to get in and out of tight parking spaces, and may cause a user to cancel the reservation. In the future, a user with minimal driving experience may be intimidated with the prospect of driving out of or parking within a tight parking spot and so this may impact their decision to rent vehicles in specific parking lots/ garages/ structures with these features.

For example, during the research trip, one Colonial garage that was evaluated had parking spots aligned in such a way that it took a 5-point turn just to drive out of the spot, even though the driver was highly experienced. The vehicle that was rented had a large dent in the side from a previous driver who had damaged the car trying to get out of the spot, which had a large column to one side (shown above).

Business Implications

Since each parking space had to be paid for by Penske Dash to Colonial, it was important that the spaces be used not to park a single vehicle for long lengths of time (which pointed to low utilization) but for numerous shorter lengths of time (high utilization).

Additionally, a difficult parking and driving situation meant that the Penske Dash vehicle was more likely to end up damage, thereby increasing the maintenance cost of the vehicle if it was repaired, and damaging the brand image if left unrepaired but still available for public use.

Different User Types and Use Cases May Impact Parking Location Selection

Another factor to consider when selecting the parking type and location to include in the Penske Dash launch were the needs of particular user groups: women, people with children, passengers with injuries or disabilities, etc. The research team needed to do the tests from the standpoint of different personas and use cases to discover potential issues to be brought up to the client and Ridecell internally.

Locations such as these were brought up to the client and impacted the selection of specific garages for launch. On the Ridecell side, the research findings translated to clear recommendations in the creation of new app features to communicate what the parking lot/ garage/ structure offered in terms of safety and convenience.

User Experience Implications

Many of the parking garages explored during the test required the user to walk down the main vehicle ramp for multiple levels in order to reach the vehicle. This is dangerous in and of itself, and for people traveling with luggage or children, this may be enough of a barrier to impact the rentals and dropoffs at that particular location.

Something else the research team needed to investigate was parking lot/ garage/ structure access during the nighttime or after hours. In those cases, the neighborhood location of the parking lot itself, the abundance or lack of lighting, ease of entry, and presence or absence of 24-hour on site attendants would also greatly impact utilization of the Penske Dash service at that location. For example, dimly lit subterranean garages, with easy public access but low foot traffic at night, and no onsite staff may deter potential renters because of its potential for danger.

Business Implications

Penske Dash was especially concerned with the safety issue, as their business was focused on delivering a great service to users, and they had awareness that any negative outcome related to a reservation of their vehicles may result in a negative view of their brand.

Not addressing nighttime access issues (not only the technical side of parking lot/ structure/ garage entry and exit but also the perceived danger and inconvenience) would mean that for a number of hours per day the Penske Dash vehicle would not be in use, and so would not be generating revenue, just because it is parked in that particular location.

The Registration Flow is OK and Doesn’t Need to be Revamped

6 months before the Penske Dash post-launch research project with consumers, I conducted internal Ridecell interviews where I spoke to 32 people from every department within Ridecell to scope out potential research work for the UX research roadmap for the following year. A common theme that came up during these interviews was the idea that the Registration flow of our white label mobile app (and therefore the registration flows for all of our consumer user-facing mobile apps) needed to be updated in a big way. I decided to take the opportunity of the consumer user research trip to test the usability of the Registration flow and understand what target consumers thought about aspects like terminology, features, etc.

We found that aside from certain terms that needed to be changed due to confusion about their meanings, and concerns about privacy and verification (as driver’s licenses and faces needed to be scanned, and driver information needed to be verified by a third party), not much actually needed to be changed about the registration process.

User Experience Implications

Many respondents we took through the Registration flow found the process easy, but a couple of people brought up concerns pertaining to trust, privacy, and responsibility. For example, some terms, like “verification process,” led respondents to question aspects of the service like who exactly was doing the verification, what kinds of information the entity was verifying, verification criteria, and the waiting period to be able to use the Penske Dash Service.

When prompted during the research interviews however, we were able to uncover easy remedies to the problems, like making sure that the verification process steps and information being verified was explained clearly, plainly, and in larger text. Changes like these help build trust in the Penske Dash service, which would help with sign up numbers.

Business Implications

As we found that only minor changes needed to be made by our Product and Engineering teams, that would largely involve small changes in writing which were easy to do, this helped Ridecell avoid a time- and resource- consuming revamp and reprogramming of the entire Registration flow.

Through the study, the Ridecell team was also able to learn variations in consumer understanding of different legal, security, and insurance terms. Namely, we learned what words concerned users, including those that specifically deterred users from signing up for the service, so that Ridecell could make those changes and advise clients in their designs. By taking this into account, this would help the Penske Dash and other client consumer-facing services gain more users, and therefore, revenue.

Locating the Vehicle When Parked in a Parking Garage is Still a Huge Issue Even After Parking Pin and Parking Information Sheets were Added

Part of the user experience test we put consumer user respondents through involved having to use the Ridecell white label app to navigate to and find a vehicle parked in a subterranean parking garage. What the team found was that despite the creation and inclusion of a Parking Pin and Parking Information sheet in the mobile app, and the fact that only a single parking garage was shown on the app, respondents still had difficulty in locating the parking garage on foot, and most required assistance from the research team to navigate to the correct location.

The problem was due to multiple factors:

• The Parking Pin and Vehicle Pin were shown in different locations, and respondents often walked to the Vehicle Pin location, which was across the street from the location of the vehicle in the actual parking garage.

• The Vehicle Pin was actually next to another garage entrance, but for a different garage, which added to the confusion.

• The Parking Pin was often covered by the Navigation Comment Box, and so respondents did not even see where they should walk to.

• The GPS location is sometimes incorrect due to the signal bouncing off of different tall buildings, and signal scramblers used by government buildings located across Washington D.C.

In addition to this, once within the garage, we found that if the vehicle was parked more than one level down, a respondent would typically give up on locating the vehicle and the rental altogether.

User Experience Implications

Locating the vehicle when it was parked within a parking garage was the biggest problem the respondents had during the user research test. Many respondents during the study expressed frustration with not being able to easily locate the vehicle, especially when it was cold/rainy outdoors (research was conducted in February), or after dark when street signs were difficult to read (research was conducted until 6pm or 7pm, after sundown). Often, respondents mentioned that if the research team had not been there, they would have given up on locating the vehicle earlier, or would have tried to dial a customer service number.

Business Implications

If the consumer user cannot locate the vehicle when it is parked in a parking garage or structure, a rental cannot be started, and therefore, no revenue can be generated. If the experience is frustrating enough, the user may think negatively about the service and brand, and either never use it again, or only choose vehicles clearly found on the street, which may cause a rebalancing problem.

Penske Dash was also cognizant of costs related to customer service hotlines, and wanted to have a service that would not strongly rely on customer service calls that may still not help solve the user’s issues.

The Damage and Condition Reporting Flow and Screens Must be Redesigned to Meet Client Objectives

One of the main objectives of the research study was to evaluate the Damage and Condition Reporting flow and screens, the steps in the Penske Dash mobile app that a user would go through to report or confirm any damage or cleanliness issues with their rental vehicle.

By using techniques such as task-based analysis and asking the user questions about the meanings of aspects of screens like buttons, colors, and the UX writing, the Ridecell research team was able to uncover insights including the following:

• The information hierarchy of the damage and condition reporting directions led respondents to ignore the instructions altogether.

• Most respondents were confused about the meaning of the different colored dots on the screen, which are used to indicate whether or not the vehicle had been damaged in that specific place.

• Respondents had different ideas about where in the user journey the damage and condition reporting screens should appear (at this point in the mobile app design, the damage and condition reporting screens automatically pop up when a user unlocks their vehicle to begin a rental).

  • Some wanted to be able to report damage before starting the rental, as they wanted to be able to report exterior damage before getting into the vehicle.

  • Some respondents thought that users should be given some free time (without being charged) to check the vehicle interior for damage or cleanliness issues, and have the option to change vehicles if needed without incurring fees. They mentioned previous experiences with other carsharing services in which the interior damage was so severe that driving was unsafe (one mentioned that part of the driver’s wheel of a competitor service fell off while driving) or very uncomfortable (one respondent said that they had an allergic reaction because her seat was covered in dog hair).

  • A couple of respondents thought that the damage and condition reporting process should occur at the end of the rental, so that users could record any damage that had been inflicted on their vehicle during their reservation (i.e. if damage occurred while they were parked but still in the rental, etc.).

• Some respondents wanted to be able to view what damage had already been reported and be able to upload photos of their own, so that they can confirm what damage was already there so they would not be held liable (the version at the time only indicated previous damage with a yellow dot, which was not clickable).

The findings were used to make recommendations to the product and design teams about what changes needed to be made to the Damage and Condition Reporting flow and screens, which included:

• Making the instructions and options to report more clear, especially if color is used to indicate a change in status.

• Having the instructions be at a more legible font size and darkness.

• Having the Damage and Condition Reporting screens appear and be more obvious during more points within the journey.

• Allowing users to upload and review photos posted by previous users with regards to damage and cleanliness issues.

User Experience Implications

The key issues respondents were concerned with were: liability (if damage was done by a previous renter), safety (if the vehicle was previously damaged), and comfort (if the vehicle was still safe to drive, but was dirty). If those key concerns were not addressed, then users would not be inclined to use the service in general. The process for users to report the problems they come across during their Penske Dash reservation needs to be easy enough to do but also give users the peace of mind that something will be done to solve the issue.

Business Implications

The Damage and Condition Reporting screens are important because for the Penske Dash client, revenue is lost on vehicle damage that cannot be traced (and therefore recouped) from the renter who caused the damage. These potential loses were estimated at $2+ million per year (based on the figures of competitor carsharing services). Additionally, if the vehicle is unclean, this may cause users to cancel their reservations early (and often without the Penske Dash service knowing why), which would also lead to lost revenue.

Parking Garage Selection

As the client was wary in terms of anything that would negatively impact the brand, especially in terms of car damage and the overall user experience, the findings from the research impacted the selection of specific parking garages, especially for use cases like when overflow parking is needed.

On-Site Penske Dash Parking Signage

Designated parking spots and clear Penske Dash signage at each spot were being discussed, but the need for them was made clear through the on-the-ground research and creation of deliverables such as this journey map and presentation.

New Penske Dash App Feature: Parking Pin

For Ridecell, the research findings meant that new features needed to be developed to aid in the wayfinding of the vehicle.

A Parking Pin was created to indicate the location of the particular parking lot where the vehicle was located. On the technical side, since the service was not station-based (meaning that the vehicles were not associated with one Colonial garage/lot/structure but can be parked at any Colonial parking locations), the Ridecell team was limited in their ability to show the vehicle pin as “absorbed” into the parking pin at this time.

In-App Parking Information Sheet

As the comfort level and perceived convenience of different parking lots/garages/structures is largely subjective, the way the Ridecell team addressed these issues was through the provision of more detail in terms of parking location information. This way, the user would have key pieces of information they would need when it came time to find a place to park.

These included:

• Parking location photos on the Parking Information Sheet

• Wayfinding information with directions to the lot/ garage/ structure entrance

• Icons indicating parking features such as:

  • Hours with Attendant or Valet presence

  • Wheelchair Accessibility

  • After Hours Access

• Usability Instrumentation

UX Research Project Leader: Pre-Launch and Post-Launch

I led UX Research for the Penske Dash service, which included the scoping and planning of the research projects, Ridecell team training, research findings synthesis, research materials and deliverables creation, findings communication, and represented the user in product, business, and design meetings.

Research Project Creation and Planning

I worked with the Customer Success Manager and Launch Manager to identify the scope of the Colonial parking lots/ garages/ structures, as this information came directly from the client. I identified the variations of the different parking types and cross-checked them with existing competitor carsharing services that would be available during the times of our research trip to create the research itinerary. I also created the in-field data collection and filing method.

Research Team Training

I had created a research training document that included clear guidelines as to the roles that each person on the team had to fill, what needed to be recorded and how, what the itinerary for the week was, and where to upload the research findings files. The people on the team were myself, a Customer Success Manager, and Launch Manager. The other team members were not trained in design research, so more emphasis was put on how to think through the experience of the competitor services from the viewpoint of multiple personas.

In-Field Research and Contextual Interviews

I led the team in conducting in-field research where we evaluated carsharing competitor services at different Colonial parking lots/ garages/ structures and did intercept studies with Colonial parking attendants and valets while on duty at their parking locations.

Tester Survey Creation, Management, and Communication

For the evaluation aspect of the Beta Testing, I selected SurveyMonkey as the tool and I created the Satisfaction Survey, communicated responses as they came in to both the Ridecell and Penske Dash teams, and created a weekly summary presentation that was delivered to the client that conveyed individual survey results as well as comparisons to the service performance in previous weeks. Since background information about the beta testers was not provided, I conducted my own research using LinkedIn and other websites to put together a more detailed user profile to enhance the understanding of the responses.

Cognitive Walkthroughs

I conducted multiple cognitive walkthroughs with different teams during the months before and after the Penske Dash launch. Prior to the launch, I used cognitive walkthroughs with the Launch and Customer Success team members to create a structure for user journeys for research finding recording on Airtable, which was then refined in-field. In preparation for the post-launch user research with target respondents, I worked closely with the Carsharing Product Designer to identify and walk through multiple scenarios a user would go through with regards to the part of the Penske Dash service we were testing, to try to develop and implement solutions for the app before the trip.

Recruiter Selection and Management

I came to Ridecell with my own list of trusted recruiters, and for this project I contacted a few of them for price quotes and expected timelines, created the high-level project plan to explain what kind of respondent we were looking for and what we were looking to have them do during the test, and selected one based on their response. Once chosen, I worked to get them onboarded to the Ridecell system, created a screener for recruiting, and worked with them until after the research was completed to make sure that they were paid on time by our company.

Moderated User Research Interviews and Usability Testing

I conducted 17 user research interviews with notetaking support from 2 Ridecell team members at a rented office space located in Washington, D.C. As part of the research, I also led participants on an on-foot test where we looked at in-app and real-world experiences while searching for the vehicle.

In-Field Hardware and Software Testing Support

In addition to traditional qualitative user research, I worked with Ridecell’s engineering, launch, and customer success teams to map issues with third-party key replacement hardware and GPS. As part of this, I developed the research plan, created a findings logging spreadsheet in Airtable, and accompanied the team to conduct the tests with the client team in Washington, D.C. and Arlington, Virginia. While there, I drove our test vehicle, logged data from our third party and Ridecell systems, and tracked our route with both environmental photos and screenshots to map discrepancies and variations.

Research Findings Synthesis and Asset Creation

As the UX Researcher, upon the team’s return to the Ridecell office in San Francisco, I was in charge of synthesizing the research findings and creating related deliverables to communicate the findings to different teams at Ridecell (Design, Customer Success, Launch, Product, Engineering) as well as the client.

• 8 user journey maps (one for each Colonial lot/ structure/ garage visited on the trip) were created and shared with the client and Ridecell, complete with on-the-ground and vehicle photos, individual steps taken through each part of the journey, highlighted pain points and positive points, and candid notes about the experience

• User testing videos were created for the Ridecell internal teams

• Full research report including:

  • Full research project plan

  • User testing results with quote excerpts, screen by screen, sectioned by pain points, positive points, other comments

  • Appbot reviews

Ongoing Design and Product Guidance

As new features were being developed for the duration of the engagement with Penske Dash, I worked with the Ridecell designers and product managers assigned to Penske Dash to identify what needed to be created to serve user needs, what needed to be prioritized, and how it should appear in the Penske Dash app, on screen and within the overall flow. I provided recommendations stemming from the research and UX/UI design best practices. The design and product guidance was provided on a weekly or more frequent basis over the course of a year, before, during, and after launch.

Client and Ridecell Internal Team Presentations

In the midst of the in-field research the Ridecell Research Team was asked to present their current findings in terms of the possible pain points, positive points, and needs users would have during their user journey at each Colonial parking location tested at that point in time. I was in charge of quickly synthesizing the findings, creating the presentation deck, and presenting the findings concurrently to both the Penske Dash client team in person and the Ridecell team in San Francisco who called in via Zoom. After the in-field research was finished, I was in charge of adding the additional findings to the presentation as well as presenting the overall user journey maps to both the client and Ridecell Internal teams including Product, Design, Launch, Customer Success, and Engineering.