• Created by Unknown User (ulziibay@mit.edu), last modified by Unknown User (lopopolo@mit.edu) on Mar 11, 2012 18:12

GR1 - Project Proposal and Analysis

User analysis

  • Persona 1: Novice user
    • General opinions: 
      • Useful thing to have. 
      • Without having to exchange multiple emails back and forth, you can schedule a meeting. It is convenient
    • Additional features: 
      • Reminder email for any change in plan. It is hard to get notified of sudden changes. It will be nice to get reminders if anything changes ( location, time etc.)
  • Persona 2: Power User
    • General opinions
      • Great idea, especially for users who have to constantly deal with scheduling meetings
    • Favorite Features
      • Being able to invite other people without having them log on
      • Having a recurrence option that can allow users to choose a day in the week to schedule a recurring event can help users because they don't need to recreate an event every time
    • Additional Features
      • An optimal message to be attached to the invite
      • A way to rank/select pre-scheduled flexible events that can be moved so it can be moved
  • Persona 3: Office Socialite
    • General opinions:
      • Only wants to use MashCal if it is easy to set up
      • Likes that he doesn't need to coordinate the optimal time for everyone
      • Wants to have everyone go to lunch with him. If the program says it can't happen, he doesn't have to feel bad about not accommodating everyone.
    • Additional features
      • Invites via text message
  • Persona 4: Dumbphone or non-mobile user 
    • General opinons
      • Adam liked the idea but thought it wouldn't be useful for him if it were mobile only.
    • Favorite features
      • Ability to import calendar once makes MashCal easy to use in the future because it is always in sync
      • Use of email as the communication medium means that even people without smartphones can use MashCal.
    • Additional Features
      • Make the interface not mobile only. There should be a standard, non-touch web interface.

Task analysis

Tasks:

Linking of calendars/create accounts,
  • Goal: 
    • To link/register users on to MashCal
  • Precondition: 
    • User want to create or join an event
  • PostCondition:
     
    • Have account,
    • Have calendars imported
    • Being able to create events
  • Subtask: 
    • Input login, 
    • Importing calendar

Create meetings:
  • Goal: 
    • Create a meeting 
  • Precondition: 
    • Have an account
  • Postcondition: 
    • Invitations sent, 
    • Subscription deadline set
  • Subtasks: Event recurence, deadline

Inviting people:
  • Goal: 
    • Sending invitations to people
  • Precondition: 
    • Existing event, 
    • Have intended users/ mail group (emailing list)
  • Postcondition: 
    • Users receive emails with a link
    • Event link created, 
  • Subtask: 
    • Choose group/emails 

View mashed events:
  • Goals: 
    • Browse through history of events
  • Precondition: 
    • Have an account; 
  • Subtask: 
    • Reschedule, edit events,
    • Filtering of events

Group circles:
  • Goal: Create a circle for your friends/email group
  • Precondition: 
    • Have an account, 
    • Have users emails/group
  • Postcondition: 
    • Have a group for quick inviting
  • Subtasks: 
    • Adding removing emails, 
    • Sending mails individually

TA Feedback.

As we discussed in our meeting, the project as it stands in this iteration is not a stretch. We discussed ways to improve that in our meeting, such as broadening the user population.

You don't seem to really get a good feel for what the tasks your users use to solve your problems, and instead you describe actions that your app will let users take. Don't forget that the next step is to make three separate designs - you shouldn't already have picked one. Think of task analysis as the analysis of tasks that need to be done to solve the problems.

You also don't address classes of users at all - these people aren't a complete set of people that are trying to solve these problems. You also only discuss how they'd feel about your app with users - go back and interview them about how they solve these problems in general. Please also remove the personally identifying information from your interview section.

I'd appreciate it if you made these changes, since we'll be working off this document for the whole rest of the project.

Revised User Analysis:

Person A

Amy is a female college student who regularly goes online to check her facebook and see what her friends are doing. She generally likes to throw events every weekend at her apartment with friends. Uses email and facebook events to schedule events. She makes these online events at around the middle of the week (about 3 days prior to the event.) Overall she always has intended people to invite. On rarer occasions she might meet someone new and invite them over. The people she invites might also have their friends come over, so sometimes there are more people that she has invited.

