Someone asks for "the style guide" in week one, and what they actually need is a moodboard. Someone else calls a moodboard "the design system" and wonders why development can't build off it. The words get swapped constantly because the outputs can look superficially similar — images, colors, some type samples arranged on a page — but they're not the same tool, they don't answer the same question, and using one where you need another is a quiet, common way projects lose weeks.

The fix isn't a stricter glossary. It's understanding what each one is actually for, who it's for, and — this is the part that gets skipped — the order they have to happen in.

The moodboard: is this the right direction at all

A moodboard is for deciding whether you're pointed the right way before anyone commits real time to it. It's references, not rules: photography, competitor screenshots, textures, color that feels right, type that feels right, none of it yours yet. It's for you and maybe a client or a stakeholder, in a conversation that's still fundamentally "do we agree on the vibe."

A moodboard should never contain a hex code that anyone is expected to build with. If someone opens your moodboard and pulls a color value into production CSS, something upstream broke — that value was never meant to survive contact with real work. Its whole value is that it's disposable and fast to revise. You can throw out a third of a moodboard in an afternoon with no loss, because nothing downstream depends on those specific pixels yet.

This is also why a moodboard tends to work better as a living collection than a static deck. You're not trying to present a finished thought — you're trying to notice a pattern across twenty half-relevant references before you've fully articulated what you're looking for. A rigid slide deck locks in your first instinct. A board you can keep adding to and pruning lets the pattern show itself over a few days instead of one sitting.

The style tile: naming the direction you picked

A style tile is the moodboard's answer, condensed. Where a moodboard says "here's a range of things that feel right," a style tile says "here's the one direction, named." It's a single page: two or three colors with actual values, a heading and body type pairing set at real sizes, a button or two, maybe an icon style, maybe a texture swatch. It's not a mockup of any real screen — that's the tell that separates it from a comp — it's closer to a fabric swatch. A small, honest sample of the material you're about to build the whole room out of.

The audience shifts here too. A moodboard is for feeling something out with a client. A style tile is usually presented back to that same client for sign-off ("yes, this is the direction — the warm neutral, the serif headline, the rounded buttons") before it goes anywhere near a designer building actual screens. It's cheap to produce and cheap to compare against alternatives, which is the whole point: you want the disagreement about "should the accent color be terracotta or rust" to happen here, on one small page, not three screens deep into a Figma file.

Good style tiles usually come in twos or threes, shown side by side rather than one at a time. A single tile invites a yes-or-no reaction; two or three invite an actual comparison, which is a more honest way to find out what a stakeholder responds to than asking them to react in a vacuum. If you only ever show one direction, you'll get polite agreement instead of a real preference.

The style guide: the rules everyone has to follow

A style guide is what a style tile grows into once the direction is approved and real production starts. It's not one page anymore — it's the full rule set. Every color with its use case and its accessible pairings. A type scale with every size, weight, and line-height a product will ever need, not just a headline and a paragraph. Button states: default, hover, active, disabled, focus. Spacing units. Icon grid. Component variants. It's written for developers and other designers who need to make consistent decisions without asking you every time, which means it has to be precise in a way a moodboard and a style tile were never required to be.

This is also where the audience stops being "does this feel right" and becomes "can I implement this correctly without guessing." A style guide that says "primary blue" without a hex value and a contrast ratio isn't a style guide, it's a mood board wearing a style guide's name.

A useful way to stress-test a style guide before you call it done: hand a single page of it to a developer who wasn't in any of the earlier conversations and watch what they ask you. Every question they have to ask is a rule that isn't written down yet. A moodboard failing that test is normal — it's not supposed to answer questions. A style guide failing it means it isn't finished.

The order matters more than the definitions

Here's the sequence, and it only runs one direction: moodboard first, to explore and agree on a feeling with room to be wrong. Style tile second, to pin that feeling down into one concrete, nameable direction and get sign-off on it cheaply. Style guide last, to expand the approved direction into every rule a team needs to build consistently at scale.

Each stage narrows what's still negotiable. The moodboard has nothing decided. The style tile has the big calls made — palette, type, general shape — but the details are still open. The style guide has almost nothing open; it's the record of every decision, made specific enough to build from.

It also helps to think about how expensive a change is at each stage, because that's really what the order is protecting. Cutting an image from a moodboard costs nothing. Swapping the accent color on a style tile costs an afternoon. Changing a color that's already threaded through a shipped style guide — referenced in a dozen components, baked into design tokens, maybe already in production — costs days, and it costs trust with whoever has to explain the change to their team. The three stages exist because the price of being wrong keeps climbing, so you want to be as sure as possible before you cross into the next one.

A moodboard is a question. A style tile is an answer. A style guide is the instructions for building on top of that answer without asking again.

The mistake: jumping from moodboard straight to style guide

This is the expensive one, and it happens constantly under deadline pressure. A team collects a moodboard, feels good about the direction, and then — because a style guide is the "real" deliverable someone's expecting — jumps straight into writing full color systems and type scales off of it. The style tile step, the cheap one, gets treated as optional overhead.

It isn't overhead. It's the checkpoint. Skip it and you're locking in a full rule set — the type scale, the component library, the whole system — based on a direction nobody has actually confirmed yet. When the stakeholder finally sees something concrete, three weeks in, and says "I thought we were going warmer than this," you're not tweaking a one-page tile. You're unwinding a style guide that other people have already started building components against. The style tile exists specifically to catch that disagreement while it's still cheap to catch.

How to tell which one you're looking at

If it has more than a dozen images and no fixed palette, it's a moodboard. If it's one page with two or three colors, one type pairing, and no real screens, it's a style tile. If it has states, variants, spacing rules, and enough detail that a developer could work from it without asking you a follow-up question, it's a style guide. When you're not sure which one a document in front of you is supposed to be, ask what decision it's meant to settle — that question almost always answers itself.

Moodly saves images and links straight into a moodboard as you browse — hover, click Save, and it's organized without breaking your flow.

Add to Chrome — it's free