Donna Miller Watts

Re-Design Research Challenges:  How to re-shape what began as an anonymous peer-to-peer parking and ride sharing capability into a modern standalone app that people could feel secure using. 

• How to update a peer-to-peer ride- sharing capability that offers significant, timely utility to users, while uncoupling it from the GreenCar Buddy parking and ride sharing combination app

• How to remove features that have been superseded by onboard navigation capabilities and other advances while retaining and extending the ride share capabilities' differentiation from similar competitors

Role:  Sole User Research, User Design, Web site creation, wire frames, information architecture, competitive research

Tools: HTML/CSS, Bootstrap, Javascript, Sketch, PhotoShop

Approach:  I used a three-phase approach. 

First, I researched reactions to three older versions of rideWindow to answer specific application-based questions. 

Next, I conducted basic research concerning individuals' ridesharing experiences and queried a smaller group of commuters on their experiences with ridesharing and carpools. 

Lastly, based on a combination of test participants' application-level reactions and the results of my core user research on commuting, I offered a handful of sample site maps, wireframes and prototypes. 

Research: To begin, I observed test participants' interactions with rideWindow's existing, legacy incarnations.  I sought reactions to ridesharing in an app - regardless of the relative clunkiness or old-fashioned look of the rideshare functions. 

• I wanted to understand commuters' experiences with sharing rides and carpooling, which is the form of ridesharing with which most people are familiar - rideWindow "mobile" within the GreenCar Buddy iPhone app (I.)

• I also wanted to confirm whether or not rideWindow should exist as a separate app or remain, in a re-designed, combined GreenCar Buddy app - rideWindow legacy standalone web site (II.)

• I wanted to test reactions to the Facebook-limited ridesharing app, to understand whether or not users found ridesharing within that context more appealing - rideWindow Facebook app (III.)

Socializing Transportation

rideWindow began as a true peer-to-peer ridesharing capability (as a companion capability to its p-to-p parking space sharing capability, GreenCar Buddy), leveraging anonymous sharing of rides, its own way-finding capability and a system of tokens to encourage the honoring of riding, driving and pick-up commitments. 

- rideWindow today is a standalone peer-to-peer ridesharing capability, leveraging the social, work and neighborhood networks of the people who sign up to use it. Sign-up is free and your networks and activity are private by default.

How rideWindow evolved to its current form is a story of user research and the results of bringing research insights to bear on the design of a capability that people feel secure and comfortable using. 

Marketing site:  https://www.ridewindow.com

I. rideWindow "mobile" within the GreenCarBuddy app:   The first version, "GreenCar Buddy" app, which combined parking space sharing with ridesharing.  Here my questions concerned relative ease of use compared with a version of the same app in which the parking capabilities had been stripped out.

Results of completion of ride sharing tasks using the iPhone GreenCar Buddy combination app: 

• Five out of six of the participants were able to complete the assigned tasks without human or in-app help within the 15 minute time frame. A sixth participant finished in 17 minutes

• More than half of the testers said that sharing rides did not necessarily require parking at the end of trip for passengers and so they questioned why parking space sharing seemed to be the conceptual focus of the app instead of ride sharing

II. rW legacy standalone web site:  This rideWindow version was created as an initial test of rideWindow's separation from GreenCar Buddy, but was never field-tested.  We knew that whether a combined-with-GCB or a separate-app decision emerged, the antiquated style of the legacy site would change dramatically. 

But I still wanted to understand how people navigated through this existing website interface, however seemingly old-fashioned it was, as well as their reactions to the dashboard-style design created by the original developers.

Results of completion of tasks using the original rideWindow website:

• Five out of ten participants in the tests found the dashboard style of the old standalone site—with all options and tools on a single page—” easy to use”

• Five out of ten participants found the site “not easy to use” and when further queried, their responses summarized around the page containing too much information and appearing “too cluttered”

• Four out of six reported that although they thought it was “easy to use” because this older site enabled them "to see everything at once" (as one participant put it), they also found it "unfriendly" and, in the words of one participant, "stark"

• Half reported feeling more anxiety at the prospect of the anonymous ride share in this rideWindow incarnation than they felt with the same anonymous ride sharing within the old GCB app

III. rW standalone Facebook app:  The Facebook "app", was originally created several years ago to test responses to a Facebook-based approach to ridesharing, separate from parking space sharing.  I wanted to get reactions to the Facebook app, likelihood of use, and test participants' reactions' to limiting ride shares, even partially, to Facebook connections.

Results of completion of tasks using the rideWindow Facebook app:

• All participants found this means of completing the four tasks in 15 minutes familiar and easy to use

• All said that they found multiple offerings of ways to share rides within the app confusing, and for no reason

