Unit4
Ch. 1
1
2
3
4
5
6
7
Ch. 2
8
9
10
11
12
13
14
15
16

Lesson 11: Prototype Testing

Overview

The primary purpose of developing paper prototypes is that they allow for quick testing and iteration before any code is written. This lesson is focused on giving teams a chance to test their prototypes before moving to App Lab. Teams develop a plan to test with users before running prototype tests with multiple other students in the class (and potentially outside the class). In order to test the prototype with the users, the students will have to assign roles in the testing (the “narrator”, the “computer” and the “observers”) as well as have some questions prepared for the user to answer after the test is complete.

Purpose

The goal of this lesson is to give students a clear format for testing and iteration of their apps. This will be the first of multiple opportunities teams have to test various stages of their prototypes, and each stage will serve a different purpose. At this point the primary purpose is to gut check assumptions about how the app should be laid out and navigated - this is not the time for students to be overly concerned about fine details.

Agenda

Warm Up (5 min)

Activity 1 - Testing (45 min)

Wrap Up (5 min)

View on Code Studio

Objectives

Students will be able to:

  • Test a prototype with a user, recording the results
  • Analysing a user test to identify potential issues or improvements

Preparation

Links

Heads Up! Please make a copy of any documents you plan to share with students.

For the Students

Support

Lesson Forum

Report a Bug

Teaching Guide

Warm Up (5 min)

Getting Prepared

Distribute: Make sure each team has their prototypes in hand.

Prompt: Before considering testing with other users, take a moment as a team to work through their screens.

Activity 1 - Testing (45 min)

Praparing for Testing

Remarks

When you are running an experiment in science class, you do your best to test one hypothesis at a time. For example, if you want to prove a theory that food will spoil more quickly out of the refrigerator than inside, you wouldn’t want to test with a warm fridge that is say 50 degrees fahrenheit and and outside temperature of 50 degrees as well. Nor would you want to test with either case having the temperatures swing wildly - that might affect the results of which spoils first! So you would want to control the temperature “variable” of the food both inside and outside of the refrigerator and see what happens.

It’s the same thing when you’re testing software. Even though people are very variable, you want to eliminate as many “variables” as possible.

One way to do this is to make sure you’re asking the same questions each time you test a piece of software. So we’re going to work on a list of questions to ask our users when they are done testing our low fidelity prototypes - so we could compare the different users’ reactions to your apps and their answers to your same questions.

Display: Show What's For Lunch Testing - Video.

Discuss: what did you notice about how this test was run? Specifically dig into to following roles that were played:

  • The “user” is the person who is testing the app in the form of the low fidelity prototype. The user should pretend to execute the “app” by pressing on the prototype with their fingers in the way that makes most sense. The most important part is that the user should speak out loud what they are thinking as they do their actions and ask lots of questions if there are things they don’t understand. They can also offer helpful suggestions in our critiquing form with sentences starting with “I like…”, “I wish…”, and “I wonder… “
  • The “computer” is the person who is manipulating the fidelity prototype based on what the user is doing. For instance, if the user presses a button that should make the app go to another screen, the “computer” would take away the mock up of the old screen and replace it with the the mock of the next screen. The “computer” starts the test by presenting the user with the first screen of the app.
  • The “narrator” is the person who is running the test. This person will introduce the team members, app and it’s purpose. This person will also remind the user to talk out loud as they are manipulating the app and will remind the “computer” and the “observers” to keep from trying to steer the user in what they think the right way to use the app is, unless the user asks for help.
  • The “observers” are the other students in the team. They will watch the interaction and write down in their notes what they see the user do in response to the computer.

Teaching Tip

Reducing Printed Materials: This Activity Guide can be completed online or as a journal activity.

Distribute: One copy of Paper Prototype User Testing - Activity Guide for each team.

Paper Prototype User Testing

Overview: As a class review the goals for the user test. In particular respond to any questions about the different roles.

Assign Roles for Testing: Ask groups to assign roles for their testing. If they wish, however, roles can be switched between tests.

Teaching Tip

Testing Outside of Class: If you wish, ask groups to run a version of this test with a member of the community, school, or their families who might be a likely user of the app. If students are testing outside of class, it's recommended that they make copies of the prototypes to use so that the "master" copies stay safe and available to the team.

Identify Users: Groups should either be paired with another group to test out their app.

User Testing

Set Up: Decide how groups will pair up for testing and place the arrangement where students can see.

Prompt: Using the Paper Prototype User Testing - Activity Guide, test your app with a user.

Circulate: Students will start their tests which should run for about 5-7 minutes each. Encourage students to keep on task, and encourage the observers to write as much as they can. After students are done, have them move back to their original team.

Summarize Findings: Have groups discuss what they observed and record their findings on the first page of the activity guide. In particular ask them what their observations mean in terms of changes they'll need to make for the user interface of their prototype.

Wrap Up (5 min)

Reflection

Journal: Write in your journal the answer to this question:

  • Was there a difference between testing with a user that was involved in the development of your low fidelity prototype (what we did yesterday) vs testing with a user who had never seen this app before?
  • What were some of the similarities between the two types of users?
  • What difference did you see between the two types of users?
View on Code Studio

Overview

In this lesson teams test out their paper prototypes with other members of the class. With one student role playing the computer, one narrating, and the rest observing, teams will get immediate feedback on their app designs which will inform the next version of their app prototypes.

Resources

Standards Alignment

View full course alignment

CSTA K-12 Computer Science Standards (2017)

AP - Algorithms & Programming
  • 2-AP-10 - Use flowcharts and/or pseudocode to address complex problems as algorithms.
  • 2-AP-15 - Seek and incorporate feedback from team members and users to refine a solution that meets user needs.
  • 2-AP-17 - Systematically test and refine programs using a range of test cases.
CS - Computing Systems
  • 2-CS-01 - Recommend improvements to the design of computing devices, based on an analysis of how users interact with the devices.
DA - Data & Analysis
  • 2-DA-08 - Collect data using computational tools and transform the data to make it more useful and reliable.
  • 2-DA-09 - Refine computational models based on the data they have generated.
IC - Impacts of Computing
  • 2-IC-22 - Collaborate with many contributors through strategies such as crowdsourcing or surveys when creating a computational artifact.