Green for success, red for error: semantic colors

Short answer

In interfaces, success is shown in green, warning in yellow or orange, error in red, and info in blue; this mapping isn't a universal law, it's a habit regulated in workplace safety signage that got carried over into the interface, and it breaks down in some contexts. In a product whose brand color is red, an error message can't be distinguished by color alone; icon, text, position, and shape have to work together, and the error red has to be defined as its own token, separate from the brand red. Status colors grow stronger as they get rarer: when everything warns with color, the user stops seeing the warnings.

The four roles

In UX-01, you saw that semantic tokens are named by their role, not by their color value. In almost every interface, a small subset of these roles is set aside to tell the user about a status.

Success says that an action has completed: the form was submitted, the payment was received, the file was uploaded. Warning says that something isn't wrong yet but needs attention: the battery is low, the subscription is about to end, the password is weak. Error says that something has gone wrong and the user needs to do something: the card was declined, a field was left empty, the connection dropped. Info conveys a status without judgment: a new version is available, maintenance will begin at eleven o'clock.

Warning and info are defined the same way; warning is usually chosen from a range running from yellow to orange, and info from blue. Yellow stays low in readability when used as a text color on a white background, which is why the warning role is often built as a yellow background with dark text on top, or as a darkened orange.

Where the "universal" codes come from

These mappings aren't an invention of interface designers. Red's meaning of danger and stop, and yellow's meaning of caution, have long been regulated as safety signage in workplaces and public spaces. The US workplace safety regulation defines a color code for marking physical hazards: red is the base color for fire-extinguishing equipment, danger, and emergency stop buttons on machinery, while yellow is the base color for caution and for physical hazards like tripping, falling, or being caught in between. At the international level, ISO 3864 regulates safety colors and the design principles of safety signs.

The interface inherits this habit. When a user sees a red border on a form, they apply what they learned from seeing a red sign on a road. This inheritance works, because a learned mapping doesn't need to be taught again.

But the word "universal" has to be used carefully. The meaning of a color changes with context: red can be an error in an interface, a celebration on a congratulatory screen, or just the name of a data series in a health app. Which color shows a rise and which shows a fall in financial charts varies from market to market, and in some East Asian markets a rise is shown in red; the detail of these codes is the subject of EC-13. For cross-cultural color meanings, TK-14 gives a broader framework. The lesson to draw for interface design is this: the established mapping is a starting point, and it can't be assumed correct for the user's context without testing.

Color isn't enough on its own

The biggest weakness of status colors is that all four are often distinguished by color alone. Two problems come together here.

The first is color vision differences. For someone with difficulty distinguishing colors on the red–green axis, success green and error red can look very close to each other; these differences themselves are the subject of the BI series. The second is lightness. When a commonly used error red and a success green are measured, their lightness values can come out nearly identical: the WCAG contrast ratio between #D32F2F red and #2E7D32 green is about 1.03:1. For someone who can't see hue, these two colors are two copies of the same gray. The black-and-white test from DT-01 is useful here too: turn the status colors to gray; if they all look the same, the interface is speaking with color alone.

That's why a good error message isn't just red: it also carries a warning icon next to it, a sentence that says what happened, and a position right below the problem field. A success message can carry a checkmark, a warning a triangle, info the letter "i." Color reinforces these cues; it doesn't replace them.

If your brand color is red

The question on the lesson card asks about a conflict many products genuinely face: if your brand color is red, how do you distinguish your error messages?

If the brand red is everywhere — on buttons, headings, and accent elements — error red can't carry a separate meaning on the screen. When the user sees a red border on a field, they can't tell whether it's an error or just the brand's decoration. Several approaches can be used together.

A separate token is defined for error and set clearly apart from the brand red: a darker red, or one with a slightly different hue, or, conversely, the brand itself uses red more sparingly outside of error, only on large surfaces. This keeps the two reds from being confused in the same role, but it isn't enough on its own.

The error's shape is kept separate from the brand's. If the brand red lives in filled buttons and in the logo, the error lives as a thin line under a field, an icon, and a line of text; the two don't share the same shape.

The error is carried by non-color cues. The icon and the text describe the error no matter what the red is. Even if the user mistakes the color for the brand color, they read the sentence "Card number is missing."

Position and timing are used. The error appears right next to the problem field, the moment the user takes an action; brand elements, by contrast, stay in the page's fixed spots.

None of these approaches is the one right answer; the team chooses a mix based on how heavily the brand uses red, and tests the result with users, including those with color vision differences.

Alert fatigue

The last trap with status colors is overusing them. If every small piece of information turns into a yellow box, every missing field into a red border, and every routine confirmation into a green band, the user stops reacting to these colors.

This concept is best documented in hospitals, for audible alarms, but the principle carries over to visual alerts too. A 2013 alert from the Joint Commission, which accredits hospitals in the US, writes that hundreds of alarm signals can be generated for a single patient in a day, that an estimated 85 to 99 percent of these signals don't require clinical intervention, and that as a result, clinicians become desensitized to the sounds.

The conclusion for interfaces is clear: a status color carries meaning when it's rare. For the info role, plain text is chosen over colored boxes; for warning, only situations that genuinely need attention; for error, only moments when the user has to do something. In an interface where red rarely appears, red gets read when it does appear.

Example — the face verification frame

A banking app asks the user for a face photo when opening an account. An oval frame sits over the camera image: it turns green when a face is detected and red when it isn't. There's no other cue.

The calculated contrasts show the problem. #D32F2F red separates from a light skin-tone sample, #F1C7A9, at about 3.2:1, but against a medium-dark skin-tone sample, #8D5524, the ratio drops to 1.22:1; #2E7D32 green stays at 1.18:1 against the same skin tone. In other words, for a user with medium or dark skin, the frame is barely visible against the edge of their face regardless of its color, and the difference between red and green is carried by hue alone, with no lightness difference.

The team rebuilds the frame. The oval gets a two-layer edge made of a white line on the inside and a dark line on the outside: the white line carries the boundary against dark skin tones, the dark line against light ones. The status is reported with a sentence written below the frame and an icon: "Your face was detected" next to a checkmark, "Move your face closer to the frame" next to an arrow. Color is still there, but it only reinforces these cues. The result is tested on a set of images shot across skin tones from light to dark and under different lighting.

Common misconception

Summary

1. The four status roles are shown with the green, yellow-orange, red, and blue mappings inherited from safety signage; this mapping is a starting point and breaks down depending on context.
2. Status isn't reported by color alone; icon, text, position, and shape work together, and in a product with a red brand color, error red is defined with its own token and its own shape.
3. Status colors carry meaning when they're used sparingly; for elements that appear against skin, a colored frame is reinforced with a two-layer edge and written status information.

Test yourself

1. (Easy) What are the four most common status roles in interfaces?
2. (Easy) What does WCAG 2.2's criterion 1.4.1 require for color?
3. (Medium) If your brand color is red, how do you distinguish your error messages?
4. (Medium) What is alert fatigue, and how does it affect the use of status colors?
5. (Hard) If the contrast ratio between #D32F2F red and #2E7D32 green is about 1.03:1, what does that mean for a status indicator?
6. (Hard) Why shouldn't a face verification frame be built with only red and green?

Answers

1. Success and error, and between them, warning, and info for neutral reporting ("The four roles").
2. That color not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element ("Color isn't enough on its own").
3. A separate token is defined for error, clearly set apart from the brand red; the error's shape is kept separate from the brand's, it's carried by an icon and explanatory text, and it's shown right next to the problem field the moment the user takes action. Which mix is chosen depends on how much the brand uses red, and it's tested with users ("If your brand color is red").
4. It's the desensitization of a person who encounters a large number of alerts, most of them unimportant, to alerts in general; status colors should be used only when genuinely needed, and plain text should be preferred for info ("Alert fatigue").
5. The two colors' lightness values are nearly identical; for someone who can't distinguish hue, or on a grayscale screen, the two look the same. Success and error are being distinguished by hue alone, and a non-color cue is needed ("Color isn't enough on its own").
6. Against medium and dark skin tones, both colors' contrast is very low — for example, 1.22:1 and 1.18:1 against #8D5524; the two colors are also distinguished by hue alone. A two-layer edge and written status information let the frame stay visible on every skin tone and let the status be read independent of color ("Example — the face verification frame").

Sources

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," success criteria 1.4.1 and 1.4.11.
• OSHA, 29 CFR 1910.144, "Safety color code for marking physical hazards."
• ISO 3864-1, "Graphical symbols — Safety colours and safety signs — Part 1."
• The Joint Commission, "Medical device alarm safety in hospitals," Sentinel Event Alert, issue 50, April 8, 2013.

Next step

UX-03 carries status colors into the dark: it covers why saturation gets lowered when generating a dark theme from the same token structure, how the error and success colors built in this lesson are readjusted on a dark background, and how dark surfaces relate to energy use on OLED screens. UX-04, in turn, moves from status to interaction: it asks how a color should change when a button is hovered, pressed, given keyboard focus, and disabled, and how faded a disabled element can be.