• Created by Unknown User (mattocks@mit.edu), last modified by Unknown User (pwoods@mit.edu) on May 17, 2012 22:30

Interviews

Interviewed three people:

  • 40 y/o male, Software Engineering Manager at a local company
    • Often has to answer the same questions over and over again about when deadlines are.
    • Spends a large amount of time reminding people about deadlines
    • Currently uses Jira to manage tasks, but people typically ignore the due date feature because it is extremely complicated
  • 25 y/o male, Software engineer at a local company
    • Uses a todo list manager and calendar notifications to manage tasks
    • Difficult to work in a team with his current set up
    • Gets notified far too often about impeding deadlines 
  • 20 y/o female, Simmons Student
    • Uses a written planner to keep track of due dates
    • Has lost her planner and then struggled to get organized again
    • When she wants to remind friends about events she usually sends out multiple mass texts

Conclusions

From these interviews we conclude that almost everyone have some non-ideal method of keeping track of their upcoming deadlines. Almost everyone seems to struggle with communicating deadlines with other people.

Proposal

A collaborative application that allows users to create countdown timers and share them with relevant team members. Also users will be able to set up automated notifications to track their deadlines.

User Analysis

Andy the team manager
Andy is the team leader of a project in his company. He has a lot of experience managing his team. One of his main jobs is to ensure that deadlines for projects are met. He often reminds his team members via email of deadlines as they approach. However, these manual actions sometimes are time-consuming for Andy.

Bill the team member
Bill is a team member of a project. While he is generally diligent about keeping track of his own tasks and deadlines in a personal planner, he finds it cumbersome when he receives constant notifications. He wants to find a more efficient way to see his specific deadlines along with those of his teammates. He might also want to set private deadlines of his own for a given project.

Cynthia the casual user
Cynthia is a user who does not use TeamTimer quite as intensely as people on project teams. She isn't the most organized person in the world either. She wants to create countdowns to events, such as birthdays of close friends and family. She wants to be notified of events efficiently. She also would like to have the option share timers with a specified group of people, or share them publicly.

Task Analysis

  1. Creating a timer.
    1. It is extremely important that a user can quickly and easily create a timer.
  2. Viewing personal timers
    1. A user should be able to browse timers that they created.
    1. A user should be able to view specific details about a particular timer.
  2. Sharing a timer with others
    1. A user should be able to share timers with others, so it must be easy to invite other people to use a timer.
  3. Finding timers that are relevant to you
    1. A user should also be able to search for timers created by others. A notion of public and private timers should be introduced.

TA Feedback.

This project, as it stands, isn't a stretch. There are a few ways you can handle this - by broadening the user population, or making it mobile (for a reason). We'll discuss this further in person.

You don't actually discuss classes of users, just specific characteristics. Try to think about who your users are more holistically - thinking about them as characteristics first is backwards.

Your list of tasks seems incomplete. For instance, what about changing a timer that is shared with you?

You also 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.

Please also be careful about gender generalizations when talking about user personae.

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

  • No labels