• One participant pointed out that the multiple offerings represented different means of communicating within Facebook and among friends and the larger public and so were misrepresented as distinct "features" of the rideWindow Facebook app.

Questioning the Experience of Ridesharing & Carpooling from the Ground Up:  I interviewed a small sample (10) of people whom I recruited online as test subjects and summarized and consolidated experiences, goals and desires expressed by this group.  We were also interested in subjects' experience with carpools, so I conducted separate, shorter interviews on this topic with a smaller group (6).

KEY INSIGHTS FROM USER RESEARCH

• Driving and sharing rides with others you are associated with is a familiar behavior, while parking space sharing is a new behavior, (especially when it involves strangers)

• Most of the time riding and driving do not necessarily include the need or desire to need, much less share a parking space

What emerged from this research was the nearly-unanimous desire of interviewees to ride with people who were not strangers with no connections to them. 

• Although several of the people interviewed said that they had used UBER and the shared-ride-hailing service Via with strangers as their fellow passengers on a ride, they felt comfortable about it because UBER and Via were corporate entities which, at least in theory, functioned as the ride sponsors, driver-vetters and monitors.

• When I asked participants whether or not they still trusted UBER and other ride-hailing services to be fully trustworthy vetters of drivers after recent incidents of ride-hailing drivers assaulting passengers, they still maintained that such incidents were notable as exceptions, but not the norm.

• With rideWindow's peer-to-peer, anonymous structure, almost all of the people interviewed said they would not feel safe in an anonymous ridesharing situation.

Given the new behavior that parking-space sharing represented, we had thought that perhaps only GreenCar Buddy might need to limit sharing between and among personal connections and extended associations through social, neighborhood and work networks.  However, with the product re-design and re-definition research I did, we realized that rideWindow would also need to become a product that invited people to bring their friends and colleagues along, and only share with people who were within their own extended networks.

Carpool Experience:  We were also interested in subjects' experience with carpools, so I conducted separate, shorter interviews on this topic with a smaller group of six participants.  In addition to understanding their experience with carpooling, I also wanted to understand how carpools were managed, if participants had experience car-pooling in the past. 

PROCESS - Testing Mobile Product Sketches & Site Map Iteractions:  I summarized the features available in the rideWindow web site and the rideWindow features of the original GreenCar Buddy mobile app in paper sketches to illustrate a potential mobile experience.  I then translated the paper sketches into a rough site map. 

Given the proliferation of way-finding apps, and my experience with these small tester/interviewee groups, it was clear that the way-finding capabilities of the original GreenCar Buddy/rideWindow mobile app were unnecessary for users, so these capabilities were reduced to graphic lines on a map, instead of the turn-by-turn capability the app had included originally.

It also emerged that the idea of rideWindow pools or riding "clubs" appealed to people in the same way that Meet-ups do, especially since testers visualized people like themselves, somehow related to themselves, as participating.  After this insight, I created wireframes using Sketch and over the course of a couple of iterations, pared the screens down as much as I thought possible. 

INITIAL SKETCH WIREFRAMES, RIDEWINDOW RE-DESIGNED & RIDEWINDOW MEMBER/NON-MEMBER USER FLOW

The next step was to put these wire frames in front of potential users, in paper form.  Some users expressed confusion, especially when asked to understand navigation from the first screens to the place in the app where the core activity happens: Get a Ride/Offer a Ride.  Based on this feedback, I returned to the drawing board, this time using the Proto.io prototyping software, to re-design screens, and move them around, animating them to get a feel for the experience of someone using the app.  

With the first clickable prototype testing, I found  test participants complaining about what seemed like "too many places to get to the same options."

• Need to collect minimum user information (name, phone #) to verify unique identity and to protect user networks entered for non-RidePool users

• Sticking points remained: the Join a ridePool section and

• ridePool's administrative capabilities

• Three screens were added to the second prototype version to address the sense of over-done screens & the need for smoother "flow" that participants reported.

Current State of rideWindow:  In the most recent, and, I believe, final version of rideWindow, the look and feel of the app, while still a prototype and not fully adhering to Material design or Apple design guidelines, has derived from the look and feel of the GreenCar Buddy standalone prototype.  The founders wanted to make sure that the design of both apps emphasized their inter-relatedness, and the fact that they are two sides of the same problem, made by the same company.

RECOMMENDATIONS FOR RIDEWINDOW’S FUTURE

One of the important features of the original anonymous peer-to-peer rideWindow & GreenCar Buddy combined applications was the merit-demerit system of tokens, used to reinforce the honoring of commitments of parking space transfer appointments, rideshares, etc.  This system was sidelined during the course of the evolution of rideWindow-GCB, but my hope is that when the final development of one or both of the apps is done, the company can look to implement the token system in an updated version.