An Argument for Dummy Tables with Examples

Publish Date

A dummy table is a planning tool that approximates data structure. They serve as a practical method of organizing thoughts and expectations before working with data. For analysts, it can take many forms, such as a dataset, a summary table, or even visual chart formats. It can even be an empty box.

There is no correct way to create or use dummy tables, but I would like to share some examples of how I’ve used them to plan and refine analytic work. Maybe they will inspire you to give it a try!

Example 1: Visualizing Final Tables

This example shows how dummy tables can be used to design a final table. This particular use case is helpful when starting out or when analytic tables become complex. Table 1 is the initial draft for the tables featured in the Consistency of MBSF: Base Race Codes over Time (2010 vs 2019) article.

Table 1. Final Table Draft

 Difference(%)
Beneficiary Race Code  
RTI Race Code  
2010 Entitlement - OASI  
2010 Entitlement - DIB  
2010 Entitlement - ESRD  
Sex – Female  
Sex – Male  
Sex - Other  

Table 1 caption: The first attempt at a table that describes beneficiary race changes over time by beneficiary characteristics. Columns represent the difference between 2019 and 2010 and the percent difference.

Table 1 plays to the strength of having an all-encompassing table. Having a one-stop shop can reduce reader fatigue by removing the need to search across tables for information. However, there are a few limitations with this table:

  1. It’s difficult to read.
    These types of tables can become very dense quickly, even with a few rows. It’s possible to format these tables into a visually digestible format, but it may not always work for web design and accessibility. Additionally, readers may assume that all the rows are inclusive, which is not the case. Each category is exclusive.
  2. It’s missing a total column.
    Total columns provide context to the values in your table when using percentages.
  3. The labels could be improved.
    The column header “Difference” will be unclear to readers. As a dummy table, the header works because I know what I’m trying to convey. However, it’s important to remember that the final table is for your audience. I had to translate my intention into the final version.

It’s not reasonable to expect that you’ll catch these issues immediately. In practice, I often find these mistakes when making final tables in Excel or during peer review. However, even an imperfect dummy table can help prevent early structural concerns.

Example 2: Anticipating Data Anomalies

This example shows how dummy tables can be used to identify anomalies and rare cases.

For context, I was attempting to manage Medicaid beneficiary enrollment in a single year of CMS Medicaid data. Medicaid beneficiaries can gain and lose benefits multiple times a year. After a preliminary view of raw data, I created a dummy table to map out possible enrollment scenarios to inform my coding approach. This table was the product of multiple test runs.

Table 2. Data Anomalies Table Draft

JanFebMarAprMayJunJulAugSeptOctNovDec
xxxxxxxxxxxX
xx          
         xxx
   xxxx     
xx      xxxx
  x x xxx   

Table 2 caption: This table illustrates potential enrollment patterns with months as column headers and rows representing enrollment in said month.

As seen in Table 2, I was able to identify the following enrollment patterns:

  • Continuous Enrollment (Enrolled all 12 months)
  • Left censorship (Continuous enrollment starting in January but ending before December)
  • Right censorship (Continuous enrollment not starting in January but ending in December)
  • All Other
    • Single continuous enrollment, not starting in January or ending in December
    • Single enrollment gap
    • Multiple enrollment gaps

This visual representation helped me in many ways. First, I was able to use this table to anticipate and track unexpected enrollment patterns. This system allowed me to design failure tests to ensure beneficiaries were placed in the correct buckets. As I found more enrollment pattern types, I was able to track those in this table. Second, I was able to use this table to communicate with the principal investigator about managing patterns. It was much easier to understand the difficulties of enrollment management with a visual.

Conclusion

Dummy tables are a simple but powerful tool for structuring analytic work. They clarify requirements, identify gaps, and improve efficiency. Consider incorporating dummy tables into your workflow!

Stop back here every once in awhile and you might find new examples waiting for you.