Colors

1. A tool for communicating interactive UI affordance

Color is one of the primary signals that tells someone “this is something you can act on.” Buttons, links, active states, focus rings, and selected states all rely on color to separate the interactive layer of the UI from the static layer. If everything on a page were the same neutral tone, users would have to guess what responds to a click. Color removes that guesswork.

This affordance role is intentionally consistent and narrow: a small set of colors are reserved for “this is actionable,” and those colors aren’t reused elsewhere for decoration. That consistency is what lets someone scan a dense clinical screen and immediately know where the actionable elements are, without reading every label.

2. To embed character and personality into the product

Beyond function, color is one of the clearest ways a product communicates feel. A sterile, clinical tool and a warm, approachable one can have identical information architecture and still feel completely different, and that difference lives largely in color choices, particularly at the accent layer.

For Air EMR, this means color has to walk a specific line: professional and trustworthy enough for a clinical setting, without feeling cold or sterile in a way that adds to the emotional weight clinicians already carry in their day. Accent choices are where this personality lives, and where the product’s character can flex without touching the semantic logic underneath it.

3. A semantic tool to communicate system status and intent

Color is also how the system communicates state: what’s normal, what needs attention, and what’s urgent. This is the highest-stakes use of color in the system, because getting it wrong has real consequences in a clinical context. A status color needs to mean the same thing everywhere it appears, every time, with no exceptions.

Because of that, semantic color use is the most rigidly governed part of the system, covered in detail below.

All color is applied via tokens

There are no hardcoded hex values anywhere in the product. Every color used in the UI resolves through the token system (primitive → semantic → accent), described on the Design Tokens page. This is what makes everything else on this page possible: theming, surface-agnostic components, and consistent semantic meaning all depend on color being a token, not a fixed value baked into a component.

If you’re building a new component and reaching for a raw hex value, that’s a signal to check whether an existing semantic token already covers the case, and if not, to raise it rather than hardcode it.

Theming across two dimensions

The color system supports theming along two independent axes:

1. Light and dark theme: the full UI can shift between light and dark modes. This is handled entirely at the semantic layer: semantic tokens point to different primitives depending on active theme, so components never need theme-specific logic of their own.
2. Accent themes: currently blue, green, and purple, with room to expand. Accent themes shift the personality/brand layer of the product (primary actions, key highlights) without touching semantic meaning. Switching accent theme should never change what a color means, only how the “personality” layer of the UI looks and feels.

These two dimensions are independent of each other by design: any accent theme should work correctly in both light and dark mode, and switching theme shouldn’t require re-deciding what counts as a danger state or a success state.

A surface-agnostic color system

The system is built so that components remain fully functional and accessible regardless of the surface they’re placed on, within reason: a card on a default background, a card on an elevated surface, a card inside a colored callout. Rather than designing components against one assumed background, we design them against a set of surfaces they need to hold up on.

This is a scalability decision as much as a visual one. As Air EMR (and the broader Commure product surface) grows, new contexts and layouts will place existing components on backgrounds we didn’t originally design around. A surface-agnostic approach means we don’t have to special-case every new placement. A component that’s already proven accessible across our surface set is very likely to hold up in a new one too.