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

Compare with Current View Page History

« Previous Version 23 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

Iteration between prototypes

These are the changes we made after the analyzing the feedback we got on the first prototype:

- We got rid of the “All” tab, which selects all displays the entire stream, because it did not enhance the user experience.

- We decided that the calendar would only be modifiable by the teachers, who would use it post exams, events, etc. Parents would only be able to view it.

- To make it more clear to the user what student's profile he is currently on, we decided we would introduce a small bio of the student at the top of the page, which would include the student's name, his parent's name, and his average grade.

- In order to make it more clear to the teacher that the left menu contains the student's names, we added icons with the student's pictures beside each name.

- Calendar will only be modifiable by teachers, who will just use it to post exams, events, etc. Parents will only be able to view it.

- We no longer divided the main container into an "editing box" and a "view box", as it became confusing especially in the calendar view, where users are used to seeing a pop-up when they edit an entry.

- We changed the button named "All", which made reference to all the class, to "Class".

Planned Iteration

These are the the changes we are going to make next:

- Separate the class and make it bigger

- SOMETHING ABOUT GRADES

  • No labels