The goal of this milestone is to create a low-fidelity prototype, do a cognitive walkthrough and small user test on that prototype, plan your medium-fidelity prototype, and then get started on implementing it.
For the final step of your Ideate Milestone, your team chose the most promising conceptual design. At this point you should selectively incorporate (based on time constraints) feedback that you received from your instructors and peers, as well as any further thinking you have had about the design in order to develop a low-fi prototype. Use your list of requirements and your task examples to flesh out the details needed for your prototype.
Reality check: normally you would incorporate all the feedback you received, which could involve starting from scratch with a new conceptual model. That is not practical for this project.
1. Develop a low-fidelity “paper” prototype
Tools to use: For your low-fidelity prototype, you are expected to use a non-computational technique, i.e., nothing that involves scripted interactivity. This will give you the opportunity to act as the “computer” in the evaluation step (described below). If you are unsure of what technique to use, consult the course staff.
Scope and other dimensions: Your prototype should illustrate how your system would appear to the user. You should not be concentrating on prettiness or completeness; rather, you are trying to show the overall interaction style and to indicate the scope of your system. Your prototype should contain the core views that illustrate how the system will work as a whole, with emphasis on the parts you are focusing on, including the interactions based upon the key tasks. The low-fi prototype does not need to capture every little detail, but it should capture the details that will dominate the experience of using it.
1.A. Document your prototype(s) using media of your choice. This illustration should document the main components of your design, and show how the prototype supports your task examples. E.g., you could create a narrated video demonstrating how a user completes those tasks with the prototype(s). If using photos, or something else, include annotations and labels as appropriate to ensure the demonstration is easy to understand.
1.B. Additional Information about your prototype(s). Identify which of the task examples you have chosen to support in your design. (Generally, your prototype should support at least 2 of your task examples.) Justify the scope of your prototype(s), as well as the major design decisions you made. Include any additional information that didn’t make it into your demonstration in part A, but you think is critical for course staff to understand the design.
Length: There is no specific length limit for parts 1.A and 1.B. However, please avoid excessive length and concentrate on conveying key aspects. If in doubt, consult course staff.
2. Evaluation: Walkthrough + Informal User Test
Test the low-fi prototype for usability bugs (problems, faults, weaknesses) by performing both a brief cognitive walkthrough and a small informal user test, using the task examples supported by your prototype.
Cognitive walkthrough: Note that while the walkthrough is typically performed by the interface designer and a group of his or her peers, you should consider having one or more of your team members perform the walkthrough together with two or more classmates from another team (e.g., swap team members for the walkthrough).
2.A. Walkthrough Report: Briefly summarize what you learned in your walkthrough, good and bad. Then very briefly address each task example in a separate paragraph. If you found nothing wrong for a given task, (i.e., your interface is perfect) then outline the ways in which it was perfect (e.g. “Our cognitive walkthrough showed that users can do X, Y, and Z without errors or confusion.”).
Reality check. At this point, depending on the issues uncovered, in a real project you would at a minimum address any issues with the prototype (at a maximum, scrap the prototype and restart), but there is not enought time. You should do what you can to fix minor issues and move on to the user testing as fast as possible.
Informal user test: Design a simple user testing protocol and recruit 3-6 representative participants (depending on how easy it is for you to get participants) to evaluate both your low-if prototype and your conceptual model, as well as to validate your task examples. A simple user testing protocol includes a short list of the goals you have for the evaluation, a simple introduction script for how you will introduce the prototype to the users, the tasks that you will ask users to do, and the interview questions that you will ask users. In terms of running the participants through your protocol, it is best to have at least two team members at each session. One for managing the session and the other for taking detailed notes. Collectively as a team, you should then summarize what you learned from the user testing, the strengths and weakness of your design, with the latter tagged according to how critical they are (show-stopper, major, minor).
Reality Check: In a real project, you would video record these user testing sessions in order to replay them with the entire team for more detailed analysis.
2.B. User Test Report: Briefly describe your protocol and participants at a level that another team could replicate what you did, and document what you learned about the strengths and weakness of your design. Make sure to reflect on how well your conceptual model was received, and whether you were able to validate your task examples.
Length: up to 3 pages for both 2.A and 2.B (use an appendix for material that doesn’t fit)
3. Plan your medium-fidelity prototype
Decide on scope and emphasis of the medium-fidelity prototype. All project teams will build (at least) one interactive prototype, meaning a fully- or semi-functional, coded simulation of the system. For some projects, it may be helpful to also build a very simple non-functional physical mockup so that users can understand the system’s form factor. Overall effort should be based on the size of your team.
Reality check. Depending on the issues uncovered in your user testing, in a real project you would address those issues, likely iterating on the low-fi prototype and running more user tests, before moving on. But given the time pressure, you should do what you can to fix the issues that you can in the short time and move on to your medium-fidelity prototype.
To help you figure out what to include and what not to include in your medium-fi prototype, beyond supporting at least 2 task examples, consider: What aspects are most novel/interesting in the design; What are you most curious about in terms of how users will respond — e.g., Will they understand X? Will they be able to complete a task in Y in a reasonable amount of time? Make sure your prototype will enable you to eventually answer those questions.
The functional prototype(s) you build will generally be some combination of horizontal and vertical. Note that a prototype is rarely either entirely horizontal or vertical, but rather some combination of the two. You need to have a sufficient vertical component that, at an absolute minimum, subjects can complete one task. Likewise, you need to have a sufficient horizontal component to provide some indication of what the envisioned system/interface would look like as a whole.
The point here is that except for a quite simple interface, we do not expect you to implement everything. Figuring out the scope (both horizontal and vertical) is an art. Give it careful consideration and solicit input from your course staff.
Examples of the questions you must answer at this point include:
Consider the topics covered on the “Many Dimensions of ‘Fidelity’” slide from lecture to see if others are relevant for your project.
The goal is to get the most useful evaluative results with the least amount of production effort. Less is good! But, choose wisely where to direct your effort.
3.A. Rationale of Medium Fidelity Prototyping Approach: Briefly summarize your reasoning for choosing your prototype approach, i.e. at a minimum address each of the questions stated above, address anything else that is pertinent, and provide rationale for your answers.
Length: up to 1 page
4. Begin to develop your medium-fidelity prototype
Begin to embody your design(s) in a medium fidelity interactive prototype(s); and if appropriate, a non-functioning supporting prototype as well. Note that we do expect the total prototyping effort involved to be fairly uniform across projects (normalized by team size).
You will not have sufficient time to complete the prototype for this milestone.
4.A. Preliminary prototype demonstration: Briefly document the status of your prototype implementation, with a paragraph and using screenshots/screen capture, photos, or the equivalent for your project.
Length: There is no specific word limit for this part. However, please avoid excessive length and concentrate on conveying key aspects. If in doubt, consult course staff.
Report:
There is no presentation for the Prototype milestone but Instructor will walk through each team’s preliminary prototype and will provide verbal feedback and suggestions for improvement in the working class. Please be ready to demonstrate your prototype.
For your report, include an appendix that identifies each team member’s contributions. You may optionally include additional appendices for content that does not fit into the main sections of the report.
Teams need to submit a pdf of their report to Canvas. Please give your pdf files name “Prototype-report-<team name>.pdf”.
Rubrics: