The Stroop Effect: when a label and its colour disagree
The Stroop effect is the delay and error rate you get when you have to name the colour of a word whose meaning is a different colour — “red” printed in blue. It matters in interfaces because reading is automatic and colour-checking is not, so when a control’s label and its colour disagree, people act on one, notice the other late, and make mistakes they find hard to explain.
What it is
John Ridley Stroop published the original work in the Journal of Experimental Psychology in 1935, and it is worth knowing that it was three experiments rather than one, because the comparison between them is the part that matters for design.
In the first, participants read colour words aloud — words printed in black, against the same words printed in a conflicting ink colour. Having the ink disagree with the word barely slowed the reading. In the second, the task was reversed: name the ink colour, either of a plain coloured square or of a colour word naming a different colour. Here the interference was large. Naming the ink of the word “red” printed in blue took substantially longer than naming the colour of a blue square. The third experiment looked at what practice did to both.
That contrast is the finding, and it is asymmetric. The word intrudes on the colour; the colour does not much intrude on the word. Any account of the effect has to explain the one-way street, and the standard one is automaticity: for a literate adult, reading is not a task that gets chosen, it happens the moment the eyes land on a word. Naming a colour is deliberate by comparison. The automatic process wins the race and its answer has to be suppressed before the deliberate one can be given.
Colin MacLeod’s 1991 review in Psychological Bulletin gathered half a century of replication and remains the standard reference. The effect survives knowing about it, survives being warned about it, and shrinks with practice without disappearing — which is the finding that disposes of “our users will learn our colour scheme” as a remedy.
The asymmetry has a direct design consequence that is usually missed. A user who is reading your label is relatively protected from a contradicting colour. A user who is judging by colour is not protected from a contradicting label — but they are unlikely to be reading it at all, which is precisely why they are going fast. So a mismatch does not confuse everyone equally: it quietly sorts your users into those who will act on the text and those who will act on the colour, and sends the two groups in different directions.
None of this is confined to laboratory colour cards. Any interface that encodes the same meaning twice, once in words and once in colour, is running a small Stroop experiment on every user. It stays invisible for exactly as long as the two encodings agree.
Why it works on people
Interfaces lean on colour because it is scannable. You can find the red thing in a list without reading the list. That is exactly the property that makes conflict expensive: colour is processed fast and pre-attentively, text is processed slightly later but carries the authoritative meaning.
So a user scanning quickly acts on colour, and a user reading carefully acts on the label. When those disagree, the interface has quietly split its audience into two groups who will do different things — and neither group is being careless.
The cost is rarely a total failure. It is a small hesitation, a second look, and an occasional wrong click. That makes it hard to catch in testing, because the task still gets completed and nobody reports “the button was the wrong colour”.
Most production conflicts are not decisions anybody made. They are two template expressions that read two different fields, and the fields drifted apart — a badge coloured from a status enum next to a label written from a different one, or a cached value rendered beside a fresh one. Nobody chose to put a green tick on a failed job; the two halves of the component were simply never required to agree.
The conflict is also worst exactly where the stakes are highest. Destructive confirmations, payment states, security warnings and system health are the places where colour is used most aggressively as a shortcut, which means they are the places where a mismatch does the most damage per occurrence.
And the effect compounds with the other conflict costs an interface imposes. A mismatched label is one competing signal; put it on a control adjacent to its opposite, or on the far side of the screen from the thing it governs, and you have stacked semantic conflict on top of spatial conflict. The flanker and Simon pages cover those two, and they add rather than overlap.
Where you meet it
- A destructive action styled in the same colour as the primary confirm action, so “Delete” and “Save” both read as the safe thing to press.
- Status dashboards where a green badge sits next to the word “Failed”, usually because the badge colour is driven by a different field than the label.
- Dark-pattern consent dialogs that deliberately colour the privacy-preserving option grey and the data-sharing option in the brand colour, so the eye is pulled to the choice that benefits the site.
- Charts whose legend colours are reassigned between views, so the series that was green a moment ago is now red while keeping the same name.
- Form validation that turns a field green while displaying an error message inside it.
- Toggle switches whose “on” state is coloured with the brand accent while the setting being turned on is the restrictive one, so the reassuring colour marks the more limiting choice.
- Diff and version views where added and removed lines keep conventional green and red, but a theme swaps the hues without swapping the labels.
- Financial interfaces shown to an international audience, where a rise is conventionally green in some markets and red in others, while the accompanying sign or arrow follows the other convention.
- Severity badges reused across products with different scales, so “warning” is amber in one screen and red in the next while meaning the same thing.
Designing around it
- Make colour redundant, never load-bearing. WCAG 2.2 success criterion 1.4.1 requires that colour is not the only visual means of conveying information — but the stronger design rule is that colour and text must never point in different directions, even when both are present.
- Derive the colour and the label from the same source value. Most real Stroop conflicts in production are not design decisions; they are two template expressions reading two different fields that drifted apart.
- Reserve one colour for one meaning across the whole product, and treat destructive actions as a colour reserved for destruction. If “red” means both “error” and “brand accent”, you have guaranteed conflicts.
- When you must show a mismatch honestly — a red item in a list titled “Healthy”, say — add an explicit reason next to it rather than letting the user resolve the contradiction themselves.
- Test with the colour removed. If a greyscale screenshot leaves the interface ambiguous, colour is doing work that text should be doing.
- Let the text carry the decision and the colour reinforce it, which is what the asymmetry in Stroop’s own data argues for. The word is the stronger automatic signal, so a design in which the label is sufficient on its own degrades gracefully; one in which the colour is sufficient on its own does not.
- Write a test that asserts the pairing rather than trusting review to catch it. If a status maps to both a colour and a label, that mapping is a single table, and a unit test over it is cheaper than any amount of visual QA.
- Do not rely on users learning your palette. Practice reduced the interference in Stroop’s third experiment without removing it, and every subsequent replication agrees. Familiarity buys you a smaller hesitation, not a safe one.
Questions
What is the Stroop effect?
It is the measurable delay and increase in errors when you name the colour of a word whose meaning names a different colour — for example the word “red” printed in blue. Reading happens automatically, colour naming does not, and resolving the conflict between them takes time.
Why does the Stroop effect matter in user interface design?
Because interfaces routinely encode the same meaning twice, in words and in colour. While the two agree, colour makes the interface faster to scan. The moment they disagree — a green badge on a failed job, a red confirm button — users split between acting on colour and acting on the label, and some of them act wrongly.
Does the Stroop effect go away with practice?
It shrinks but does not disappear. Half a century of replication shows the interference persists even in people who know exactly what is being done to them, which is why "users will learn our colour scheme" is not a fix.
Why is the Stroop effect asymmetric?
Because the two tasks are not equally automatic. Stroop’s first experiment had participants read colour words printed in conflicting ink and found the ink barely slowed them; his second had them name the ink of a conflicting word and found a large cost. Reading is automatic for a literate adult and colour naming is deliberate, so the word intrudes on the colour but not the reverse — which is the argument for letting the label, not the colour, carry the decision.
Is using colour in an interface bad?
No — colour is one of the few genuinely pre-attentive channels available, and removing it makes interfaces slower to scan. The rule is that colour should be redundant with the text, never in competition with it.
Sources
- Stroop, J. R. (1935). Studies of interference in serial verbal reactions. Journal of Experimental Psychology, 18(6), 643–662. The original experiment. Establishes that naming the ink colour of an incongruent colour word is slower than naming a congruent one.
- MacLeod, C. M. (1991). Half a century of research on the Stroop effect: An integrative review. Psychological Bulletin, 109(2), 163–203. The standard review. Useful for the automaticity account and for how consistently the effect replicates.
- W3C. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.1: Use of Color. The accessibility requirement that colour must not be the sole carrier of meaning. Related to, but narrower than, the design rule above.