User Analysis

We’ve identified two main classes of users for an MIT-based event-browsing application. We’ll hereafter refer to these classes as “publishers” and “readers”, and further subdivide readers into “searchers,” and “browsers.” (Users may belong to more than one class.) These classes are described below, and are further illustrated by three example personas that we’ve constructed using data gathered from interviews.

Publishers

Harry is the publicity officer of the International Student Association (ISA). When the ISA holds events or parties, he sends invitations out to all the dorm lists, making sure to BCC them to avoid starting a flame war, and then publishes the invitations to events.mit.edu. He does this a few times a semester, or whenever the ISA holds public events.

From this example, we can see that publishers:

  • are ordinary MIT students or MIT-affiliated personnel,
  • want to publicize an event to the general MIT student body,
  • have a working knowledge of the internet and e-mail,
  • currently use mailing lists to reach their audience, as well as events.mit.edu,
  • publish events at least a few times a semester, depending on how often their organization holds public events.
Readers
Searchers

Sam is a Course 2 senior searching for work. He’s looking for company info sessions, especially those with consulting internship positions, but the Course 2 mailing list doesn’t have many of those. He wishes there were a central location he could search for specific types of events from, whether they be job talks, free food, or various athletic events. He also dislikes manually tracking events by typing them into Google Calendar, and would like to have an easier way of saving events for future reference. Furthermore, he wants to be able to quickly see which events he has scheduled while on the go.

Browsers

Mary is a Course 6 sophomore who would like to be able to quickly find fun events to attend in her free time. She wants a better way to browse events happening on campus than just reading her e-mail, because there’s too many mailing lists for her to keep track of, and most of their messages are about things she doesn’t care about. She also thinks it’d be nice to have an easier way of subscribing to events in certain categories, like music performances, without bothering with so many different groups’ mailing lists. She didn’t know events.mit.edu existed.

From these examples, we can determine that readers in general:

  • are MIT students, or people interested in MIT-based events,
  • are at least functionally familiar with internet-based applications, such as e-mail and web searching,
  • feel the current system of notifying people of events is too complex or insufficient,
  • want to be able to quickly find events to attend,
  • would like to be able to track events they’re interested in, whether or not they attend.

More specifically, searchers:

  • know specifically which types of events they want to find,

While browsers:

  • have more general preferences for events they’re interested in.

Task Analysis

From the above user types, we’ve determined four major tasks and one minor possible task for users of our application. They are:

  • publishing events
  • searching for events
  • saving/scheduling events
  • reviewing scheduled events
  • sharing events
Publishing

Goal: The user wants to publicize an event to an MIT audience.

Preconditions: The user knows the event’s time and location, and has a general description of the purpose of the event.

Subtasks:

  • The user describes the event’s characteristics.
  • The user specifies the preferred audience the event is targeted towards.

Result: Event is published and viewable by application users.

Searching

Goal: The user wishes to find an event or events to attend, based on the user’s own interests or needs at some point in time.

Preconditions: The user knows the characteristics of a desired event, even if it’s as generic as “event should be fun.”

Subtasks:

  • The user searches for specific events.
  • The user browses a list of events.
  • The user limits search space by specifying characteristics of the desired event, such as time, location, subject matter, etc.
  • The user views an event.

Result: The user is able to see events that they would like to attend.

Saving/Scheduling

Goal: The user wants to be able to save interesting events that occur at a later date, and easily access their information in the future.

Precondition: The user must be able to identify him- or herself in order to access unique personal stored information, such as saved events.

Subtasks:

  • The user selects an event to save for future reference.

Result: The event is saved somewhere that the user can easily access.

Reviewing

Goal: The user wants to view information about the events he or she thought were interesting enough to specifically save.

Precondition: The user must be personally identifiable, and also have saved events.

Subtasks:

  • The user views events they saved earlier.
  • The user organizes events according to some personal preference.

Result: The user can access their saved events.

Sharing

Goal: The user wants to let other people, such as friends, know about an event they plan to attend or are interested in.

Precondition: The user has an event in mind.

Subtasks:

  • The user selects a friend or friends to send the event information to.
  • The user sends the event information.

Post-Condition: The user’s friends now have access to the event’s information.

  • No labels

1 Comment

  1. Sacha Zyto

    Project looks promising but scope is probably too large for a term project: You should try to focus on a specific problem (and specific user categories), in order to avoid the pitfall of ending up designing a standard database driven app. For example, we mentioned in GR1 meetings that you could focus on the problem of finding parties based on your preference and availabilities, or hanging out w/ friends,  or organizing board games nights, or whatever other problem for which you think there's a current problem that could solved by using a novel UI design focused on the specific needs of your user population.

    On the other hand, the project doesn't seem MIT specific: similar observations could be probably be true in any large university: It's important that you try not think not in terms of "MIT" in order to put you in the state of mind that "you are not the user". If it helps to use a name for the university, don't use MIT.

    As we mentioned in the meeting, don't forget to consider the opportunistic vs. non-opportunistic dimensions, and the consequences in terms of UI design: Will most people actively your app, or should you rather integrate it with something else they can see when they have 10 seconds (just ike posters).In the latter case, you might want to integrate your app within an existing information ecosystem.