...
Issue | Page | Type | Severity | Possible Solution |
|---|---|---|---|---|
The lunch sidebar was overlooked when trying to report a lunch. | Report Lunch | Learnability | Minor | We could add tool tips that remind the user to add a meal if they try changing the meal first. We are not too concerned about this, because once the user learns about the sidebar, it becomes obvious to learn how to use. |
The labels "Checked In" and "Checked Out" were confusing to some people. They were mistaken for actions instead of states. | Check In/Out | Learnability | Minor | We could rewrite the labels to be "In" and "Out" to get rid of the connotation with action. |
It wasn't entirely clear that the "Who?" input was tokenized rather than just a normal text field. When the users typed too fast, they can miss the search results causing their entry to not be inputted. | Share a Story | Learnability | Minor | Again, this would cease to be a problem as soon as the user is shown this fact. However, a tooltip could pop up to aid users if the user is unable to successfully add a child. Also, we could make the search results pop up faster. |
Fields like Energy, Potty, and Mood are hard to quantify. | Daily Log | Affordance | Minor | We could make the options for Potty, include a quantified number of times. We could provide extra information on how to quantify Energy and Mood in a tooltip or a help menu. This information could include particular criteria to make quantification easier. |
The "+" in the lunch sidebar was misleading and gives the accordance of the affordance of a link or dropdown menu. | Report Lunch | Affordability | Cosmetic | Remove it. Possibly have a dropdown menu of previously used lunches. |
...
Another lesson from class that became clear to us we learned over the course of the iterative design , was the difficulty of predicting how users would interact with our designproduct. There were many times where we would take for granted that a particular feature was simple and easy to use, but user testing revealed otherwise. For example, we thought that users would easily understand how to use our Report Lunch feature without any assistance, but a number of users needed to be shown how to use it.
...
One risk assessment that we made a mistake on, was the risk of not finding daycare workers that would be willing to test our product. We assumed that since user testing only takes 5-10 minutes per user and since ChildFeed is directly related to their profession that daycare workers would be more than just willing to participate in our user testing because ChildFeed is directly related to their profession and requires minimal time to test. Thus, we waited until we were done implementing ChildFeed , before we emailed to email the daycare workers in the TCC located in the Stata Center. We thought that there would be more than enough daycare workers who would be excited to test our project, but it turned out that we were wrong and that Unfortunately, they did not show nearly as much enthusiasm as we expected. Had we known that there might be difficulty in getting volunteers for our user testing among daycare workers in the TCC, we would have started the process of finding test users among the daycare worker population earlier. However, we believe that we were still able to more-or-less accurately evaluate our project with a less representative user population. We believe that our choice of testing ChildFeed on users who had experience taking care of young children in childcare gave us a good sense of how well daycare workers would have been able to use our interface.