...
# | Task |
|---|---|
Task 1 | Check-in Chuck, Derp, and Herp. |
Task 2 | Notify Chuck's parents that Chuck got covered in paint today and please include a photo of this adorable event. |
Task 3 | Log that everyone except Derpina had macaroni and cheese for lunch. Derpina had tomato soup. Log that everyone ate a healthy amount except for Herp, who ate so much he threw up. |
...
Prototype
...
Photos go here.
Observations
Colin's text goes here
Prototype Iteration
Initial Page changes
- Changed names of the 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.
Before | After |
|---|---|
| |
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.
Before | After |
|---|---|
| |
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.
...
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.
Photos go here.
Iteration Observations
.
Before | After |
|---|---|
| |
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. Colin's text goes here