ChildFeed - GR3

Briefing

ChildFeed is a web app that allows daycare workers to share information about children under their care to the children’s parents in real time.

Using ChildFeed, daycare workers can notify parents of:

• when their child has been checked-in and checked-out of the daycare
• what their child ate that day and how much
• what general mood and energy level their child was in that day
• special events with custom text and attached photos

In addition to checking their feed, parents can also analyze daily information using customizable visual representations.

Note that ChildFeed is meant to be a one way communication system from the daycare workers to the parents. Also, ChildFeed is not designed to be used in cases of emergency.

In this scenario, you are Dan Donald a day care worker. We will be giving you a series of tasks that we would like you to try your best to accomplish using our prototype interface. As you attempt these tasks, we ask that you vocalize your thought process to the best of your ability, so that we can better understand what is clear and unclear in our design. Note that there are no wrong answers and that we just ask you to try your best at accomplishing the given tasks.

Thanks for your help and remember that you are free to leave the experiment at any time.

Scenario Tasks

Prototype Iteration

Initial Page changes  

- Changed names of the options  

We realized that the question "Who is here?" was a bit confusing for our users. We decided to change the names of all of the options to represent actions so that the users know exactly were to go when they need to accomplish a task.  

- Added large buttons in the middle of the page  

In the first version we weren't completely sure about what to put in the middle of the initial page. We decided to include 4 large buttons that do exactly the same thing as the options in the sidebar. We included expressive icons in the buttons that made it easier for first users to know what each option is about.  

- Included Report Lunch as one of the initial options  

In the first version, Lunch report was an option that appeared in a submenu when the user clicked in Daily Reports. The daycare worker is going to be logging information about the children's lunches fairly frequently and also at a different time than he is going to be filling daily reports. Therefore, as we had plenty of space and it made sense to separate them, we decided to make the Report Lunch a button on its own.

Changes to Check in/out Page

With version 1 there was room for some confusion between the actions of checking in and out. At first we were thinking of separating both actions and make them two completely separate menus. However, it could get confusing to the user because the check in and check out screens would be essentially identical but would do different things (could motivate modal errors).  We decided to go with the check in/out screen from the Visual and Simple design. As the daycare worker checkins children he is building a set of kids that are at daycare. The user takes advantage of that set for tasks like reporting lunch. 

Changes to Report Lunch page

The name of the page was changed to "Report Lunch" for clarity, and the structure of the interface was changed. Based on user feedback, it wasn't clear or intuitive how the different UI elements interacted, especially the meal entry portion of the interface and the child data entry sections. To remedy this problem, we opted to move the meal entry information into a sidebar and make the child data entry take the center stage in the pain part of the page.

We also modified the paradigm behind this portion of the interface, slightly. Instead of the lunch report feeling like a story that is "published", the lunch report now feels like a log, where you add information and submit it. Daycare workers can go back to the Report Lunches page at any time and edit the information entered if need be. As such, we eliminated the need for the checkboxes for the child tiles. This is a good change because we had problems with people knowing that they need to check or uncheck boxes when reporting lunch information for specific children.

Users were also confused by the fact that adding the first menu item will fill it by default to all child tiles, but not the second. Instead, we opted to make the meal sidebar not fill any information by default, and instead added a "Fill All" button next to each meal item.

Initial Prototype Observations

Our initial prototype was very successful. Not only did most users figure out ChildFeed's interface with minimal difficulty, but they provided very useful feedback which allowed us to make the design sleeker and cleaner. Some key observations which led to changes included:

• The 'add a meal' section was overlooked.When a user was tasked with reporting what a particular child ate, he looked first to enter information under the child's name (from the drop down menu in the child widget), rather than the 'add a meal' menu. Unfortunately, (in our first prototype) our interface did not allow for users to input a meal from the child widget.
• Some of the default setting were not intuitive/expected by the user. One user did not expect all of the children to be 'checked' by default when he wanted to log a lunch report about only one or two students.
• One user did not understand why a button called "Publish" was required to complete the "log lunch" function.
• "Who's Here?" label did not immediately translate to "Check in" for some users.
• Users wanted to see some icons or directions on the home screen.
• Users found the check in process very easy and intuitive.
• Users enjoyed publishing a story about a child.

In addition to allowing us to improve on our interface, the first round of user testing gave us a lot of positive feedback. Several called it "intuitive", and reported that a majority of the interface made sense. Most users thought it was a cool idea and rated our interface highly for learn-ability and efficiency. (We did not get any feedback about safety).

Second Protoype Observations

We were very pleased with the second round of user testing. Our second prototype allowed us to fix several of the complaints which users had with the first prototype. It also led to good discussion about various subtleties of how our product will function. Some of the important comments were:

• One user loved the  "Fill-all" option when adding a meal. He saw how this could greatly improve efficiency when logging lunch data for multiple children.
• One user was a little confused by the menu titles. He was not sure whether the "daily log" would allow him to publish a story or to input data about a child's lunch. 
• Users wanted to be able to see what their actions did. For example, after publishing a story, he wanted feedback from the application on what the parents actually saw.
• Sometimes users wanted to see a "close", "back", or "undo" button added to the menus.
• One user asked a good question, "If I fill all meals with Mac and Cheese, change a child's meal to chicken nuggets, can I undo the change somehow?". This led to a discussion about how undo should function on several of our menus.
• One user suggested making the "adding meal" option brighter, or having some other way of obtaining the user's attention.

Most of the users had positive things to say overall about their test of ChildFeed. One user said it was an "amazing paper prototype, with not too high and not too low fidelity". Most said that the general flow was smooth, and appreciated the overall consistency of menus in the product. Our group felt happy that we spent adequate time discussing various options for our interface design and for its testing.