Scenarios
- Charles is planning on going to campus today. He woke up at 11and needs to be on campus by 3pm, but besides that he doesn’t really care when he goes. He’s willing to give people a ride and leave whenever is more convenient for others. He is going to check to see when people have requested a ride. He sees that 2 people have requested a ride at 2, and then schedules a ride then. His car seats 5 (including him).
- Alexis is on campus and he needs to get to the house, Saferide and the T have both stopped running for the night, its too cold to walk and he wants to get a ride but he would not mind getting a cab. he’s flexible on when he is leaving but he knows he can’t leave in the next 30 min.
- Jorge needs to get to campus before 1pm. It’s 11am right now and he doesn’t care when he goes as long as he gets a ride before one. Jorge looks at the available rides and reserves himself a spot on a ride in Yifan’s car at 12:30pm.
Design 1
Task 1 (Charles)
g1.png 
- Bottom picture is splash page notices that there is no rides for the correct time, he click request.
Pop-up appears and he has to enter his name and phone number
* learnability high, pretty self explanatory
* saftey high you can always click back on your phone browser
* efficiency not the best if you know your not going to do anything right away, however very high if you need to know the next ride now.
--------------
g2 
He is looking for rides around 5 but the window is expanded for 6, so he clicks the the 5 o’clock bar. This expands the 5 o’clock bar, and notices there are no rides or request he clicks and area himself (made obvious by the concetric circles)
* learnablity low. Depending on the user there is no way of knowing that clicking the different menus will expand or collapse sections, and that clicking empty space will open a request
* saftey high, you can always click backspace, and expanding menus or collapsing them by reclicking them.
* efficieny medium, there are no shortcuts but its pretty quick and forces you to look at schedule which is done on purpose
----------
g3 
this pops up a menu with defualt value he turned in. Defualts being after time he clicked with his fingers, and before an hour and ten minute from that time. He then fills in the options about how many spots are requested, he enter the number one because his girlfriend is not coming along. He selects the type of rides he wants, and enters any notes about his specific request then clicks done.
*learnablity high its all labled
* saftey med/low, if you accidently click done but are not done it cannot be undone from this menu
* efficiency high since the defualts fill themselves
-----------------------------------------------
Task 2 (Alexis)
There is the same splash screen however, this time charles clicks offer, he has to sign in if the cookie is not saved on his browser. It then redircets him to the offer page. Simple he chooses the date, how many spots he has available and the time frame. He clicks see request,the next page that loads is a list with the time frame he asked for expaned, It has requests on the left, and offers on the right. Charles can then click on a block of request or click on a time zone to scheuldle his ride.
* learnablity high walks you through the process, however like before clicking empty space is not super obvious especially if you don’t use google calender
* efficiency med no shortcuts, but again that would increase the chances of duplicate offers
*saftey high back on the browser still undos everything
------------
g5 
if he clicks on empty space it sumbits his options and says thanks him. If he clicks on a request it shows him a list of people in the request, with a right triangle to show for notes and his specifc time. And it allows him to accept or decline that specifc request.
*learnablity high, except it might not be obvious to click on the arrow to find out more information about each person
* efficiency high can’t really be faster
* saftey low if you accidently add a request it cannot be undone from this menu.
Task 3 (Jorge)
g6 
same splash screen same thing about signing if in no cookies. This time Jorgito clicks on request, and it opens the menu. Jorge expands the section of time he is interested in and notices that Yifan has spots avalible. he clicks on that time zone
*learnablity med you have to learn to click a certain area, and a certain block to add yourself to that request, however, it is consistent with the rest of the ui
* efficiency high can ‘t reasonably be faster
* saftey you can click menus to collapse them, and click back if you accidently click an area
------
g7 
it opens a join Ride menu which shows the name of the driver and their phone number, shows notes the rider posted and the option to accept or decline. He accepts and it shows Yifan’s number in a way that phones recognize it as a phone number and you can call right away.
* leanablity high there really noothing to learn
* efficiency high can’t be faster
* saftey low like before if you click done you have to go to a different menu to cancel.
Design 2
Task 1 (Charles)
|
Charles opens the Next Ride website and enters his name and number and hits ok. This is simple, learn-able and difficult to screw up. This would be slow to do every time, however if this information is stored in a cookie it should be efficient in that it is only done once. |
|
This brings him to the main page which defaults to the “To Campus” tab. He can see the Date at the top, and the current hour is blown up in detail at the top of the scroll pane. He looks at the times between 11am and 3 and sees that 2 people are requesting a ride at 2. He clicks on the 2:00 time block and a menu opens up. This UI sacrifices learnability for efficiency. It is not immediately obvious that the times, cars and 'requests' are clickable. However, the display packs in a lot of information that is easy to parse quickly, and requires only a single click to get to the schedule menu. |
|
The schedule screen allows Charles to schedule a ride. He chooses the type of ride (car), the number of spots (4) and the time (which defaults to the selected time 2:00pm). In order to help charles choose a specific time requests near the selected time are shown. He can choose to recieve SMS notifications (for when people join/leave his ride). He then clicks ok. This UI has a number of clearly labelled fields which can be edited which is easy to learn. The defaults allow the user to get through the UI quickly. The immediate feedback in the UI provides safety and the user can always click cancel if they didn't intend to schedule a ride. |
|
This returns Charles to the original screen where he can see that his car has been added at 2:00pm with 4 seats. This gives the user immediate feedback about their action. |
Task 2 (Alexis)
|
Alexis gets the same landing page as Charles |
|
Alexis is then taken to the main page where he selects the "To House" tab. He sees that nobody is driving to the house anytime soon. The current hour is expanded, and he wants to leave in half an hour so he chooses the 2:30 time to make a request by pressing on the '-' |
|
This bring up the request menu. There are only a few options here: time, type and number of people all of which are clearly labeled and use standard input methods. This is very learnable, and with proper defaults can be very efficient. If Alexis has made a mistake he simply cancels. |
|
Finally Alexis is returned to the main page where a "1!" has shown up in the requests column to give feedback that his request was accepted. |
Task 3 (Jorge)
|
Jorge sees the same landing page as everyone else |
|
Jorge is then brought to the main page which again defaults to “To Campus”. He sees that the only ride before 1 is in the 12:00 block, without scrolling down to see a more specific time he chooses that ride by clicking on it. This opens a reservation menu. Again, this UI is sacrificing learnability. It's not immediately obvious that the car icon is clickable, however Jorge can quickly see that the most fitting ride is the car at 12:00 and can select it with one click. |
|
The reservation menu tells Jorge the name of the driver, the ride type and the departure time. He can then reserve up to 3 Seats. The screen also displays Yifan’s number witch icons which allow him to directly text or call. Jorge makes a selection and hits ok. Here the interface provides Jorge with additional information about the ride, and then allows him to pick a number of seats. This is learnable, and efficient. If the user doesn't want to reserve a ride they can simply cancel. |
|
Jorge is then returned to the main screen where he can see that he has been added to Yifan’s car and the number of available seats has been reduced to 2. Again, the updated UI give immediate feedback to the user |
Design 3
Task 1 (Charles)
Navigates to the Next Ride page and chooses the “Schedule a ride” option
The UI goes to the next page that lets Charles choose parameters for type of ride to schedule. He chooses the “to Campus” option and to schedule a car ride that leaves between 11:00am and 3:00pm. Then he clicks on Next.
He is then taken to another page that shows the ride requests in the time range he selected so that he can factor this information into his decision if he wants to. He sees that Pas2 and Pas3 want rides at 2pm so he decides to leave the house at 2pm. He clicks “Next”.
He then enters his name, contact info, number of spots and time in the final page and click on the finish button to complete the process.
* Learnablity - Easy to learn because it is what you see is what you get
* Efficiency - This UI only shows you the information you need based on the search parameters you input. Inefficient that you need to go through multiple pages to perform the action.
* Safety - He can always go back if he makes an error.
Task 2 (Alexis)
Navigates to the Next Ride page and chooses the “Find a ride” option
The UI goes to the next page that lets Alexis choose parameters for type of ride to find. He chooses the “to House” option and that he wants a car, van or other ride that leaves from campus between 2:30am and 6:00am. Then he clicks on Next.
He is then taken to another page that tells him that there are no currently scheduled rides in the time frame that he chose in the last screen. He is given the option to choose different parameters for a search or to request a ride. He chooses to request a ride.
In the “Request a ride” screen, he enters his name, contact info, and he chooses the option to auto-reserve a spot. He then clicks on finish to request the ride.
* Learnablity - Easy to learn because it is what you see is what you get.
* Efficiency - This UI only shows you the information you need based on the search parameters you input. Inefficient that you need to go through multiple pages to perform the action.
* Safety - He can always go back if he makes an error. You would need a different interface to cancel a request
Task 3 (Jorge)
Navigates to the Next Ride page and chooses the “Find a ride” option
The UI goes to the next page that lets Jorge choose parameters for type of ride to find. He chooses the “to Campus” option and that he wants a car or van ride that leaves to campus between 11:00am and 1:00pm. Then he clicks on Next.
He is then taken to another page that shows him two currently scheduled rides to campus in the time frame that he chose in the last screen. He then chooses to ride in Yifan’s car by clicking on it.
The next screen is for “Reserving a spot” in Yifan’s car. He enters his name, contact info, and clicks on the “Reserve a spot” button.
* Learnablity - Easy to learn because it is what you see is what you get
* Efficiency - Inefficient that you need to go through multiple pages to perform the action.
* Safety - He can always go back if he makes an error. You would need a different interface to cancel a request
1 Comment
Edward Oscar Benson
Excellent job. Detailed explanations, clean drawings, good demarcation of each task. I especially like that you used a phone stencil to enforce UI size constraints. Nice work.