Why Our UI Is Black and White

Last week we started documenting Sirius2’s design foundations. Writing the Color and Depth sections forced us to articulate decisions we’d been making intuitively. Turns out they’re more coherent than I expected. There’s a philosophy here, and naming it makes it easier to apply consistently.

Why the interface is black and white

Sirius2’s core interfaces use a monochromatic color scheme. Not because we don’t like color, but because we want color to mean something.

When everything is colorful, nothing stands out. A dashboard with blue headers, green buttons, orange badges, and purple accents is visually busy but informationally flat. Your eye has no guidance on what matters. Every element is competing for attention.

When the baseline is neutral (grays, whites, blacks) then the moment something uses color, it pops. A red badge on a monochrome interface screams “critical.” A green status pill says “success” without needing the word. Color becomes signal, not decoration.

This is a hard constraint to maintain. The instinct to “make it look nice” with color is strong, especially for marketing-adjacent surfaces. Our rule: color in the UI is only permitted when it carries semantic meaning. If removing the color would lose information, the color belongs. If removing it would just make the page less pretty, it doesn’t.

Thirteen color roles

Every color in Sirius2 maps to one of thirteen semantic roles:

The obvious ones: Success (green: completed, confirmed), Warning (yellow: needs attention, not yet critical), Critical (red: errors, blocked states, destructive actions). These are universal and need no explanation.

The interesting ones:

Caution is different from Warning. Caution is “this hasn’t started” or “this is stalled.” It’s pre-severity, meaning the task isn’t late yet, but it’s not moving. Warning is “this needs your attention now.”

Magic is reserved for AI and automation features. It has its own color so that AI-driven suggestions, automated actions, and generated content are visually distinct from human-driven UI. Users should always know when they’re looking at something an AI produced.

Emphasis is for active/focused elements in editors: syntax highlighting, selected text, cursor position. It doesn’t appear in standard UI, only in content-editing contexts.

Input is reserved for form elements. It ensures WCAG contrast ratios between form controls and their backgrounds without affecting the color choices available for other UI elements.

Each role has a strict set of do/don’t guidelines. Info is for tips and promotions, never for urgent statuses. Brand is for primary actions, never used on multiple elements in the same area. Navigation colors stay in navigation. They never leak into content areas.

How we built the palette

The palette is generated using HSLuv, a perceptually uniform color space. The key property: colors at the same lightness step across different hues have identical perceived brightness. Our Red-12 and Blue-12 don’t just have the same numerical lightness. They look equally bright to the human eye.

This matters for accessibility. If you swap a success badge (green) for a critical badge (red), the contrast ratio against the background stays the same. You can theme components by changing the hue without recalculating whether the colors are accessible. The math guarantees it.

Twelve hues, sixteen lightness steps each, 192 palette values total. All generated from a Ruby class, not hand-picked in a design tool.

Depth: three purposes

Depth in Sirius2 serves exactly three purposes. Any use of depth that doesn’t serve one of these is wrong:

Hierarchy: higher elements are more important. A modal floats above the page because it demands attention. A dropdown menu floats above the content it overlaps. The z-index system has twelve named layers from layer-0 to layer-top, and each layer has a defined purpose.

Interactivity: depth signals “you can interact with this.” Buttons have a subtle bevel and shadow that makes them feel tactile. Cards with hover shadows invite clicking. Static elements must not have depth because it misleads users into thinking they’re interactive.

Focus: depth guides attention. A darker backdrop behind a modal pushes everything else into the background. But we pair depth with other techniques (contrast, blur, opacity) because not all users perceive depth the same way.

Four mechanisms for creating depth

Shadows: elevation shadows (below the element, simulating floating), inset shadows (within the element, simulating recessed), and bevel shadows (dimensional appearance enhancing perceived shape). Buttons use a combination of bevel and elevation that gives them physical presence without looking heavy.

Lighting: subtle brightness changes that reinforce interactivity. A button’s hover state is slightly lighter. Its pressed state is slightly darker. These are 1-2% changes that you feel more than you see.

Layering: organizing elements on different z-planes. Most elements should live on the same layer to establish a baseline. Layering is reserved for elements that genuinely need to float: modals, dropdowns, tooltips, toasts.

Surface depth: using background color intensity to push content into the visual background. A subdued Card section with a gray background de-emphasizes its content relative to the primary section above it. No shadows needed, just color intensity doing the work.

What writing this down taught us

Articulating the color philosophy exposed a few places where we were violating our own rules. A couple of components were using color decoratively. One section header had a blue tint that carried no semantic meaning. It was just “making it look nice.” We removed it.

The depth documentation revealed that we’d been inconsistent about shadow intensity across similar components. Cards and Popovers had different shadow definitions despite occupying the same conceptual layer. We unified them.

This is the value of writing design documentation. It’s not just for the reader. It’s a mirror that shows you where your practice doesn’t match your principles.