Put a Name Next to a Value and People Read the Name

Clad turns two questions and one photo into a personal colour card. At the centre of the card are eight colours that suit your season and four to keep away from your face. It is the part people look at longest, and the part they actually pull up again when buying a shirt or choosing a lipstick.

Recently I re-picked every one of those colours. Not only because a few were wrong. Looking closely at the table, I saw that the name attached to each colour had been keeping everyone, me included, from looking at the value underneath. This piece is less about colour than about that structure.

A plausible name over a wrong value

The seasonal recommendations were web default colours: navy, crimson, steelblue, the colours a browser understands by name alone. The names sounded right. Anyone reading or reviewing the table thought "navy for winter, sure" and moved on. But those values are rare in real clothing and cosmetics. Every one of the eight winter recommendations was that kind of value.

Worse was the mismatch with the text. The winter description said "vivid or achromatic", and the recommendations included a muddy blue-grey. Someone who read the sentence expected clear colour; the screen showed a dull one. Both sat on the same result card.

The reason this survived is simple. When a name and a value sit side by side, people read the name. A value is a string of digits; reading it does not put a colour in your head. So review happens against the names, and the values ship without ever having been reviewed.

None of this was hidden. The values were in the file the whole time, one line under each name, and anyone could have opened it. That is what makes the pattern worth naming: the problem was not missing information but where attention goes when a readable word sits next to an unreadable number.

Same name, different values

It also turned out that the colour values did not live in one place. Two tables each held a colour under the same name, with different values. Winter's colour to avoid, "beige", was beige in one table and very nearly white on screen.

Because the names matched, nobody suspected the two differed. The name held the tables together so they looked like one, while underneath the values had drifted apart. The app I am building held its own palette as well. One name could point at three different values in three places.

Changing the colours was not enough

The easy fix was to replace the colours with better values, and I did. Every recommended colour and every colour to avoid is now one you can actually buy, in fabric dye or in lipstick. But replacing them alone would let the same thing happen again. The next time someone added a colour, it would still be reviewed by its name.

So I did two things together. First, I turned what each season's description says — warmth, lightness, vividness — into numeric rules. Every recommended colour has to pass them, and a colour that fails breaks the check. Put a muddy blue-grey into winter now and a test stops it before a person has to notice. Second, I made every colour value come from a single table, and merged the app's separate palette into the same values.

The two had to come together. A rule checked against one table means little if the screen draws from another; it would pass on the value nobody sees. The rule makes the value keep the promise in the description, and the single table makes sure the value that was checked is the value that is shown. Either one alone leaves a gap the name can hide in.

I also had to decide which side was the reference. When the description and the colours disagreed, I could have rewritten the description to fit the colours. But that description is text the diagnosis model reads; change it and the verdicts move. So the description stayed, and the colours were made to follow it. There had to be one reference, and it had to be the side more things were already leaning on.

Names are never checked

What stayed with me is less a lesson about colour than about data. Data that pairs a name with a value is everywhere: a config key and its setting, a product name and its price, a label and its number. In every one of those places people trust the name and skip the value, and the more plausible the name, the more they skip it.

So I now want something other than a person to confirm that the value keeps the promise the name makes. If the description and the data do not check each other, the value stays quietly wrong under a convincing name. And the first person who really looks at that value is usually the one in front of the screen.