Brand & Surface
Brand and surface
What you see and how it sounds. Radical minimalism, typography, studio voice and translation that preserves meaning. XNLAB's aesthetic judgment applied to everything.
BS-01 Radical minimalism
lesson Audit a real screen and deliver a before/after where every element you removed is justified by a decision, not by taste.
Radical minimalism
lessonAudit a real screen and deliver a before/after where every element you removed is justified by a decision, not by taste.
XNLAB's radical minimalism is not an aesthetic: it's a decision method. Most operators believe that "cleaning up" an interface means lowering opacities and adding whitespace. It's actually the opposite: every element that survives has to earn its place by answering a concrete question (what is the user doing here? what decision are they making?). Surgery, not decoration. Without an explicit method, "minimalist" degenerates into "empty and arbitrary," which is worse than cluttered: it looks careless. The antidote is an audit with written criteria, where removing something is a defensible, reversible action rather than an impulse.
THE LESSON
Radical minimalism is a method of elimination, not a visual style. The default is to remove; adding is the exception, and it carries the burden of proof.
Every element on a screen has to answer a question the user has at that moment. If it answers none, it's noise no matter how attractive it is.
A before/after with no written justification is an opinion. With justification it's an audit: defensible in front of a client, repeatable by someone else, reversible if the data contradicts it.
Arbitrary emptiness (lowering opacity, adding whitespace for no reason) reads as carelessness, not sophistication. Minimalism done badly looks like a broken page.
The XNLAB rule is conservative but not dogmatic: the default is surgical editing, revisable with conversion data, not a moral law.
EXERCISE
Take a dense screen that already exists (a landing page, a dashboard, a form; MOONKEY's own screens work fine). Capture the current state as the 'before'. List every visible element in a table. For each one, answer in a single line: what user decision does this serve here and now? Mark as a removal candidate anything that answers nothing. Apply the cuts and capture the 'after'. Next to each removal, write the reason (redundant / answers no decision / movable to another view / decorative with no function). Verify that no cut broke a task the user actually needs to complete.
DELIVERABLE
A before/after audit of a real screen: the two captures, the element table with each element's user-question, and the list of removals each with its written one-line justification. Reversible: anyone can read why each thing was removed and undo it if data contradicts the call.
KEY INSIGHT
Removal is the hardest decision to defend because it leaves no trace; that's why you write the reason before deleting, not after. The audit turns minimalism from opinion into method.
MISTAKES TO AVOID
- ×Mistaking minimalism for lowering opacities and adding whitespace: that's arbitrary emptiness, not surgery. The result looks careless, not premium.
- ×Removing elements that actually hold up a user task and breaking the flow in pursuit of visual cleanliness.
- ×Not documenting the reason for each cut: without written justification the audit is irreversible and can't be defended to the client.
- ×Treating the rule as an unbreakable moral law instead of a default that's revisable with conversion data.
BS-02 Typography with intent
lesson Build a pair of headlines that mix Inter sans with italic-serif spans (Cormorant) without the eye detecting the jump, and document the size correction that makes it work.
Typography with intent
lessonBuild a pair of headlines that mix Inter sans with italic-serif spans (Cormorant) without the eye detecting the jump, and document the size correction that makes it work.
Mixing a sans (Inter) with an italic serif (Cormorant) inside the same headline is one of the highest-return and most treacherous typographic moves. The concrete, verified trap at XNLAB: the italic serif has a smaller x-height, so at the same font-size it looks optically smaller and the headline appears broken, as if the italic were sinking. The operator who doesn't know the adjustment leaves it like that, and the result grates without their knowing why. The correction isn't theoretical: it's an explicit font-size bump on the italic span (~1.18–1.2em) to match the perceived height. Knowing this is the difference between typography with intent and two fonts fighting each other.
THE LESSON
Nominal font-size is not perceived size. What the eye measures is x-height, and the italic serif's is lower than the sans, so at the same px it looks smaller.
The verified adjustment for Inter + Cormorant italic is a fontSize bump to 1.18-1.2em on the serif span. It's not optional: without it the headline reads broken.
The italic serif is used for one word or phrase carrying semantic weight inside a sans headline, not for random decoration. The contrast has to mark something, not just look pretty.
Typographic intent is demonstrated: the corrected span and the uncorrected span, side by side, make the problem visible and the solution undeniable.
EXERCISE
Write two XNLAB headlines where a key word goes in italic serif inside sans text (e.g., a noun that carries the meaning). Render each one twice: once with the italic span at the same font-size as the sans, once with fontSize:'1.18em' on the span. Compare the two versions side by side and confirm by eye (not by the number) which one matches the perceived height. Note the exact value that works for your type pair. If the jump is still visible, push toward 1.2em and check again.
DELIVERABLE
A pair of working italic-mix headlines, each accompanied by its 'uncorrected / corrected' comparison that makes the x-height problem visible, plus the exact line of CSS (fontSize:'1.18em' or whatever value works) documented as a reusable decision.
KEY INSIGHT
Typography with intent is noticed precisely when it goes unnoticed: if the reader perceives the jump between sans and serif, you failed. The x-height adjustment is invisible when done right and obvious when done wrong.
MISTAKES TO AVOID
- ×Assuming that same font-size means same visual size: it ignores x-height and leaves the headline sunk in the italics.
- ×Using the italic serif as decoration with no semantic weight: typographic contrast has to point at something, not fill space.
- ×Verifying the adjustment by the number (1.18em) and not by eye: the exact value depends on the font pair and the size; you have to look at it.
- ×Applying the bump globally instead of to the specific span, breaking the rest of the hierarchy.
BS-03 Studio voice
lesson Write a real page copy deck (hero + three sections) in an anonymous studio voice that passes the "truth or marketing?" test: every sentence is either verifiable or deleted.
Studio voice
lessonWrite a real page copy deck (hero + three sections) in an anonymous studio voice that passes the "truth or marketing?" test: every sentence is either verifiable or deleted.
XNLAB's voice is anonymous by design: studio, never person. There's no named founder, no bio, no photo, no "I think." This sounds easy and is the hardest thing of all: with no "I" to appeal to, the only authority left is precision. The operator's typical failure is to fill the void with smoke—"we transform your business," "exceptional results," "passion for detail"—phrases that say nothing verifiable. The studio voice rests on the opposite: claims that are either provably true or never written. XNLAB's legal status demands it literally: don't invent a tax ID, address, or registry data; mark as unregistered what isn't registered. The copy deck is the artifact where that discipline becomes testable.
THE LESSON
The studio voice is anonymous: never first person singular, never a founder's name, never a bio. Authority comes from precision, not from who's speaking.
The 'truth or marketing?' test: every sentence gets labeled. If it's verifiable, it stays. If it's an empty promise or an unsupported adjective, it's deleted or rewritten as a fact.
Empty promises ('we transform,' 'exceptional,' 'leading') are noise that lowers the credibility of everything around them, including what actually is true.
Legal honesty is part of the voice: don't invent entity data. What's unregistered is marked unregistered; the cycle is described as it is ('Open.'), not as it suits.
Anonymous isn't cold. The voice is direct and concrete—the warmth comes from rigor and from talking about real things, not from personal confessions.
EXERCISE
Pick a page (home or /contact). Write the hero and three sections in the studio voice. Then run every sentence through the test: in one column paste the sentence, in another write 'truth' (and how it's verified) or 'marketing' (and why it's smoke). Every sentence marked 'marketing' gets rewritten as a verifiable fact or deleted. Check that no 'I' slipped in, no proper name, no invented entity data. Confirm that the cycle status is described as it actually is, not as it would sell better.
DELIVERABLE
A copy deck for a real page (hero + 3 sections) with its 'truth or marketing?' test table alongside it: every final sentence classified as verifiable-truth, with not a single surviving empty promise and no invented entity data. Ready to paste into the page.
KEY INSIGHT
Removing the 'I' forces every sentence to carry the proof, not the person; that's why the anonymous voice is the most ruthless smoke detector there is. If a claim needs a name behind it to stand up, it wasn't truth: it was marketing.
MISTAKES TO AVOID
- ×Filling the absence of a founder with superlatives ('exceptional,' 'leading,' 'transformative') instead of with verifiable facts.
- ×Slipping in first person or a proper name and breaking the studio's anonymity.
- ×Inventing entity data (tax ID, address, registry) to look established: it violates the real legal status and gets detected.
- ×Mistaking anonymous for cold and writing lifeless copy: the warmth comes from rigor and from the concrete, not from an 'I'.
- ×Describing the cycle as it suits commercially ('one place remains') instead of as it is ('Open.').
BS-04 Translating while preserving meaning
lesson Produce an EN/ES pair of a copy block where the Spanish says the same thing as the English—not the literal—and deliver the notes behind each meaning decision.
Translating while preserving meaning
lessonProduce an EN/ES pair of a copy block where the Spanish says the same thing as the English—not the literal—and deliver the notes behind each meaning decision.
Translating XNLAB copy isn't swapping words: it's preserving meaning across two languages with different grammars. The documented, recurring error is the lexical mirror: translating 'Not X' as 'Sin X' when the English marked a comparison (not an absence) and the Spanish turns it into something else. Same with shifting an English passive into a Spanish reflexive, or with modifiers and verbs that drop out unnoticed. Each of those slips changes the meaning by a degree, and three degrees later the Spanish page says something the English never said. The only defense is to read each Spanish line as a native—not as a translator—and verify that the claim is the same, not that the words match.
THE LESSON
Translating is preserving meaning, not mirroring vocabulary. The right question isn't 'does this word exist in Spanish?' but 'does this sentence assert the same thing?'.
'Not X' → 'Sin X' is the headline trap: absence vs comparison. English sometimes contrasts, and 'Sin X' turns it into a lack the original never stated.
An English passive that becomes a Spanish reflexive can change who performs the action and the implied responsibility. You have to check the agent, not just the form.
Modifiers and verbs drop out in translation without warning. A lost adjective or a flattened verb lowers the temperature or shifts the force of the claim.
Quality control is reading each ES line as a native, not contrasting against the EN word by word. If it sounds like a translation, it is one; if it sounds like an original, it's right.
EXERCISE
Take a real EN block (a hero or a section with loaded claims). Translate it into Spanish prioritizing meaning. Then audit line by line: did any 'Not X' become 'Sin X', swapping comparison for absence? did any passive become reflexive and move the agent? did any modifier or verb drop? For each finding, note the decision: what the English said, what your first draft said, what you put and why it preserves the meaning. Read the final Spanish version aloud as a native and confirm it asserts exactly the same thing as the English.
DELIVERABLE
An EN/ES pair of a real block with its translation notes: for each at-risk line (Not X / passive-reflexive / dropped modifier), the documented decision on how the meaning was preserved. The ES passes a native read without smelling of translation.
KEY INSIGHT
A word-for-word correct translation can be a sentence-for-sentence lie; the lexical mirror is the fastest route to saying something the original never asserted. Preserving meaning sometimes requires moving away from the words.
MISTAKES TO AVOID
- ×Lexical mirror: 'Not X' → 'Sin X', turning a comparison into an absence the English never stated.
- ×Letting the English passive become a Spanish reflexive and shift the agent or the implied responsibility.
- ×Losing modifiers or verbs in the transfer and flattening the force of the claim without noticing.
- ×Verifying by contrasting word by word against the EN instead of reading the ES as a native: the lexical mirror passes that test and still lies.
BS-05 Color and depth
lesson Document a color-and-depth system (glass, bands, color fields) as a set of reusable rules and tokens, with samples that prove it adds life without adding noise.
Color and depth
lessonDocument a color-and-depth system (glass, bands, color fields) as a set of reusable rules and tokens, with samples that prove it adds life without adding noise.
Color and depth are where a minimalist surface gains life or breaks. Glass, color bands, and background fields can make a flat page breathe—or turn it into a carnival that contradicts the radical minimalism of BS-01. The difference between the two outcomes isn't taste: it's a system. Without written rules (when glass, what intensity, what field depth, what animates and what doesn't), every screen improvises and the whole loses coherence. There's also a verification trap documented at XNLAB: background animations pause when the tab isn't active, so an opacity read lies; animated depth is verified with a visual capture, not by reading values. The deliverable is the written system: tokens, rules, and samples anyone can apply without reinventing it.
THE LESSON
Color and depth add life only within a system. Glass, bands, and fields with no rules degenerate into noise that contradicts the minimalism.
The system is written as tokens and rules: when to use glass, what intensity, what field depth, what moves and what stays still. Reusable, not improvised per screen.
Never interpolate dynamic color classes (bg-${theme}): it breaks Tailwind's JIT. Themes are declared as explicit entries in the THEME map.
Background animations pause in an inactive tab: an opacity read returns a false value. Animated depth is verified with a screenshot, not by reading the DOM.
The criterion is 'life without noise': if a color field or a glass element doesn't add hierarchy or breathing room, it's surplus. Depth serves reading, it isn't put on display.
EXERCISE
Inventory the depth resources the surface already uses (glass, bands, blobs, background fields). For each, write the rule: when it's used, at what intensity, what hierarchy it serves, whether it animates or not. Turn them into named tokens. Render one sample with the system applied and one without, side by side, to prove the version with the system adds life without raising the noise. Verify any animated layer with a screenshot in an active tab, not by reading opacity (which lies with the tab in the background). Confirm no color is interpolated into a dynamic class.
DELIVERABLE
A documented color-and-depth system: named tokens + usage rules (when / what intensity / what animates) + a pair of with-system / without-system samples that proves 'life without noise', verified by visual capture. Reusable by any screen without reinventing the criteria.
KEY INSIGHT
Depth done right feels like air and done wrong like noise, and the only way to stay on the right side at scale is a written system, not good taste per screen. And never trust an opacity read: the sleeping tab will lie to you.
MISTAKES TO AVOID
- ×Improvising glass, bands, and fields screen by screen with no rules: the whole loses coherence and the minimalism breaks.
- ×Interpolating dynamic color classes (bg-${theme}) and breaking Tailwind's JIT, leaving styles that don't compile.
- ×Verifying animated depth by reading opacity in the DOM: the animation pauses in an inactive tab and the read value lies. You have to take a screenshot.
- ×Adding color fields or glass that add neither hierarchy nor breathing room: decoration that raises the noise and betrays 'life without noise'.
Next constellation
Ops & Security
The discipline