...
- Major: "Problem due to invalid search results" alert pops up at home page
- Good: User noticed right away from the home page how many foods she had, and how much she spent on her budget
- Good: Used food tab to navigate to food page.
- Good: On budget page, it was obvious to her that she'd spent too much already.
- Good: Began using arrows to change budget, but realized after going up 1 or 2 that she should type it in.
- Good: Noticed right away how to edit purchase, edited, and clicked out of screen with no problem
- Good: Understood icons on add foods page with no instruction
- Major: Still need to refresh recipes page
- Good: Thought recipes pages was cool
- Good: At the end, asked if it was going to be up for real, and said that it was very intuitive and she would use it
Reflection
We Throughout the semester, we learned that the iterative design process is very useful. Every step along the way (paper prototype, computer prototype), we learned about things we needed to change before actually spending lots of time implementing them. One thing we could have done differently is to have shifted some work from our implementation to our computer prototype. This would not only have spread our work out more between the two stages, it would have helped us to get more useful feedback earlier on. Our computer prototype was essentially the same as our paper prototype, so the feedback we got was similar.
...
The paper prototype test we did in the classroom setting were useful, but only touched on the more important features due to time. When creating the computer implementation, we realized that we weren't sure how to sort/filter food on the food page because it hadn't been tested. Sorting/filtering also wasn't tested much on the computer prototype because of it's high-fidelity nature. If we were to do this again, we would do a second paper prototype that was longer and covered these tasks. These tests would also have included more realist sized sets of food items. We often tested with 5-10 items, while sets of 20-40 would also be common and would bring up new problems in usability.
Initially, we worried a lot about the recipe component to our site. We didn't know was external databases existed and to what degree we could specify queries to such sites. This was a somewhat risky component, but also made our site unique, so we pushed forward. This was the correct choice. While it took a lot of tinkering, our recipe page is elegant and functions handsomely. Selecting milk and asparagus brings up soup recipes, and even returns nothing when those two ingredients are selected with the no dairy option.
Due to our recipe stuggles early on, we didn't focus as much on food item entry, when in fact is somewhat risky too. A tedious entry process would keep people from using the site. In addition, a user's reaction to entering 10+ foods is very different that that when entering 3, like in our tests. We simplified the food entry scenario, leading to an inappropriate risk assessment.