Table Designer

Table Designer

Heritage and scope

This is an original Open Science Skills workflow for table production in social-science manuscripts. It is general — apply to descriptive tables, regression tables, balance tables, and summary tables across any method. For tables whose interpretation depends on method-specific standards, also consult the relevant sibling skill (conjoint-design, conjoint-diagnostics, list-experiment, topic-modeling, text-classification, vlm-ocr-pipeline). For end-stage QA on a finished table set, hand off to figure-table-audit.

Tables are for precise reading. A good table is one where the relevant comparison can be made without arithmetic, and where every number that appears in the manuscript text can be traced back to a specific cell. If readers have to do mental subtraction to recover the substantive quantity, the table is the wrong shape.

Instructions

1. Decide whether the result belongs in a table at all

Tables are for reading values; figures are for seeing patterns. Use a table when:

• Readers need exact values (descriptive statistics for a sample, balance check, key effect sizes for citation).
• The comparison spans many models or specifications and a coefficient plot would be too dense.
• Regulatory or replication norms require it (CONSORT flow numbers, baseline balance).

Use a figure when the substantive claim is a pattern — a slope, a non-monotonicity, a difference of differences. Many regression tables in social science would be more readable as coefficient plots with a small accompanying summary table.

2. State the comparison and the estimand before laying out the table

Write down, in one sentence, what the table is supposed to let the reader compare. The first column or first panel should anchor that comparison. Examples:

• "Effect of treatment on turnout, baseline → with covariates → with fixed effects → preferred specification."
• "Sample means by treatment arm, with balance test."
• "AMCEs by attribute, pooled and split by partisanship."

If the comparison is not clear, the table will read as a coefficient dump.

3. Choose column order to match the argument

Columns should mirror how the text walks the reader through the result:

• Regression tables: baseline / minimal-controls → preferred specification → robustness checks. Place the preferred model in a clearly labeled column, not necessarily the rightmost; readers focus on the column that the text says is preferred.
• Comparison tables: control / treatment 1 / treatment 2 / contrast(s), or pre / post / difference.
• Descriptive tables: full sample → analytic sample → by treatment arm; or order subgroups by substantive logic, not alphabetically.
• Do not let stargazer/modelsummary defaults dictate the order if it obscures the comparison — pass models in argument order that matches the manuscript.

4. Group rows and structure panels