Colour decisions in embedded display design are constrained by physics that do not apply to desktop or print design: the display panel's physical colour gamut, the ambient light in which the product will be used, the viewing angle at which the panel is observed, and in some cases regulatory conventions that define what specific colours mean in safety contexts. A colour palette that looks excellent on the designer's sRGB monitor may render as flat, washed-out, or indistinguishable on the actual TFT display in the application's ambient lighting conditions. This guide covers the physical constraints and engineering best practices for colour in embedded display design.
Display Technology and Colour Rendering
Not all embedded display panels render colour equally. Understanding your panel's characteristics before designing a colour palette prevents late-stage surprises:
- TN (Twisted Nematic) panels: Wide deployment in industrial and automotive applications due to low cost and sunlight readability. Colour accuracy is limited — colour shift at off-axis viewing angles (±30°) is significant. Reds shift toward orange at off-axis viewing. Avoid designs that rely on subtle colour differences between similar hues — they may become indistinguishable at off-axis angles. Use high-contrast colour pairings.
- IPS (In-Plane Switching) panels: Better colour accuracy and wider viewing angles. Premium embedded applications (medical devices, consumer electronics, smart home panels). IPS colour rendering is closer to sRGB — designs created on sRGB monitors will translate better. Still has a white-to-black contrast ratio of approximately 1000:1, meaning dark greys on black background require careful contrast checking.
- AMOLED displays: True blacks (OLED pixels are off), infinite contrast ratio, vivid colour saturation. Dark backgrounds look definitively dark, not "dark grey." Designs that use dark themes benefit enormously from OLED. Over-saturated colours (pure red, pure blue) may appear overwhelming at full brightness — consider slightly desaturated versions of primary colours for large filled regions.
- Transflective and reflective displays: Used in outdoor/sunlight-readable applications. Colour gamut is narrowed compared to transmissive panels. Effective colour palette reduces to high-contrast combinations: white, black, strong primaries. Subtle secondary colours will be invisible in high ambient light.
Contrast Ratio Requirements by Ambient Condition
WCAG 2.1 (Web Content Accessibility Guidelines) specifies minimum contrast ratios for text legibility. These apply equally to embedded displays:
- Normal text (under 24px): Minimum 4.5:1 contrast ratio between text and background
- Large text (24px+, or 18px+ bold): Minimum 3:1 contrast ratio
- Non-text UI elements (icons, borders, status indicators): Minimum 3:1 contrast ratio against adjacent colours
In bright ambient environments (industrial floors, outdoor agricultural, automotive with sun glare), the effective contrast ratio requirement increases — sunlight reduces the display's apparent contrast. Add a 2× safety margin to WCAG minimums for outdoor and high-ambient-light applications. For critical safety displays, target 7:1 or higher contrast for alarm text.
Colour Coding Conventions in HMI Design
Industrial and safety HMI design has established colour conventions that operators have learned from years of use. Deviating from these conventions causes confusion and errors. Follow ANSI/ISA-101 (HMI design standard) colour conventions:
- Red: Abnormal, alarm, emergency, fault. Reserve red exclusively for conditions requiring immediate operator attention. Never use red as a decorative or brand colour in an HMI.
- Amber/Yellow: Warning, pre-alarm, caution. Conditions that require awareness but not immediate action. Approaching limit, degraded mode.
- Green: Normal, running, OK, enabled. The system is operating within normal parameters.
- White/Grey: Neutral state. Not running, available, inactive. Avoid using white for "OK" — green is the established OK colour.
- Blue: Informational. Used for operator-initiated mode changes, selected items, active navigation elements. Not an alarm colour.
- Flashing: Reserve for the most critical alarms only. Flashing draws attention effectively but causes fatigue if overused — limit flashing to Critical (highest severity) alarms only.
For consumer products (smart home, wearable, consumer electronics), these industrial conventions are less binding — but the principle of consistent colour semantics (one colour = one meaning) still applies.
Dark Theme vs Light Theme: Selection Guide
The choice between dark and light themes is not purely aesthetic — it depends on the application environment and display technology:
- Light theme (white/light grey background): Better in bright ambient environments where dark backgrounds look grey and text contrast is reduced by glare. Better for text-heavy information displays where reading comprehension is important. Required by some medical device regulatory guidelines for primary clinical displays.
- Dark theme (dark grey/near-black background): Better for low-light environments (vehicle cabs at night, server rooms, home automation at night). Dramatically better on AMOLED displays (power saving + infinite black contrast). Reduces eye strain in prolonged monitoring applications. Better for displaying illuminated data (gauges, charts, LEDs) against a dark field — the display acts like a real instrument panel.
For products used in variable ambient light, implement automatic theme switching or manual brightness control. Automotive instrument clusters universally implement day/night mode — bright white theme during daylight, dark theme at night (triggered by light sensor or vehicle daytime running lights signal).
Colour Asset Management in Embedded GUI
Colours in Flint UI Designer are defined as design tokens — named colour values applied to widget properties. Using named tokens rather than hardcoded hex values throughout a design enables:
- Consistent colour application: "alarm-colour" is red everywhere, without per-widget colour memorisation
- Easy theme switching: Changing the token value changes the colour on every widget that uses it — the entire theme updates in one operation
- Day/night mode: Two token sets (day palette, night palette) are swapped at runtime to switch themes without touching widget definitions
Sparklet supports runtime palette switching through its theming API — the day/night colour token set swap is a single API call. Explore colour design in Flint UI Designer, see industrial HMI design examples, or request the evaluation package.