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.
Storyboard 1 Task 2
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
-----------------------------------------------
Storyboard 1 scenario 1.
g4.
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.
Storyboard 1 scenario 3
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:
Scenario 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.
Scenario 2 - Alexis
Scenario 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.