Design Specifications

Design Specifications: What to Include & What to Leave to Designers

How to use Claude to produce complete design specs — while preserving the creative and visual work for expert human designers.

The Boundary Between AI-Assisted Specs and Human Design

Design specifications fall into two categories:

  1. Structural specifications — What screens exist, what they do, how users flow between them, what interactions are required, what states need to be handled. Claude excels here.
  1. Visual design — Color systems, typography scales, component aesthetics, spacing refinement, motion design, brand expression. This is the domain of skilled human designers who have visual judgment, brand sensitivity, and aesthetic training Claude cannot replicate.

This lesson focuses on using Claude to build complete structural specifications that enable your designer to work efficiently — without trying to replace the creative work.

What a Complete Design Specification Contains

Product Requirements Summary

Before design starts, the problem must be clear. Claude can help structure this:

text
Feature: [Feature name]
User story: As a [user type], I want to [do something] so that [I achieve a goal].
Success metric: [How we measure if this feature succeeded]
Constraints: [Technical, legal, timeline]
Out of scope: [Explicitly what this feature does NOT do]

User Flow Documentation

text
Generate a user flow document for a checkout experience. The user journey starts
when they click "Buy Now" and ends when they receive an order confirmation.
Include all decision points, error states, and edge cases
(empty cart, payment failure, out of stock, returning vs. new user).
Format as a numbered step list with branching paths clearly indicated.

Screen Inventory

text
Generate a complete screen inventory for a B2B SaaS project management tool.
For each screen, list: screen name, primary purpose, key user actions available,
data displayed, and navigation entry/exit points.
Organize by user role: Admin, Project Manager, Team Member.

Component Specification

text
Write a component specification for a data table component. Include:
- All states: empty, loading, populated, error, filtered
- Sortable columns: which columns, sort direction indicators
- Row actions: inline vs. bulk selection
- Pagination: page size options, navigation controls
- Responsive behavior: how the table adapts below 768px
- Accessibility requirements: keyboard navigation, screen reader labels
Do not prescribe visual styling — that's for the designer.

Interaction Specification

text
Write an interaction specification for a drag-and-drop task board (Kanban-style).
Cover: drag initiation, valid drop targets, invalid drop targets,
drop success animation, undo behavior, touch device behavior,
keyboard accessibility alternative, and loading/optimistic update handling.

Annotation Guidelines for Wireframes

When working with wireframes, Claude helps write clear, actionable annotations:

text
I have a wireframe for a user onboarding flow with 4 screens.
Generate an annotation template for wireframes that covers:
component labels, interaction notes, copy placeholders,
responsive breakpoint notes, and handoff notes for the developer.

What Good Design Specs Leave Out

A good Claude-assisted design spec explicitly marks what the designer decides:

text
[DESIGNER DECISION]: Color palette and visual hierarchy for this screen
[DESIGNER DECISION]: Typography scale and line height for body copy
[DESIGNER DECISION]: Spacing tokens and component radius
[DESIGNER DECISION]: Icon style and illustration approach
[DESIGNER DECISION]: Animation curves and timing

Include these explicitly so designers know where their creative authority begins and the spec ends.

The Spec-to-Designer Handoff Prompt

text
I have a design specification document for [feature].
Rewrite the specification as a designer brief — a document that:
1. Gives the designer full context on the user problem
2. Specifies exactly what constraints exist (technical, brand, accessibility)
3. Lists every state that needs to be designed
4. Leaves all visual decisions explicitly open
5. Ends with 3 specific questions I should ask the designer to align on before they start

Key Takeaways

  • Design specs cover structure, flows, states, and interactions — not visual design choices
  • Explicitly mark "DESIGNER DECISION" sections so creative authority is unambiguous
  • Complete specs reduce designer re-work by answering structural questions upfront
  • Claude generates annotation templates, component specs, and interaction notes faster than writing from scratch

---

Try It Yourself: Pick a screen you're building or planning. Prompt Claude with: "Generate a complete screen specification for [screen name]. Include all states, user actions, data displayed, and edge cases. Do not specify visual styling." Review the output — what did Claude include that you hadn't considered?