...
- The "Read something interesting" task , initially confused some users. some users didn't realize the first task was asking them to try to scroll down or expand items. Changing the description to "Find something interesting to read" resolved this.
- Some users did not realize that the page was meant to be scrollable. We tried to afford scrolling by displaying a partial line of content at the bottom edge of the paper, but some users didn't recognize the mobile app functionality we were trying to describe.
- Originally, we didn't display a "Shrink" button on expandable content, and users tried to touch outside the content to get back. Users noticed the "Expand" button and successfully clicked on it to expand items to see the full version. However, in some of the original tests we didn't draw a shrink button and users tried clicking outside expanded items to get back, similar to how you close a photo on Facebook. Some users did this even after we started showing the "Shrink" button - we could consider making clicking outside of an expanded item shrink it, though this could be another issue that comes up with a paper prototype.
- A couple of users hit the "Share" button, which took them to the canonical URL of the item (its imgur page, the e-mail in the Gmail interface, the post on Facebook, etc). Ideally, we could choose a reasonable default mode of sharing so that the user wouldn't have to take further action. There is always the possibility that the user wants to share between services or out-of-band, though.
- Some users thought the interface was busy, and they suggested hiding buttons. When the interface is on a real screen we can better determine whether the blow to learnability makes sense.
- For the most part, users did not encounter significant roadblocks. Users were familiar with interfaces that present a list of items to read, so use of our reading interface was generally straightforward.
...
- Several users took more time on the filtering task than they did on the other tasks, partly because the task itself is more complex.
- Most users took longer than we expected to find the "Filter" tab. The filtering interface went through the most changes in the iteration step. In the initial design, users accessed the filtering interface by switching tabs at the top, but most users had trouble finding the tab in the first place. When we replaced it with a button, users learned the interface much more quickly.
- Our "Advanced Filter" options button looked more like a header than a button. Some users didn't immediately understand what the advanced filter options referred to. On paper the "Advanced Filter" text surrounded by what were supposed to be disclosure arrows looked more like a header than a button. Since our task required using an advanced filtering option, users were slow to complete it. One user who couldn't find the "has a hyperlink" advanced option added "http" as a keyword search instead, which was creative and may have been as effective.
- Some users wanted to preview the results of their filter, showing filter options alongside the items in the reading interface.
- Initially, users were unsure how to apply or save their filter. After we made the buttons more prominent in the updated prototype, users figured it out quickly.
...