One Warm Colour
A visual reset that threw out an aesthetic I had said I liked. One colour reserved for the person's own marks, which the system never uses to talk about itself.
Date
Category
Writer
The product used to be warm brown and monospace. Pixel-adjacent, terminal-adjacent, slightly retro, and a direction I had explicitly said I liked.
I threw it out, and the instruction I wrote for myself at the top of the round was deliberately harsh:
An old aesthetic preference is not a product identity, and must not be used as a constraint on this round.
That sentence exists because I know how I work. Given any constraint that references something I previously enjoyed, I will protect it, and I will produce a good-faith argument for why protecting it was the right call.
Why the warm terminal had to go
Monospace-everywhere had been justified as honesty. The same voice as the machine. No decoration, nothing dressed up.
The trouble is that monospace is not neutral. It is a costume, and the costume says terminal, code, developer tool, this was made by and for people who write software.
Setting a person's own handwritten note in monospace does not make the note honest. It makes the note look like output.
Which is precisely backwards, because the note is the one thing in the entire product that is not output. It is the only text in there that a machine did not produce.
The system that replaced it
A cool neutral room, and one warm colour, with a single rule attached that decides every use of it:
The warm colour is reserved for the person's own marks. The system never uses it to talk about itself.
The warm colour appears on | It never appears on |
|---|---|
Your name for a thing | A status message |
Your reason for keeping it | A system label |
A search match | Machine-read extraction |
A pin you placed | A count or a badge |
An undo you triggered | An error, a heading or a button |
Table 1. Colour doing semantic work rather than decorative work.
Glance at any screen and the warm marks are your handwriting on it. Everything else is the room.
I like this more than any individual visual decision in the product, because it is a rule rather than a taste. A new feature does not require a colour discussion. It requires one question: is this the person's mark or the system's voice. The answer determines the colour, and there is no third option.
The rest of the material system
Six depth steps. Not a shadow scale invented per component. Six, named, and everything sits on one of them.
Five type sizes, from 11.5 to 26px. Five. The constraint is the feature: a sixth size is a request to justify why the existing five could not carry the hierarchy.
Monospace kept for exactly one purpose: strings a machine wrote. A hash, a filename, an extracted value, a dimension.
That last one is the redemption of the discarded direction. Monospace is now a signal that something was generated rather than authored. That is a real distinction doing real work, instead of a general mood applied to everything.
The cat survived with its behaviour untouched, but desaturated and given a contact shadow, so it sits in the room rather than floating on top of it.
The card, which was most of the work
The old card was built around the filename. IMG_3928.png, large, first, as the primary identifier.
The filename is the least meaningful thing about a kept object. It is usually generated by a camera, frequently wrong, and almost never chosen by anyone. Designing around it means designing around a machine's serial number and calling it the thing's identity.
The new hierarchy, in strict order:
# | Layer | What it is | Why here |
|---|---|---|---|
1 | Recognition | The actual image, real preview, genuine excerpt | You recognise your own things instantly. Nothing beats it |
2 | Meaning | Why you kept it, if you said | The only thing no system can reconstruct |
3 | Context | Facts already derived. Nothing new invented | Useful, and must not grow to fill the space |
4 | Identity | The filename. Small, last | Occasionally needed, never the protagonist |
Table 2. That ordering is the entire redesign. Everything else followed from it.
Two constraints set to avoid the usual failures
The original must still read as original
A photograph in the collection should look like a photograph someone took, not like something the product generated.
This is harder than it sounds. The more a design system unifies its cards, the more everything begins to look like the system's output rather than the person's belongings. Consistency, pushed one step too far, quietly annexes the content. You end up with a beautiful grid in which a wedding photo and a receipt have the same visual weight, the same corner radius, the same treatment, and therefore the same emotional temperature.
The fix was to let the content break the system rather than the reverse. A photograph gets to be a photograph, at its own aspect ratio, without a frame.
Understanding should be quiet intelligence, never fifteen badges
When a machine reads a PDF's page count, extracts a document's text, decodes an audio waveform, the temptation is to display every derived fact, because each one was work and the work was hard.
The result is a card wearing its own computation as jewellery. What the person needs is to recognise the thing. Almost everything else belongs in detail, on request.
There is a general principle here that I have not seen stated well anywhere: the visibility of a derived fact should be proportional to how often it is needed, not to how difficult it was to produce. Those two are frequently inversely correlated, and engineering effort exerts a quiet gravitational pull on layout that nobody defends out loud.
The constraint that made the round work
The rule at the top of the round was negative: zero new features, zero new flows, zero new data, and no weakening of anything that already worked. Visual language only.
That constraint is worth stealing.
When visual and functional changes are permitted in the same pass, every visual problem has a functional escape hatch. The layout is confusing, so add a label. The hierarchy is unclear, so add a filter. The card is ambiguous, so add a badge. You end up solving design problems with features, which is how products grow heavy while appearing to improve.
Forbid the escape hatch and you are forced to solve the actual problem, which was almost always hierarchy in the first place.
And one last constraint, which mattered most: completion is judged by the screen, not by test counts. There was no number that could tell me this round had worked. I had to look at it, on several devices, over several days, and decide.
That is uncomfortable for a process that otherwise runs on evidence, and it is correct. Some things are only knowable by looking.
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
