...
Overall, the user didn't have serious issues with the core functionality of the interface, it was just supplementary features that were confusing. Most of the issues with the core functionality were learnability issues, so the next time she used the application she would probably better understand how it worked. Resizing was also an issue with this user, so maybe eliminating the enlarge video button and replacing it with a resizable Review pane would be a good idea. Since the user wanted to go back to the parent folder from the note and couldn't do it with the "Home" button, she was worried that clicking the browser back button would lose all of her changes to the note.
User 3
Our final user was a junior majoring in course 6.
Task 1: The user made a new note in the root folder, hoping to be able to move it into the 6.813 folder and was surprised that it went directly to the edit screen. This user had no issue with starting the recording, noting that the disabled "play" button was helpful in letting him know what he could and couldn't do.
Task 2: While this user didn't resize the video player to take a picture, he had much more trouble actually cropping it. Part of the inserted image was hanging off the bottom of the screen, and since our "crop" and "delete" buttons always show up just below the image, they weren't visible so he didn't think there was an option to crop at first. He also got annoyed at the "crop" and "delete" toolbar moving when he scrolled, rather than remaining attached to the bottom part of the image.
Task 3: Since the user didn't create the note in the 6.813 folder to begin with, he had to move it to the correct location. He had no problem dragging it into the correct folder.
Task 4: This user also tried to use the search bar to find "Lecture 19", which didn't work because it only searches based on note contents. Once he found the note, he was unsure of how to find the relevant section of notes. He started watching the video at 2x speed for a few seconds, before realizing that the scrub bar could be dragged. Once he learned (by mistake) that the correct section of video could be skipped to by clicking on the corresponding notes, he was able to navigate the notes and video much more easily.
Again, most of the issues involved seemed to be caused by learnability problems. Once he used the application a few times, the user would likely have no problem accomplishing these tasks.
Reflection
Overall, the way that we did our initial designs and paper prototypes had some pros and cons. We came up with three very different ways to bring images into our note-taking program: the webcam solution we implemented, taking photos with a smartphone, and drawing diagrams with a smartphone. We paper prototyped all three, since they were so different, before settling on the webcam option since we liked the extra review features it let us implement. Considering very different alternatives for how to handle our input was useful, but it also meant that we only came up with one design option for the input method we ended up using. Paper prototyping all three alternatives let us be a lot more confident in our decision to narrow in on the webcam alternative, but it also meant we spent less time developing and iterating our paper prototype of the webcam design. In summary, the broadness of our scope in the beginning of our design and paper prototyping process helped us come upon a design idea that we might not have decided on otherwise. However, it left us with less time to tweak and iterate on that idea once we had settled on it. The ideal solution would be to start with a broad scope, but spend more time iterating later; however, time constraints prevented us from doing this. It's difficult to say whether we made the right choice in that regard. However, even with less iteration on our paper prototype of the webcam design, we still got very good feedback from users, and made several major design decisions based on their feedback, detailed in the Design section.
...