Problems

Rarely anyone ever confirms Amy's invites online. She doesn't know who is coming. The number often varies since sometimes people can't attend or friends of friends are invited. She usually has to call people the day of the event in order to get confirmations and a better number of who is attending.

Person B

Bonnie is a mom who has to do all of the scheduling for her young pre-teen kids. She rarely gets on the internet, but she does have a smart phone. Bonnie is not very tech savvy but her older teenage kids sometimes show her how to install apps for her phone. She keeps a schedule on a paper calendar and has to manually erase/update them for upcoming and changing events. These events can range from medical appointments to play dates with other kids.

Problems

Bonnie has difficulties keeping track of events for the kids since they are all written on paper. If this paper calendar gets lost, then she loses all of the events. Bonnie also realizes that she has to schedule events for her kids AND herself. If she decides to have another baby then she will have to schedule more and more. The paper can only hold so much. She also hates it when someone reschedules because she has to erase or scratch out previous events and make new ones. Sometimes she also forgets that her kid has a checkup with the dentist since she doesn't always look at the calendar.

Person C

Charlie is a course 14 tutor trying to create and maintain a schedule with initially a large number of openings. He is an MIT student and is very tech savvy. Charlie wants to limit individual tutorees for only one hour a day and make sure they don't take up any more time. His process for tutoring is leaving a blank paper with certain times that are blank for users to sign their name to take up a spot. Charlie wants to make sure that this signup process is first come first serve.

Problems

Charlie is an MIT student... meaning he doesn't have time to deal with rescheduling and has only certain times to tutor someone. Slots can change instantly and need to somehow update the prospective tutorees of new openings. People can also be devious (or try to maximize their utility of the tutoring system) and end up erasing names on the paper to fill theirs in. People can also just not end up showing to a time slot or won't notify Charlie that they can't attend.

Person D

Daniel is a big time executive in Bitdiddle Co. He travels from country to country, state to state, city to city frequently. He likes being organized because he knows that any slip up can be terrible for his company. He likes using mobile applications because he doesn't have time to use a laptop when he's on the road or the air. He frequently uses mobile apps for different airlines and constantly checks emails. He also uses his companies mobile calendar in order to work with scheduling.

Problems

Daniel has difficulty keeping up with changes in plans because their are so many other things going on at once. Some meetings end up getting postponed. This leads to events being pushed back repeatedly until a meeting is forced because it is the last possible time to meet. Daniel has troubles with getting the best user experience from the company mobile calendar since it was developed by two IT guys in the company. IT people aren't engineers. He needs to quickly make changes and find the next best times to reschedule.

Justifications:

Going Mobile: All of our classes can be benefited by some sort of notification system. We think that a mobile solution (text message, in-app push notification) can be more effective than an email. People tend to batch emails, making them less real-time and more prone to being lost or delayed. A mobile notification requires quick feedback from a user. This encourages users to have a more engaged interaction with the event.

Revised Tasks:

Create Event

Pre-Condition: Need to have an account;

Post-Condition: New event is created; Users need to be invited;

Subtasks: Specify range of acceptable times; Specify the expected duration of the event; 

Motivation: A common theme among our user classes is that scheduling events is a difficult problem. In order for our solution to be effective, it needs to allow users the ability to tell us when and what they wish to schedule.

Invite

Pre-condition: Need to have an event;

Post-condition: Notifications are sent;

Subtasks: Set notification reminder interval; Add people to the event; 

Motivation: Another common theme among our user classes is that coordinating a meeting time for a group of people is hard. Thus, mashcal needs to allow users to invite people to an event.

Respond

Pre-condition: Need to be invited to an event;

Post-condition: User has RSVPed;

Subtasks: Accept/Decline event; Choose from available time slots;

Motivation: The main problem we identified was how difficult it is to get confirmations from invitees (it is why we are going mobile). As such, we need to make it frictionless for invitees to accept/decline an event, and say what times are good for them.

  • No labels