Using current calendaring solutions, it is often difficult to view others' or an aggregate of schedules. Our system hopes to simplify scheduling large numbers of people, minimize duplication of effort, and track academic and life tasks. The system is a web interface that has three main components: groups, tasks, and the calendar. Groups are any collection of people the user associates with - classes, project teams, friends, etc. Using these groups, our system allows people to schedule and contact their groups with greater ease and efficiency by providing shortcuts for these common tasks. Furthermore, the system provides a centralized, accessible location for users to store and manage their tasks. Additionally, the system allows users to "tie" events, tasks, and groups together. Any object (group, event or task) can be linked to another, providing a visual cue to illustrate connections between the various objects.
The purpose of our user test is to establish the layout of our final system, identify problem areas within our design and to better understand our users' mental models.
The above image was taken after our first interview. It shows how the first interviewee choose to rearrange the components.
The above images were taken after the second interview. You can see that the layout has changed substantially and modifications were made to the interface.A list of daily events now appears in pink in the upper left hand corner. It was done on a sticky note to represent the user's abilty to hide it if desired. Also a blue sticky note with larger forward and backwards buttons was added, the initial forward and backward buttons were not visually apparent enough.
The images above were taken after our third interview. Certain links and buttons were made clearer to allow the tester to know they were available. The Day, Week, and Month view buttons were moved to the center top of the calendar and made into distinct buttons. As soon as this was done the user immediately started to use these options. Another large change was made to the "add new event" toolbar. The user could now edit the time, date, and notes of the event in the toolbar. The tester immediately expressed contentment with this addition.
We chose three people to interview during this phase. While all were college students who would likely be using the system, some were power users of current calendaring solutions (e.g. Microsoft Outlook) while others currently used no calendaring solution at all. We are interested in this range of demographics because we want all users to be able to understand and use the system effectively, regardless of prior experience. Some of those who participated had been interviewed in previous phases, but not all of them had. We would have liked to interview a few more users, but were limited due to time constraints. We would have especially liked to hear from users who did came from a calendaring solution background other than Microsoft Outlook. Despite this, we still feel we learned about the response to our design from our particpants.
During the interview we selected tasks from the interview script and asked the participant to try and complete them. Some examples of what tasks we asked users to perform and what we looked for follow.
We introduced ourselves, explained the project, and obtained consent from the users. We then demonstrated the concept of “playing computer” to the users in order to make them feel more comfortable. Following that, we asked the users to complete several common tasks with our prototype, according to our script, during which we observed and took notes on their interactions. Interview sessions took no more than an hour each to conduct. After performing the task scenarios, we asked users to give us general feedback regarding the use of our system. This included specific layout issues, as well as features they would have preferred seeing and points in our system where we failed to communicate how our interface operated.
We are most interested in how users interact with our system. While it resembles many calendaring applications, we have implemented several innovative concepts and improve upon the collaborative aspect lacking in other implementations. Because it resembles current calendar software, we want to see if users can still operate our software in the way they are used to, but also take advantage of our new features. Of course, we are also interested in where our software fails to provide affordances for users and where we generate cognitive friction in user interaction. Anywhere users try to do something but are unable to or presented with difficulty in meeting their goals, we have made an error in our design.
In general, users found that our system was usable, although they missed certain features. While this is our fault for not presenting some of our unique features clearly enough, we believe that some of the problems were a result of the paper prototype's inability to allow the user to fully interact with our demonstration. However, users did invent several new ways to use our system. We told users that everything was drag-and-droppable as well as clickable, and they invented several new uses for us. For example, one user clicked the 'schedule event' button at the top of the page, input the name and time, and proceeded to drag the dialog box onto his schedule where he wanted to schedule it. Furthermore, users never really discovered the 'tie' system. Even after we told them about it, while they found it “cool”, no one seemed to really feel the need to use it.
Specific issues our interviews revealed follow.We learned a great deal about how users perceived various details of our design (addressed above in the results section). The point of conducting lo-fidelity interviews is to gauge how users respond and understand facets of the interface that we as designers believe to be intuitive or self-explanatory. From our results, we know that users can navigate and use our system, but often don't take the "quickest" route because we have not made these features clear enough to them. This is the pitfall of having a system that is similar to an existing one that users have prior experience with.
It is difficult to “advertise” new and (what we consider) useful features to users in a system that resembles existing solutions. The similarity between our system and existing ones did not create any major errors in usability, and in fact allowed users to perform actions they were used to in their previous systems. Additionally, users had varying opinions on how the system should perform when entering data. Some wanted the events to immediately become part of their schedule when they finished editing the information while others wanted an "OK" button to actively apply the changes.
It is extremely apparent that users have significant psychological momentum with regard to their prior experiences with calendaring software. Because of this, they often are forced into thinking within the constraints of their prior experience. This is both a blessing and a curse - it allows them to interact with our software in ways they are used to, and when we respond in the same manner, they understand what is occuring. However, it prevents users from exploring new features we are trying to offer in the interface since they always operate in the method they are comfortable with.
There needs to be a lot cleaner interface so that users understand where to access basic features such as switching between views. Many people requested preferences or options so they could customize their interface (how many days in a work week, how fast tasks expire after completion, color coding, etc), so this will probably be implemented. However, we want the system to work immediately for any user, so we must continue improving the visual cues and affordances for features we want users to understand and use.
Because users did not access every part of the site when prompted with a task, we did not get to judge the effectiveness of certain parts of our design. For example, the tie system was not fully evaluated because users didn't know it was an option. When shown that it was a capability, they didn't have adequate time to fully examine the system and whether or not they would use it. Our first interview focused on where the user would place common items such as the calendar and tasks, and therefore did not allow for as much room for error as our later interviews. Because we didn't have as many interviews as we would have liked, we feel that the evaluation process couldn't tell us exactly what changes we needed to make regarding certain elements of the design. For example, we realized the need for users to be able to email individuals and schedule meetings with users not in groups, but we haven't established exactly what the best way of doing this is. Obviously, the next phase will allow us to refine this design even further.
Some notes from our users' interactions are available as a PDF.