Vary race-category color assignments across projects
For repeated communication of racial categories across separate projects, vary category color assignments on categorical palettes to improve respectful framing and mitigate permanent color-category links for readers who encounter multiple graphics over time.
- purpose:refine
- basis:heuristic
- data:categorical
- quality:trust
- lever:encoding
- communication:workflow
- polish:palette
- channel:color-hue:use
advice
Cross-project color rotation
Change the palette or the color-category mapping when you visualize racial data again in another project. For example, if one group was pink in the last project, assign it a different hue such as turquoise or dark blue in the next one instead of making the same color permanent.
reason
Why rotating colors matters
Repeated palette assignments create stable associations that start to feel natural. Changing the mapping between projects keeps any one hue from becoming attached to a racial category as if that link were inherent.
Mechanism: Cross-project variation prevents readers from learning a fixed race-to-color code that can harden stereotype-like associations.
Evidence: The source says that no race should be permanently linked to one specific color and recommends choosing a different set in later projects, giving examples such as using pink in one project and turquoise or dark blue in later ones (Muth, 2024).
context
When to rotate colors across projects
- User Goal: Avoid building a permanent race-to-color code across coverage.
- Task: Publish a new chart or map after earlier projects on similar racial data.
- Data: Categorical racial groups.
- Chart Setting: A new project with a fresh category palette choice.
- Audience: Readers who may encounter more than one project over time.
- Success Criterion: No group becomes predictably tied to one hue across separate projects.
exceptions
When not to rotate colors
Break it when: you are not choosing colors for another project but working within the same already-colored project. Why: the source recommends shuffling colors when you pick colors again in another project.
costs
Costs of rotating colors
Sacrifice: You lose repeated cross-project color familiarity. Risk: Reusing one fixed mapping can make a category seem naturally tied to a hue. Mitigation: Change either the palette itself or which group receives each hue in the new project.
mistakes
Common cross-project color mistake
Mistake: Keeping the same race-to-color mapping every time because it feels consistent. Why it fails: That repeated consistency hardens the very color-category link the guideline is trying to avoid.
check
How to check for repeated mappings
Failure Sign: The same group keeps appearing in the same hue across recent projects. Quick Check: Compare the current key to the last few race-related graphics. Stronger Test: If a reviewer can guess a group’s color from prior projects before reading the legend, change the mapping.
fix
How to fix repeated mappings
- Reassign categories to different hues than last time.
- Swap which group receives a previously used hue.
- Start with a different palette for the new project so no single group keeps one permanent color.