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.

Assessment Opportunities

  1. Design and run test that use paper prototypes to gather feedback on a design

    Activity Guide, page 2: Several relevant tasks should be identified in the chart, along with notes describing the user testing around those tasks.

  2. Analyze user tests to identify features that should be removed, added, or improved

    Activity Guide, page 1: The left side of the T-chart should include at least four descriptions of things that happened in the test, and the right side should list respective proposed improvements to the app.

Agenda

Lesson Modifications

Warm Up (5 min)

Activity - Testing (45 min)

Wrap Up (5 min)

View on Code Studio

Objectives

Students will be able to:

  • Design and run test that use paper prototypes to gather feedback on a design
  • Analyze user tests to identify features that should be removed, added, or improved

Preparation

  • Either have other people lined up to test each team’s paper prototypes, or schedule enough time for teams to test each other's prototypes
  • Print a copy of the activity guide for each team

Links

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

For the Students

Support

Report a Bug

Forum

Teaching Guide

Lesson Modifications

Attention, teachers! If you are teaching virtually or in a socially-distanced classroom, please read the full lesson plan below, then click here to access the modifications.

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 - 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 the 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. Roles will be switched between tests to allow each student to try each role.

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 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 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?

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.