The Spec Is the Artifact

Most design deliverables are screenshots.

The real artifact is the specification.

The culture celebrates the visual: the polished mockup, the hero shot, the Dribbble-worthy screen. But the mockup is not the design. The mockup is a proposal for one moment in one state. The design is the system of rules that governs the thing across every state, edge case, and failure mode.

Pixels lie.

Specs commit.

The mockup illusion

A mockup is almost always a happy path:

• Perfect data.
• Ideal viewport.
• No latency.
• No errors.
• No ambiguity.

It is a picture of a world where nothing goes wrong.

This is fine as a sketch. It’s disastrous as a deliverable.

When you hand an engineer a picture, you are not handing them a design. You are handing them a puzzle. They must invent the rest: the loading state, the empty state, the invalid state, the offline state, the “user clicked twice” state, the “the server responded but the session expired” state.

That invention is where drift begins.

The shipped product doesn’t match the intent, not because anyone is careless, but because the intent was never fully defined. The design was a vibe, and vibes don’t survive contact with reality.

Here’s the tell:

If the “spec” lives as Figma comments and Slack threads, you don’t have a spec.

You have a rumor.

What a spec actually is

A spec is not a description of the design.

It is a definition of it.

It answers the questions that mockups politely avoid:

• What happens when the data is missing?
• What happens when the text is too long?
• What happens when the user is offline?
• What happens when the action fails?
• What happens when the state is ambiguous?

If you can’t answer “what happens when…”, you don’t know what you’re building yet.

That’s not shameful. It’s normal.

But it’s also the core of the work.

The spec is the contract between design and engineering. It’s what turns “make it feel calm” into operational behavior. It’s what turns taste into rules. And it’s the only deliverable that can survive time, team changes, and the slow entropy of a product.

Here’s the practical test:

Can an engineer build this without asking questions? If not, the spec is incomplete.

The goal is not “no questions ever.” The goal is that the questions are good—the interesting ones, not the avoidable ones.

Why specs are undervalued

Specs are undervalued for the same reason infrastructure is undervalued: it doesn’t screenshot well.

Spec work is unglamorous. It forces you into the boring scenarios where the truth lives. It surfaces uncertainty. It demands decisions that a mockup can defer indefinitely.

And design culture often rewards the portfolio piece, not the production artifact.

Designers get praised for how things look, not for how they behave under stress.

So the incentive is predictable: spend time polishing the happy path and let everyone else deal with reality.

Reality always arrives.

The anatomy of a real spec

If you want to treat specs as first-class, you need a shared sense of what “complete” looks like.

At minimum, a real spec accounts for:

States. Every component has them: default, hover, active, disabled, loading, empty, error, success, partial.

Content constraints. Min/max lengths, truncation rules, fallbacks, empty copy, formatting rules, localization stress.

Behavior. What triggers what? What’s the sequence? What’s optimistic vs. confirmed? What happens on back/refresh?

Edge cases. What if the user does something “wrong” but common? Double clicks, network flaps, concurrent edits, stale data.

Failure modes. How does the system fail? How does it recover? What does the user learn? What action can they take?

Accessibility. Keyboard navigation, focus order, screen reader output, motion considerations, reduced motion alternatives.

None of this is “extra.”

This is the design.

Specs are where judgment lives

It’s fashionable to say AI can generate mockups.

It can.

That’s exactly why mockups are no longer the high-leverage artifact. Screens are cheap. Plausibility is abundant. What’s scarce is the thing that prevents generic output: constraints, priorities, refusal lists, tradeoffs.

The spec is where human judgment lives.

It’s where you decide what matters when everything can’t be true at once. It’s where values become operational. It’s where you choose what the product will refuse to do.

This is also the higher-leverage way to use AI: don’t prompt for screens—prompt for specs. Ask for state tables, edge cases, failure tests, accessibility behavior, content constraints. Ask for the questions you forgot to ask.

The spec is the brief made operational.

The spec as collaboration tool

Specs aren’t just for engineers.

They’re for everyone:

• PMs use specs to confirm agreement: “Is this what we decided?”
• QA uses specs to know what to test.
• Support uses specs to explain behavior to users.
• Future designers use specs to understand why decisions were made.

In other words: the spec is institutional memory.

But there’s a hard rule:

Dead specs are worse than no specs.

If the design changes and the spec doesn’t, you’ve created a trap. A new teammate will trust the document and build the wrong thing with confidence. So if you treat specs as artifacts, you must treat them like code: versioned, owned, updated.

How to make specs first-class

If your team wants fewer handoff failures and less drift, you don’t need more “alignment meetings.”

You need better artifacts.

• Allocate time. Spec-writing is design work, not admin.
• Critique behavior, not just appearance. Review the failure modes, not the hero shot.
• Version specs. Track them, diff them, assign ownership.
• Reward completeness. Celebrate the designer whose handoff requires no clarification because the decisions are already made.

The mockup is the promise.

The spec is the commitment.

Pixels are easy to change. Specs force you to decide.

The design is not what it looks like.

It’s what it does—when the user clicks “Cancel” and the network is down and the session has expired.

That document is the design.