A design system a marketing team will actually use

Three causes, in rough order of frequency.

It is slower than the blank canvas. If finding and adapting the right component takes longer than making something from scratch, people make something from scratch. Every time. This is not a discipline failure, it is a speed failure, and it is the one most systems have.

It covers the wrong things. Beautifully specified buttons and spacing scales, nothing for the formats the team produces weekly: the recruitment post, the webinar promotion, the case study one-pager, the sales deck slide, the event banner in four sizes.

Nobody owns it. It launches, the person who built it moves on, and within two months there are three versions of the primary button in circulation and no authority to resolve which is correct.

Design for all three or you will rebuild this in eighteen months.

Before designing anything, do an inventory. This step gets skipped and it is the one that determines whether the system is used.

1. Collect everything the team produced in the last 90 days. Social posts, ads, emails, decks, landing pages, one-pagers, event collateral, internal slides. All of it, not the good examples.
2. Group by format and count. You now have frequency data. You will find a long tail of one-offs and a short head of things produced constantly.
3. Mark what was made from scratch. These are the expensive items. Repetition plus from-scratch production equals a missing template.
4. Note where it went off-brand. Not to assign blame. The patterns tell you what was hard to get right: usually type hierarchy on dense layouts, image treatment, and anything involving a logo on a busy background.
5. Ask the three people who produce most of it what they dread. The answer is usually resizing, cropping for different platform ratios, or making a lot of text fit.

Your first release covers the head of that distribution. Not the whole brand. The top eight to twelve formats, done properly.

A component that is only a visual spec will not get used. Each one needs four layers.

The example layer is the one teams skip and the one that does most of the work. Include a version with too much text, a version with a poor-quality image, and a version in the longest language you support. Those are the real conditions. A component shown only with ideal content teaches nothing about what to do when content is not ideal.

Also specify what to do when the component does not fit. "If the headline exceeds two lines, use the stacked variant" is more useful than a rule that assumes headlines are short.

Naming is where systems quietly become unusable. Designers name by structure. Everyone else searches by job.

Call it social-post-quote rather than card-variant-3. Call it deck-slide-two-column-stat rather than layout-split-b. The name should answer "is this the thing I need" without opening it.

Three rules that hold up:

• Name by purpose, then by variant. Purpose first so related things sort together.
• No internal jargon, no version numbers in names. hero-v2 guarantees hero-v3 and permanent ambiguity about which is current.
• One name per concept, everywhere. If the design file says "accent", the code says "accent" and the documentation says "accent". Not "secondary" in one place and "highlight" in another.

Write a one-line description against every component in plain language. Make the library searchable by those descriptions.

Heavy governance kills adoption. The minimum that works:

• One named owner. With authority to approve or reject additions, and an hour a week blocked for it.
• One intake route. A single form or channel for "I need something that does not exist". Not direct messages to a designer.
• A standing rule for repeats. The same ad-hoc request arriving twice becomes a template. No debate.
• A quarterly review. What got used, what did not, what went off-system. Remove components nobody uses; they add search noise and maintenance cost.
• A changelog in plain language. What changed, when, and what you need to do about it. Two lines per entry.

Resist the pull toward a formal contribution process until there are more than a handful of contributors. Until then it is overhead pretending to be rigor.

1. Lock the foundations. Type scale, color tokens including accessible text-on-background pairings, spacing scale, logo clear space and the minimum sizes. Small set, no exceptions.
2. Build the top three formats as finished templates. The ones produced most often, with examples. Ship these before anything else so the system is immediately useful.
3. Put them where the work happens. In the tools people already open, not in a separate portal they have to remember. A system that requires a second login is a system with a weekly tax on using it.
4. Watch one production cycle without helping. Two weeks. Note every point where someone got stuck or went around it. This is the most valuable data you will get.
5. Fix the friction before adding scope. Resist the urge to expand. Fix what you just watched fail.
6. Then extend down the frequency list. Next three formats, same depth.
7. Add the documentation last. Short, searchable, written for someone in a hurry. If it needs to be long, the system is too complicated.

Built for the design team's taste rather than the marketing team's throughput. Signal: it is admired and unused.

Too much scope in version one. Forty components, nothing finished, nobody confident which to pick.

No accessible color pairings specified. People then combine tokens that fail contrast, and you find out from a customer or an audit rather than from the system.

Documentation as the deliverable. Documentation is the smallest part. Working templates in the right tool is the deliverable.

No owner after launch. The most reliable predictor of a dead system. Agree the name and the hour before you start building.

Ignoring the one-off requests. Each one is telling you about a gap. Log them.

This usually sits downstream of brand work and upstream of campaign production. If the foundations are contested — if there is still an open question about type, color or how the identity behaves in motion — that gets settled in brand strategy and identity first, because a system built on unresolved foundations has to be rebuilt. Where the foundations are settled and the problem is throughput and drift, the work goes straight into design systems: inventory, foundations, the top formats, then one watched production cycle before anything is extended.

Agree what better means before the work starts. Fewer off-system requests, faster production on your highest-frequency formats, or less rework at approval. Those are different targets and they build differently.