You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

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:

Aftering 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:

l

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.

  • No labels