Visual Language Through Style Tiles

What this topic is for

Before building any meaningful UI, a commitment has to be made about what the thing should look and feel like. Without that commitment, every downstream decision — typography, color, density, radius, weight — gets made ad-hoc, and the result is generic because it is generic: an average of defaults, with no point of view.

This topic establishes that commitment. It guides a conversation with the user that moves from what users should feel and think when they use this thing to which visual attributes produce those responses to several candidate directions for the visual language, then renders those directions as style tiles the user can compare side-by-side and iterate on until one wins.

Style tiles were introduced by Samantha Warren in 2012 as a design deliverable that sits between mood boards (too vague) and full mockups (too specific). A style tile references interface elements through font, color, and style collections — enough to convey a direction without committing to layout. Read Warren's original article for the clearest explanation of what they are and why they work.

The method

Style tiles used as design alternatives. You establish with the user what the design should evoke, translate that into visual attributes, propose several candidate directions, render each as a style tile on a single page for side-by-side comparison, and iterate — first going wide to explore the space, then narrowing in on one.

This topic uses the design-alternatives skill to render and iterate on the tiles. That's where the N variants on a single HTML page, the commenting, and the iteration loop live. This topic handles everything else: the opening conversation, the intake, the filtering of approval words from real directions, the translation into visual attributes, the proposal of divergent candidate directions, and the management of divergence and convergence across iterations.

Canonical worked example

Before following the steps below, read style-tiles.example.md. It's a concrete walk-through of the opening of this topic applied to a real project — a Unicode character utility being restyled — showing what a good run actually looks like in conversation. The steps in this document describe the shape of the work; the example shows what it looks like when done well. Read the example first; the rest of this document will land better.

Before you start

Confirm with the user

If the user explicitly asked for visual design work, proceed straight to the intake.

If this topic is firing implicitly (the user is building or changing UI without having asked for a visual direction exercise), raise the option first. Explain the method, the value, and the cost, and let the user decide:

"Before I start making visual choices, I can run a visual direction exercise with you — we'd generate a few style tile options, you'd pick one, and then everything I build from here is grounded in that direction. Takes maybe 15–20 minutes of back-and-forth. Or I can skip it and just use sensible defaults. Your call."

If the user skips, make defensible default choices rather than improvising a visual language ad-hoc. Pick one solid typography + neutral palette + standard component library that fits the stack (shadcn, Tailwind defaults, etc.). Don't invent.

Talking to the user

Don't assume the user shares design vocabulary. Jargon makes them feel like they need to translate before they can engage. Use plain language — "look and feel" instead of "visual language," "exploring options" instead of "diverging," "zeroing in" instead of "converging." If the user uses design jargon themselves, mirror it back.

But don't shrink your expertise to the user's vocabulary. References they haven't heard of (design systems, designers, publications) stay in the conversation — style tiles will make them concrete. The user being guided into unfamiliar territory is part of the value.

The steps

1. Intake

New or restyle? If restyle, ask to see or have the user describe the current design early. Understanding what's failing is real signal about what the new direction needs to answer for. But park the diagnosis before running step 2 — you'll come back to it. Defining what the thing should feel like has to happen before letting the current version's failure lead the thinking.

The surface, described concretely. What is this thing and what does it do? Specific about purpose and function, not layout. Layout is downstream.

Constraints that can't change. Brand elements, accessibility floors, platform conventions, existing tokens or components to respect.

Don't treat the intake as a form. It's a short conversation that makes sure you're operating on the actual project, not an imagined one.

2. Describe what users should feel and think

The first real design step. Elicit the intended response — what users should feel and think when they encounter the design. Not visual attributes yet. Ask in plain terms, with examples that anchor the kind of answer you're looking for:

"What do you want your users to evoke in people using this? Feelings, emotions, reactions. For example, a meditation app might aim to evoke calm and spaciousness; a trading terminal might aim to evoke urgency and control; a reading app evokes quiet focus."

Let the user give a rough, messy answer. Play it back as a list. Then filter.

Filter with the opposites test

Some words the user gives you will point at real, specific directions. Others will be approval words — words that just mean "good" without committing to a direction. Approval words feel meaningful to the user but can't be designed from; they produce generic outputs.

Motivate the test before running it. Explain why you're filtering — approval words sound like commitments but aren't. Don't impose the filter as a linguistic rule, introduce it as a tool that makes the rest of the process actually work.

The test: can you name a real, meaningful opposite of the word? Something a different project might legitimately pick?

• Quiet → loud. Real choice. Meaningful.
• Efficient → lingering. Real choice.
• Typography-forward → chrome-forward. Real choice.
• Refined → unrefined / crude. Pejorative. Nobody picks it. → approval word.
• Well-designed → badly designed. Pejorative. → approval word.
• Modern → outdated. Pejorative. → approval word.

