Paper Prototyping

Prototype Photos

Prototype 1

Prototype 2   

Briefing

Users were shown the following video prior to completing their tasks:

https://www.youtube.com/watch?v=9YoNIife2OM

Scenario Tasks

1. Contact Sarah's mom to schedule a meeting time to talk. You are free Mondays and Fridays from 3pm to 6pm

2. Share Sara's grade for the last math test with her mom.

3. Remind your entire class' families they have a math test again this Friday and that they should review multiplication.

Observations

Phase 1:

After testing our initial paper prototype with three users, we learned a lot about how new users approach using our system with little to zero knowledge of how it works. Our testing provided valuable insight, making many usability issues clear as well as confirm some of our assumptions about how users think and feel about CheckMark.

The All tab confused users: The users tried to select the all tab multiple times, not knowing what to expect and what often appeared confused them. Since it provides no additional functionality (it groups views), we learned that having a summary view is extremely confusing when its functionality isn’t well defined.

The context of who you were messaging often eluded users: One user went through the entire first task (scheduling an event on the calendar) without noticing that he was scheduling an event with the entire class instead of just Sarah. Once recognizing how to use the person/group selection toggle boxes, most users had little trouble selecting who they wanted. However, every user struggled realizing the context of who they were interacting with and we learned to provide more affordances to make the context extremely clear.

How to schedule an event confused users: Many users were confused about the purpose of the calendar functionality. Specifically, we asked them to schedule an event on Friday, given that they were available from 3pm-6pm. All three users were confused as to whether that means creating an event from 3pm-6pm or messaging the parent about their availability. We learned that even though multiple ways to accomplish the same task might be useful, it also might result in the user getting stuck when they are not clear on what they need to do.

Users accomplish the messaging task without trouble: All three users despite usability issues in other tasks, managed to complete the messaging task easily and efficiency. We learned that using models from existing and popular applications allows us to significantly reduce the learning curve.

Phase 2:

After incorporating the user feedback we received during testing with our initial prototype, we tried to simplify our design by reevaluating what problems our interface really aimed to address and eliminate what got in the way from users accomplishing their goals with ease. Our feedback from users on our second design revolved around three major areas for improvement.

Displaying contacts needs to be clearly and logically organized: Most of our users caught onto how we organized and displayed contacts by the end of completing their scenario tasks. However, because CheckMark revolves around improving communication, being able to identify and select contacts for a task needs to be extremely clear for users, especially because many correspondences involve sensitive and/or personal information. In one case, a user sent an email saying that their student failed their exam to the entire class when it should have been sent to only that student's parent. Although our prototype indicated the selected contact by highlighting it on a left sidebar and displaying their contact "bio" above the content pane, we observed that these choices of indicating which contacts were selected were not clearly verifiable by users. One user commented that he thought that "Class" was simply the name of another contact and not group of contacts because it was spaced and formatted exactly the same as the other contacts in the sidebar -- the only difference was that it was at the top of the list. Additionally, another user commented that his eyes were not drawn to pay any attention to outside of the content pane, which was were we were displaying contact selection in our prototype. Therefore, we realized that we should place important information such as this inside of the content pane and we need to focus on visually differentiating between individual contacts and groups.

Users need feedback on their actions throughout the experience: Many users went through additional steps to verify that the messages and grade reports were in fact shared after sending them to parents, which cut down on their efficiency. For example, one user went back to the content stream a total of three times to verify that each of his correspondences showed up. Additionally, many verbally indicated that they were unsure of whether or not their intended action had been accomplished. One user explicitly said in his commentary that he wanted more feedback, which we observed to be an opportunity to solve other issues we observed (i.e.: sending information to the wrong parent/entire class). Providing feedback throughout the process in addition to confirmations is an area that our next design will incorporate to hopefully alleviate some of these issues.

Grade sharing should provide information for both the parents & teachers: Although we originally thought that grade sharing would provide a one-way communication mechanism for teachers to give parents information about their students' performance, we received some feedback that our interface for grade sharing was ambiguous. More specifically, a user commented that although for a student, we provided a neat table displaying each assignment name and their score on it as a percentage, they had no idea what those percentages meant because they were not in relation to anything. For example, if a student scores an 80%, it would be valuable to know if the class average was 90% vs. 70%. Additionally, it would be valuable to know the trends of a student's grades over time and be able to share this kind of data with parents. Therefore, we were enlightened by these observations to expand the way we approached grade sharing: We want to provide useful, personalized information to both parents and teachers and not just support the flow of data from teacher to parent without context.

Prototype Iteration

Changes between prototypes

1. The All selection was unclear. We replaced the word "All" with "Class".

2. We removed the scheduler and all scheduling should be done through the calendar. Parents can only view the calendar, and cannot add new events. To coordinate on availability, teachers and parents should just communicate through messages.

3. So users would understand which context they are in (which student's parent they are communicating with), we introduced a small bio of the student at the top of the page. This bio included the student's name, picture, and grade in the class.

4. To make the purpose of the side vertical navigation clearer, we added profile photos to the left of each student's name.

5. We decided that dividing the main container into an view box and an edit box confused users. Instead, we scrapped the edit box for the calendar and grades tab and used pop ups to add content to these tabs.

Planned Changes

1. The interface needs more feedback about the context closer to the focus points on screen. For instance, at the top of the view box in the Messages tab, we plan to include a line of text stating "Viewing messages from Brenda, Tammy, and ..." for each context.

2. The class selector still isn't perfectly clear. We plan to put a small amount of spacing between it and the students and to increase it's height for more learnability. We think this will continue to reduce the amount of lapses users experience.