GR1 - User and Task Analysis
User Analysis
We have identified two main user classes: students (both undergraduate and graduate) and faculty/staff. To explore our user base, we have interviewed two undergraduate students, one graduate student, and one staff member. Our interview process was conducted face to face, and users were asked a series of multiple choice and open-ended questions.
User Classes
Students
Undergraduate and graduate students at any given university.
Characteristics:
Male and Female
18-25 years old
Speak English
Computer literate
Are concerned about privacy
Needs:
Want to share summer plans with friends
Find others who have overlapping summer plans
View friends’ summer plans
Faculty and Staff:
University affiliates who can verify themselves in some manner.
Characteristics:
Male and female
22+ years old
Speak English
Computer literate
Work at a given university
Needs:
Want to plan summer events geared toward students
Want to view undergraduate/graduate summer plans
Personae **
User 1: Undergraduate Sophomore at MIT
John is a twenty-year-old college sophomore who is, at this point, unsure of his summer plans. He is studying Management Science (Course 15), and hopes to be working in New York or Boston this summer and/or next summer. He is from a secluded part of St. Louis, and enjoys the privacy of a humble Midwestern town. John has a passion for sports and music; in his free time, he enjoys playing basketball and guitar. As an MIT student, he is relatively technologically savvy, though has no sort of programming / software design experience. His main uses of his computer are browsing the Internet and word processing.
- Means of communication. This user mainly communicates with friends and acquaintances via text messaging or email. When making immediate plans with friends, he often calls them directly. He is not a huge fan of other social media outlets, but "would use something that's a completely new service, or if I was given some sort of incentive to sign up."
- Travel plans. John generally makes travel plans independently (i.e., without consulting friends) or with the aid of his parents. He says, "I wouldn't go out of my way to find someone else who was going to the same place, but if I did know of anyone who was, either specifically or through a mutual friend, then I would try to coordinate our travel plans." John is not aware of his friends' summer plans, though he and several of his friends are still in the process of making them.
- Information security. Internet security is something that John values; he shares his personal details (phone number, home address, etc.) with only his close friends. He wouldn't mind sharing some broader personal information, such as his email address or general summer plans, with the general MIT community. However, he feels strongly about keeping any personal information away from the reaches of the general public. Most of John's personal information on Facebook is kept private, and he is not a highly active Facebook user. He has also never used Twitter or other social media applications.
User 2: M.Eng. Student at MIT
Mark is a 22-year old student in his 5th year working on his M.Eng. project in course 6. He has an extremely active social life and besides going out multiple nights a week with friends, he helps run a thriving music blog. Mark tends to spend his summers traveling to different cities in the U.S. to visit friends he’s made over the years at different colleges.
- Means of communication: Mark relies heavily on his phone and email to keep in touch with those close to him. Although he has Facebook account, “he’s not very into it” and “doesn’t check it too regularly.” If our service was provided as a standalone website, Mark wouldn’t sign up because he doesn’t want another account/site that he wouldn’t check. He also was very clear that he didn’t want a service spamming his email with periodic updates, even if they were relevant to him. If anything, he wouldn’t mind some form of integration with another service which would save him time in signing up and checking for updates.
- Travel plans: Mark doesn’t have a consistent way to inform his friends of his summer travel plans. While Mark makes his plans independently, he expressed interest in using such a service because he believes it’s extremely important to know at least a few people no matter where you are.
- Information security: Mark keeps most of his personal information private on Facebook and shared parallel concerns about who would be able to see his summer travel plans. He says that “I would only want my friends to be able to see them” but wouldn’t mind if that group were defined as his Facebook friends. In that light, he stressed some form of Facebook integration that would allow access to users’ Facebook friends list.
User 3: Undergraduate Junior at MIT
Denise is a 20-year old MIT junior majoring in Chemical Engineering. She enjoys meeting new people and generally having a good time.
- Means of Communication: Denise communicates via texting, GChat, and Facebook. She wants a tool to communicate easily with a group of people. She doesn't like to mass text and hates long email chains. She recalls that during her freshman summer, one of her friends had created a summer mailing list to organize trips, plan parties, and generally keep in contact with their group of friends While she thought the mailing list was a good idea, she remembers several problems that arose. For example, people in the Boston area were accidentally left out of the list at first. Also, event planning sometimes resulted in very long email chains. She emphasized that registering for a new account would deter her from using a new service. Finding and "friending" people is also a deterrence, because Facebook already does that.
- Travel Plans: Denise usually stays at MIT to UROP. She has her living arrangements settled but is looking for an easy means of meeting and contacting other people who are also at MIT over the summer.
- Information Security: Privacy is very important to Denise. She wants to meet other MIT students, and maybe friends of friends, but not random people. She doesn't want her information to be readily available to just anyone on the street. She also wants to be able to filter the people she meets by criteria such as living groups.
User 4: Staff in the MIT Alumni Association
Emily is in her forties and works in the MIT Alumni Association. Her job involves expanding the presence of MIT's alumni network.
- Means of Communication: Emily communicates with MIT alumni and current MIT students mostly via email. She notes that her messages are often times ignored, sometimes because her emails are too long, and sometimes because her target audience is not specific enough. When asked whether she would use a tool that can generate a list of MIT affiliates organized by geographic proximity, she said yes. She indicates that she can organize events for alumni and current students located in a certain geographic area. She emphasized that the tool must be able to send succinct messages and target specific groups. That is, it must have filtering capabilities.
- Information Security: For Emily, privacy is very important. She wants to organize events only for MIT affiliates. Having a system where log-in information is verified via certificates would be very useful.
** Users' names changed for privacy
Task Analysis
Below we have identified a series of tasks a user might perform on the TravelTech system. These tasks range from one-time profile creation to searching for other users in a similar geographic location.
1. Creating a Travel Group
Goal: Specify or search for a group of people with similar travel destinations and times.
Preconditions: User must have created an account, be logged in, and have inputted his/her own travel information and times.
Subtasks:
- Search and filter people by living groups, interests, major, in addition to their traveling destination and time.
- Identify individuals with similar traveling plans via a map of the world.
Constraints: None.
Frequency of Use: Every time that the wants to plan a new trip, one to four times a year.
Exceptions:
- User can filter incorrectly on a map due to inadequate zooming features.
- User may create a group and want to change aspects of it later.
2. Messaging a Travel Group
Goal: Send a short message to a group of users in a Travel Group.
Preconditions: User must be have created an account, be logged in, and have an existing Travel Group.
Subtasks:
- Create and edit a plain text message.
- Optionally select subgroup of the Travel Group to contact.
- Submit and send text.
Constraints: None.
Frequency of Use: Up to multiple times per day.
Exceptions:
- User may send it to the wrong recipients.
3. Inputting Summer Plans
Goal: User enters his/her general summer plans into the web interface, which will allow other users in the group to view these plans.
Preconditions: The user must have created an account and logged in. Before completing this task, the user needs to know his/her summer plans. This task should only need to be performed once or a few times (if the user's summer plans change) for one particular season, so efficiency is not of utmost importance (but still a concern to be kept in mind).
Subtasks:
- Access profile page
- Enter and save changes
Exceptions:
- The user could mistakenly enter incorrect information, so he/she should be able to easily change or undo these actions.
- A lost network connection.
4. Searching for Roommates
Goal: On the bulletin page, users can advertise within the group for a roommate.
_Preconditions:_The user must have created an account and logged in. He/she would also need to know specific details regarding what he/she is advertising or looking for. This task could be performed often (even multiple times in one session) and by many users, so efficiency and easy learnability are essential.
Subtasks:
- Access bulletin from any page
- Posting to bulletin
- Viewing previous postings
- Reply to previous postings
Exceptions:
- As with many other operations, the user could enter incorrect information, so an undo/edit operation would be necessary.
- A user posts an advertisement on the bulletin that is claimed by another user soon thereafter, but if the advertisement is not taken down, then other users may still think that the item is available.
5. Profile to Publish Information
Goal: The goal is for the user to submit or change their personal information displayed on his/her profile and maintained in the database.
Preconditions: The user must have created an account and be logged in.
Subtasks:
- Access profile from any page
- Edit and save changes
Exceptions:
- If the user enters the wrong information, the user can edit again and redo the process.
6. Find Nearby Students
Goal: The goal is for the user to be able to view an interactive map that displays locations of other students
Preconditions: The user must be have created an account and be logged in.
Subtasks:
- Access map from any page, click and drag the mouse / scroll wheel to move the map and zoom, respectively.
- Different users travel plans will be displayed on the map.
Exceptions:
- If no other users have inputted travel plans, the user may think that the feature is broken.
7. Searching for Schedule Overlap
Goal: The goal is for the user to be able to find who has overlap with his/her schedule and where/when that overlap is
Preconditions: The user must be have created an account and be logged in, and have previously inputted summer plans.
2 Comments
Sacha Zyto
The problem statement and scenarios 1 and 2 are solid, but could be generalized to many different institutions besides MIT.
Example user needs are too diverse: You run the risk of either re-implementing a forum (which isn't novel) or implementing a several UIs, each one being best suited for the corresponding task (too big for a term project). You should focus on a subset of these and build a UI that solves that subproblem well.
Task analysis:
1. "Creating a Profile and Joining a Network" isn't a high level (or goal-oriented) task: it's a precondition for other task. (think of it as: User A isn't going to use TravelTech in order to create a profile and join a network, rather to find nearby students for instance.
7. "Viewing the Map" isn't a task from a user centered perspective: it's just a means to carry out a particular task (ex: find nearby students).
There's too much focus on implementation details: "Certificates", "kerberos" etc... At this stage of planning for your project, you want to keep your options open. Not doing so adds unnecessary constraints to your projects and might also prevent you from seeing some problems. For instance, using the MIT example: what if your user doesn't have a MIT account yet (you mentioned throwing a welcome party for newly admitted students).
Sacha Zyto
Comments on the new version: