A3: Show your flow: Get feedback – DUE Friday, Oct. 26 @ 12:30am
[Friendly reminder: Read through this entire assignment carefully before doing your heuristic evaluation sessions so that you know exactly what you need to turn in. Otherwise you might not take the proper kinds of notes during your sessions and may have to re-do them!]
In this assignment, you will conduct heuristic evaluations (HEs) of another team's paper prototypes. Your heuristic evaluations will follow the "How to Conduct a Heuristic Evaluation" and "Ten Usability Heuristics" readings by Jakob Nielsen.
You will be given time in class on Monday, Oct 22 and Wednesday, Oct 24 to do Steps 1 and 2, but it is also recommended that you complete this over the weekend if possible, since it can be hard to coordinate with other groups on short notice. It is your responsibility to find teams on which to do heuristic evaluations.
Step 1: Perform heuristic evaluation on another team's paper prototypes
Find one other team to meet with (you will be given time in class but that may not be enough time, so plan accordingly). Write down the names of the people in that team, their studio section, and a description of their project idea.
Now meet with that team and go through "using" their TWO paper prototypes in any order you prefer (i.e., simulating pressing buttons or fiddling with menu items), jotting down as many usability problems as you observe. Don't try to be "nice" by not reporting problems – everything you write will help that team improve their project. You are helping them! Only one team member needs to be the evaluator for each prototype, but if your entire team wants to hang out and observe, that's fine as well.
Use Nielsen's ten heuristics as a guide and specify which heuristic(s) each problem is related to. If you come across problems that don't fall neatly into particular heuristics, mark that no heuristics apply. Be sure to also use Nielsen's Severity Ratings for Usability Problems to add a severity rating for every problem discussed in your heuristic evaluation.
Aside from marking down usability problems in each prototype, you must also make comparative feedback (i.e., comparing their two prototypes against one another) by noting if certain problems are found across both prototypes or just in one. If a problem exists in only one prototype, note which one by using the labels Prototype #1 and Prototype #2. You should highlight enough similarities and differences between the two prototypes so that the team receiving your feedback will understand the advantages and drawbacks of each design and know which one they should probably implement in code in the coming weeks.
As an evaluator, you should spend about 20-30 minutes reviewing both paper prototypes for a particular team.
Note: If the team you are evaluating has updated their prototypes based on prior feedback, you can evaluate their newer prototypes. However, you should still evaluate TWO different ones in your session so that you can make comparative feedback.
Step 2: Receive heuristic evaluation feedback from others
Your team will receive feedback in 1 or more Heuristic Evaluation (HE) sessions with students who are themselves doing Step 1 of this assignment. Just like Step 1, it is your responsibility to find enough evaluators (who must not be your own teammates).
At least 1 evaluation is required; more is optional but highly recommended. If you can find only 1 evaluator, that is fine, but if more evaluators want to test out your paper prototype and give you feedback since they are completing Step 1 of this assignment, please be accommodating and let them do so (within reason). We want everyone to be able to find other teams to evaluate their prototypes, so some teams may get evaluated more than once.
Nielsen recommends 3 to 5 evaluators to get good results for heuristic evaluation. For this assignment, we require only 1 evaluator, but if you get more, you are not only helping your classmates do Step 1 of this assignment, but you are also getting better feedback for improving your app. It's a win-win for everyone!
Before meeting each evaluator, your team should know the flow of your paper prototype and be able to quickly find/move the pieces of your prototype to simulate the experience of using a real app.
For each HE session, your team members should have specific roles:
(Your third team member doesn't have to be present here; they can go off and do heuristic evaluation on another team at the same time.)
Have a copy of Nielsen's heuristics ready for the evaluator to refer to. You may provide evaluators with this worksheet to fill out while evaluating. You may also want to create a Google Spreadsheet containing the heuristics (with one tab for each evaluator) so the evaluator can write their feedback directly to you. A Google Spreadsheet shared with your team and the evaluators is highly recommended because it makes it easier for the evaluator to do their Step 1 of this assignment and for you to improve your design.
For this step, your assignment submission should contain a substantive, non-trivial list of potential changes that your own team plans to implement based off evaluator feedback from your 1 or more heuristic evaluation sessions where other teams evaluated your prototypes. You can focus on one of your prototypes that you like the most, or combine features from both if it makes sense. Each listed change should be justified by explaining which piece of feedback you received caused you to propose this particular change.
Step 3: Reflection
Think about the general characteristics of the two prototypes you evaluated in Step 1, and suggest potential improvements to address major usability problems that you identified in that team's prototype (not your own prototype!). Decide which problems are most important, then brainstorm potential solutions for the team whose prototypes you evaluated.
Finally, distill all of this down to one paragraph where you address the major problems you all identified, as well as the potential solutions. Include a sentence or two reflecting on what kinds of things you found heuristic evaluation valuable for, and what kinds of things it's not very useful for, in your experience.
Note that technically only one team member needs to write up this step (preferably the person who did the evaluating), but feel free to work on it together as a team to improve writing quality. Remember, each team needs to evaluate only one other team (but you can do more if you feel like it!).
Step 4: Create a Video Prototype
As a team, create a 1-minute video prototype that demonstrates a scenario where your app might be used and the potential users that might use it. The video should illustrate the features that your team plans to implement and how those features will be used. (Choose one paper prototype to focus on in your video.) We will play each team's video prototypes during studio.
(We will be very strict about enforcing a 1-minute time limit for these videos, to be fair to all students. Think of this like a hard 'page limit' on written assignments; it is not fair to your classmates if you go over the allotted time.)
Example 1 – This student did an incredibly thorough heuristic evaluation. We especially like how this student incorporated comparative feedback. Keep in mind that the this assignment was slightly different last year.
Example 2 – This is a weak example of a heuristic evaluation, as it wasn't very thorough. The general structure of this example is decent, however, where problems are listed for each prototype and the heuristics and severity scores are identified. This example would have benefited more from comparison of the prototypes.
For some more inspiration: watch two students do heuristic evaluation
Submit a single well-formatted PDF file for your entire team with the following items concatenated within it:
Submit your single formatted PDF in Gradescope to the bin for your studio section. Only one team member needs to submit on behalf of the entire team.
Evaluation criteria & Grading rubric
The rubric below contains criteria that are worth one point each and will be graded independently and in a binary fashion.
Due In Studio: Teammate Assessment
Frequently Asked Questions
Q: Do we need to actually find someone in our app's target audience to appear in our video prototype?
A: No, you can simulate it with a teammate or friend acting in that role.
Q: What should our video prototype show?
A: See the demo video in the description for details, as well as the grading rubric. But in general, it should show a new user wanting to perform some task, then show them using your paper prototype to accomplish that task.
Q: What if we can't fit all of our app's interactions into a 1-minute video prototype?
A: That's OK, just show the most important and unique interactions (e.g., don't spend the entire minute showing how they log in).
Q: Do we need audio narration in our video prototypes?
A: Audio narration is preferred, but if you want to embed text captions into the video itself (not as separate subtitles since some video players don't support it), that's fine too. Your TA should be able to watch the video and tell what's going on, so either audio or text works.
Q: Should the same person evaluate both of the other team's prototypes?
A: Ideally yes, since you will need to write comparative feedback comparing the two.
Q: Do we need to submit the other group's heuristic evaluation feedback on our prototypes?
A: No, you don't need to submit the other group's evaluation of your prototypes (since they will submit it in their group). However your submission should contain a substantive, non-trivial list of potential changes that your own team plans to implement based off evaluator feedback from your 1 or more heuristic evaluation sessions where other teams evaluated your prototypes (see grading rubric for details).