In a data-visualization palette system, when do you use a categorical, a sequential or a diverging palette?

## Start from the data, not the brand A **data-visualization palette** is a set of colors reserved for encoding data in charts, maps and dashboards. It is kept separate from the interface palette used for buttons and surfaces, even when it borrows the same brand hues, because the job differs: interface colors signal roles, while chart colors encode values. The first decision is always **what kind of values the color represents**, and there are three common answers. | Data shape | Palette type | How color varies | Course-registration example | |---|---|---|---| | Unordered groups | **Categorical** (also called qualitative) | Hue changes; lightness and saturation kept roughly even | Enrollment split by faculty | | Ordered magnitude, no special middle | **Sequential** | Lightness changes steadily; hue fixed or drifting gently | Percentage of seats filled per section | | Deviation either side of a meaningful midpoint | **Diverging** | Two hues darken outward from a light neutral center | Seats requested minus seats offered, centered on zero | ## Categorical palettes Categorical colors label **groups with no inherent order**: faculties, campuses, delivery modes such as in-person and online. The goal is that each group is easy to tell apart and that **none looks more important** than the others. That is why a good categorical set holds lightness and saturation fairly even across its hues: one dark, saturated color among pale ones reads as the highlighted series even when nothing is highlighted. - Assign colors in a fixed order, so the first category always receives the first color. - Keep the mapping stable across charts, so one faculty is the same color on every view. - Keep the set small; beyond a handful of hues, readers stop telling them apart reliably. ## Sequential palettes Sequential colors encode **ordered quantity**: low to high, few to many. People judge order in color mostly by **lightness**, so a sequential ramp must change lightness in one direction — commonly light for low values and dark for high values on a light background. Hue may stay fixed or drift gently (for example pale yellow through green to deep blue) to add separation between steps, but the lightness trend must stay **monotonic**. This is why a **rainbow spectrum** is a common mistake for magnitude. Its hues have no intuitive order, and its lightness rises and falls — yellow is far lighter than the blue and red around it — so readers see bands and boundaries that are not in the data, and a grayscale print scrambles the order completely. ## Diverging palettes Diverging colors encode **distance from a midpoint that means something**: zero change, a target, a break-even line. Two sequential ramps in contrasting hues meet at a light neutral center, so both extremes stand out and values near the midpoint recede. In the portal, a diverging palette suits seats requested minus seats offered: shortfalls in one hue, surpluses in the other, balanced sections close to neutral. The midpoint must be real. Putting a diverging palette on fill percentage with its center at an arbitrary 50 percent invents a boundary that readers will treat as meaningful. Choose the center from what the data means, not from the middle of its range; when the data is lopsided, keep the meaningful value at the neutral color and let the shorter side stop partway along its ramp. ## Common mistakes and what they cost 1. **Categorical colors on ordered data** — readers cannot rank values, because hue has no natural order. 2. **Sequential colors on unordered groups** — readers infer a ranking (darker means more) that does not exist. 3. **Diverging colors without a real midpoint** — the neutral center suggests a threshold nobody defined. 4. **Rainbow ramps for magnitude** — uneven lightness creates false boundaries and fails in grayscale. 5. **Status colors reused as data colors** — red and green series read as bad and good even when the categories are neutral. ## How a design system ships them A design system usually publishes the three types as **separate, named sets** next to its interface palette: an ordered list of categorical colors, one or more sequential ramps and one or more diverging ramps, each documented with the data shape it serves and a worked example. Chart components, and teams drawing their own charts, consume those sets instead of picking colors per chart. - Colors stay consistent across products and reports. - The system tests each set once for color-vision-deficiency safety and grayscale legibility, instead of every team testing its own. - The question every engineer or designer answers becomes what kind of data this is, not which colors look nice. A native mobile chart, a web dashboard and an exported report can all draw from the same named sets, so the choice of palette type travels with the data rather than with the platform.