Recording the data is often an initial step in an activity. Because it's not the actual point of the activity, it often gets short shrift. Consequently, some students get all tangled up just recording the data—and it can stop them before they get to the content.

One solution to the problem is for you, the teacher, to set it up. You create a data-recording handout (or use one that someone else prepares) that makes it easy for students to do it right. It’s got suitable headings and columns and enough space for the data you know they’ll need. If you do the organizing, two good things happen: the students get to the actual data analysis faster, and they see an example of how to set up data recording well.

Of course, we want them to do the organizing themselves as soon as possible. This has two happy results: it saves you from having to do it, and it gives them practice with this important skill.

Students are used to using a “T” table for exploring functions and number patterns, but may not always use it for data. Left to their own devices, many students record data haphazardly, for example, as a horizontal list of numbers or as “clouds” of numbers on the page.

It's worth devoting a little class time to having students imagine what their data will look like and design a table to fit. A quick debrief of this process will help them see what will work—and that it is not a lot of effort.

Students will see that the T-table is a surprisingly general form: you have columns for different variables and one row for each observation. It’s like a well-designed spreadsheet. You can always add more columns to a table to accommodate some other variable. For example, if you’re recording class heights, you might have a column for name and a column for height. If you decided you wanted to see whether the girls were taller than the boys, you might add a new column for sex.

But a T-table is not the only way. For simple data, you might record it with tallies or graphically (as is done in the "Roving Ranges" poster problem).

For more complex data, it helps to design what amounts to a hierarchical data system. If you’re comparing the heights of sixth graders to seventh graders, for example, you might have two tables, one for sixth and one for seventh. Each table would have a heading that told which grade it was. That is, every row of the table shares some characteristics: the information in the header.

Some students would organize the height data in a single table with two columns, one for sixth and one for seventh. This makes perfect sense visually and conceptually, but it actually breaks an implied rule of the T-table: that each row corresponds to a single unit. It is not worth making a big deal about this with students at this stage, but if they were to use a computer for data analysis, that table scheme might cause problems. For a single, “flat” table, a better organization is to have two columns: height and grade. The “grade” values will have lots of duplicates, but at least each row will be a single student.