User Analysis

All users are: educated, computer literate, and 18 - 30 years old.

The users can be placed into four groups by characteristics:

1. Brothers

• know the regular Van Schedule
• would use website frequently/ wants high efficiency
• would want frequent updates/ automatic refreshing
• knows most, if not all, numbers of people offering rides
• know where the house is located

2. Alums

• usually ride providers, but are not regular
• know a good number of brothers
• know where the house is located

3. Friends of the House

• may not know all the brothers
• know where the house is located
• may not want to sign up or register (want easy learnability)

4. Infrequent Visitors

• may not know many brothers
• may not know where the house is located
• would not want to sign up or register

Users of this application would fall into two distinct roles:

• Ride-Providers (someone with a car, the house van, posting a cab time, etc...)
• Ride-Requesters (passengers, bike borrowers, cab-sharers, etc...)

• A Ride-Provider can include somebody driving a car, somebody offering to lend a bike or someone planning to get a cab. Currently, a ride provider sends an email to a mailing list with their scheduled ride to let people know when they are leaving. These emails frequently go unnoticed and the ride-provider ends up paying for a taxi themselves or taking a lonely drive to campus. Additionally, the ride-provider may not be able to keep track of how many open spots they have, which can lead to overfilled cars. The current method of ringing the bell before driving to campus is not very effective in the case of unscheduled runs because there isn’t enough time to get ready; one brother says that he barely has enough time to grab his stuff when he hears the bell so he almost always misses rides to campus.

• A Ride-Requester is anyone looking for a ride; be it a scheduled car-ride, borrowing a bike or splitting a cab. To request a ride now, a person has two options. One is to spam a mailing list asking for a ride, which may effective but is a nuisance to people on the mailing list. Alternatively they can approach individuals who are known to be ride providers, which is time consuming and often unrealistic.

Task analysis

Possible tasks include:

• Checking for any possible rides and reserving a spot
• Offering a ride
• Requesting a ride
• Contacting people who are offering/requesting rides

1. Checking

• User must have time range in mind as well as a destination
• Usage is daily to weekly
• Time constraint: requesting/ reserving needs to be done in a reasonable amount of time (> 1 min)

2. Offering

• User must have time, space and destination
• Multiple times a day, often on a schedule
• Should be extremely fast and easy
• Ideally would be possible to do from a phone (via text)

3. Requesting

• User needs time and destination
• Usage daily to weekly
• Must have number of people requesting ride