When a word fails the test, probe. Don't just discard it — ask what the user is reacting against. "When you say fresh, what are you reacting against? Trendy? Dated? Boring?" Specific answers usually pull a real direction out of an approval word. Fresh is an approval word alone but "quietly current but built to last" is a real commitment.

When probing doesn't yield a real direction, set it aside as a quality bar. "Deliberate" is approval — but the user meant "designed, not accidental." That's not a direction; it's a standard. Hold it as a quality bar you're applying to whatever direction you pick, and move on.

After filtering, play back the set that survives. Confirm with the user. But also audit internally: are these directions actually actionable, or did some approval words slip through? If they did, push more before moving on.

3. Translate into visual attributes

Turn the response commitments into visual qualities the design will have to produce them. This is a conversation, not a monologue — but you're the expert making the first pass, and pretending otherwise wastes the user's time.

Propose a first pass, making the translations explicit. For example: efficient → restrained chrome, tight type system, no motion theater. Typography-forward → type as hero, chrome recedes. Hold the proposal loosely; let the user push back, sharpen, add.

If there's a parked diagnosis from the intake, bring it back here. "Why the current monochrome green isn't working" becomes useful context for the translation — it tells you what traps the new direction has to avoid.

Look for the user's additions. Users often have specific commitments they haven't articulated yet. When they add one ("the glyph has to be the hero"), that's a real visual attribute to incorporate, not just commentary.

4. Propose candidate directions

Now you propose several different visual directions, each built around the same user responses and visual attributes, but each committing to a different visual language.

This is the divergent phase. Three rules:

Each direction goes hard in one direction. No synthesis. "Typewriter" and "classical printed page" look related — both are "ink on paper" — but they're different arguments (the machine vs. the craft). Keep them separate. Synthesis happens in convergence if at all; during divergence, every direction commits to one thing and pushes.

Spread across the map. Actively fight clustering. If your proposed directions all share an implicit assumption (e.g., all monochrome, all Western-type-oriented, all minimal), you're not exploring — you're producing variations on one idea. If you catch yourself clustering, reopen the map explicitly.

Explode regions rather than treating them as single directions. "Expressive" isn't a direction, it's a continent. "Playful," "maximal," "editorial bold," "digital-native" are directions. Whenever you reach for a direction that feels like a category, break it into its specific flavors.

Include more directions than feels comfortable. Eleven divergent directions is not too many — it's the kind of range that actually teaches the user the space. Three is the minimum for divergence.

Include directions the user probably won't pick. Boundary directions — ones that feel "too much" on some axis — help clarify what "just right" is. You don't need to warn the user about this up front; when you get to rendering, explain in that moment that some directions are intentionally pushed past comfort.

Show the directions to the user, let them react, edit, cut, add, reorder. Once approved, proceed to rendering.

5. Render as style tiles

Hand the approved direction list to the design-alternatives skill to render. Pass it:

• A short brief for each direction (the commitment it's making and why)
• The load-bearing components the tile has to feature (from the intake)
• The format expectation (single HTML page, all tiles on it, each labeled)

Only the visual language changes across tiles. Everything else is held constant.

When presenting the rendered tiles to the user, this is the moment to explain that some of the directions are intentionally pushed past comfort. Frame it as: the early rounds are about finding boundaries; seeing "too much" helps clarify where "just right" is. If they'd rather dial back, that's easy; picking from safe-only options risks not knowing what the range actually is.

6. Iterate — divergence first, then convergence

Read the user's reaction and plan the next move.

Still diverging: user is still exploring, wants to see more territory, isn't ready to narrow. Generate more candidate directions covering ground that hasn't been seen yet.

Starting to converge: user signals a direction ("I like #3" or "combine #2 and #7's type") or reacts against others ("not #4 or #5, they're the wrong register"). Generate tighter variations around the signal. Smaller moves. Less variety. Each new generation zeroes in.

Re-diverging: user realizes during convergence they want to explore more. Fine — it's a new divergent pass, possibly with updated responses or attributes based on what they learned.

At divergence, vary maximally. At convergence, vary minimally. If convergent rounds start varying more, something went wrong — probably a missed signal about what the user actually wanted.

Remember across iterations. Re-read the conversation each pass so convergent passes know what was already rejected and why. Don't re-propose ideas the user already dismissed.

7. Exit

This topic ends when the user says "this one." The output is the chosen direction plus the tile HTML. This topic does not convert the direction into tokens, CSS, or a design system — that's a different job.

Further reading

• Style Tiles and How They Work — Samantha Warren, A List Apart, 2012. The original article introducing style tiles.
• Reading Is Fundamental Element Collages — Dan Mall. An evolution of style tiles that brings in more interface-specific treatments; useful when the tile needs to convey more of the application's actual surface.
• Visual Inventory — Dan Mall. On abstracting the question from "what should this look like?" to "what should this feel like?" — the same move step 2 makes.