Briefing:
Welcome to menu.io! We are innovating in the domain of Restaurants, specifically menus, trying to expand on the lack of interactivity and dynamic content. We’ll be taking you through one use scenario of our app’s basic functionality. Remember that this test isn’t testing you, the user, but rather the interface and its usability. Feel free to think out loud so we know how you feel about each element of the interface. You’ll have the opportunity to ask questions and give us higher-level feedback when we’re done. Thanks!
Scenario:
We gave our users tasks similar to those given in our scenario from GR2.
Task 1: You have just arrived at your favorite restaurant, Flour Cafe, and want to see the menu. Open up the app and select Flour Cafe.
Task 2: You want to eat a sandwich. Open up the menu that only shows sandwich items.
Task 3: Apply filters to the menu so that you only see vegetarian and gluten-free items.
Task 4: You realize that you are not actually interested in gluten-free items. Remove the gluten-free filter.
Task 5: Find the portabello mushroom sandwich and reading it’s ingredients.
Prototype Iteration
For our first iteration, we used our riskiest prototype. We felt that the scroll wheel would be a fun feature for users to play with and we liked the fact that it would be relatively novel to our user interface. We also liked the idea of a metaphor to the Lazy Susan on a real dinner table. We knew it was a risk, but we wanted to see whether users would be able to figure it out easily. However, each user during our first iteration told us the same thing: the scroll wheel was confusing. The first said that it was hard to tell that it was a scroll wheel at all, and we figured that was because of the low fidelity of our paper prototype. We tried adding in an arrow at the top of the wheel to indicate that it was meant to scroll. Even though this helped users recognize it, they mentioned that it would be frustrating to use on a tiny cell phone because the border icons would be crowded. We ultimately decided that it wasn’t worth making a higher fidelity (i.e. computer) prototype to see whether users could recognize the scroll wheel feature.
Because users liked having the ability to see a larger view of their dishes while still being able to scroll through the dishes, for our second iteration, we moved to the grid-display design. Even within this design, we made some changes. Users found it confusing that the large display reflected the middle icon in the scroll wheel, so we added an bubble and arrow from the middle icon to better show this. After this, the grid-display design was very well-received.
For our first prototype, we used drag-and-drop tags to filter the menu. We felt this was also a risk because it isn’t widely used by many interfaces. Unlike the scroll wheel, however, users appreciated this feature. We made several changes throughout our testing. In our first iteration, we had the tags jump from one part of the screen to another when the user clicked or dragged the tag. Most users just clicked the tags; no one whether to drag it or not. We realized that we could better utilize our screen space since users didn’t expect the tags to move. For our second iteration, we tried leaving the tags in the same spot but just adding an x next to the tags in use, and telling the users that the tags changed color. Users found this confusing, so we decided that it would be better to have the tags move to the top of the screen. We also originally had a tooltip to inform the user that the tags were for filtering, but users in the first iteration told us that this was pretty intuitive, so we removed the tooltip for the second iteration.
The GPS feature was well received by every user. We did one trial with a user where the GPS “glitched” and the user was forced to enter their restaurant into the keypad. This too was received well. We didn’t feel a need to change the GPS feature from one iteration to the next.
Observations (First iteration)
User 1
User 2
User 3
Observations (Second iteration)
User 1
User 2
User 3