Templates

Best DESIGN.md templates

What launch-ready DESIGN.md templates should include for SaaS, docs, AI apps, and dashboards.

May 5, 20267 min read

Strong defaults

The best DESIGN.md templates do not start with color swatches and font names. They start with the decisions most likely to go wrong in AI-generated UI: layout density, navigation behavior, empty states, interactive state design, and anti-patterns. A template that opens with these sections saves time because the hardest design problems to communicate in text are not "what is the primary color" but "how spacious should the dashboard feel" and "what happens when there is no data to show." Strong templates also use a consistent file structure that agents can scan quickly: a fixed heading order — product feel, colors, typography, spacing, components, layouts, states, anti-patterns — means the agent knows where to find each type of rule without reading the entire file. Predictable structure is a feature in a spec document, and templates that enforce it produce better results than templates with arbitrary or inconsistent organization.

SaaS dashboard template

A SaaS dashboard template covers the specific surfaces that appear in most software products. The product feel section should describe an operational, information-dense, task-focused character — the opposite of a marketing landing page. The navigation section describes the sidebar: typical width range of 220 to 260px, item height of 36 to 44px, active-page indicator behavior, section groupings with labels, and mobile drawer behavior. The data table section is critical for most SaaS products: header font size and weight, row height, sort indicator styling, row hover state, checkbox column for bulk selection, pagination style and placement, and the empty table state. The card section covers both metric cards (compact, with a label, a large number, and an optional trend indicator) and content cards (standard padding, optional header with title and actions, optional footer with secondary actions). A SaaS dashboard template that covers all of these surfaces will produce dramatically more consistent output than a generic token-only template.

Docs site and marketing template

A docs site template has a fundamentally different focus from a dashboard template. The most important design decisions are readability and navigation clarity. The typography section should be detailed: optimal prose line width of 65 to 75 characters, body text size of 16 or 17px for comfortable reading, heading hierarchy from h1 through h4 with specific sizes and weights, code font family and size, and blockquote or callout treatment. The navigation section covers sidebar depth handling, active state appearance, search prominence, and breadcrumb placement. A marketing page template is different again: it allows more visual expression with larger typography, hero sections, feature grids, testimonial blocks, and CTA sections. The key design rules for a marketing template are about rhythm and contrast: how sections alternate background colors, how CTAs are spaced from surrounding content, and how multi-column grids collapse on mobile. Writing a template for your specific product category is worth the effort because generic templates produce generic results.

Template categories

Useful DESIGN.md templates group by product type because the visual system appropriate for one category is wrong for another. SaaS dashboards prioritize information density and operational clarity. Marketing pages prioritize visual expression and conversion. Documentation sites prioritize readability and navigability. Admin and internal tools prioritize data density and functional clarity over brand expression. AI-native products — tools where AI generation is a primary product surface — prioritize output legibility, prompt input styling, streaming text formatting, and feedback state design. Directories and catalog products prioritize browsable grid and list layouts, filter sidebar design, and card-based information hierarchy. Each of these categories has different default decisions for typography, spacing, component density, and page structure. A template right for one category will produce wrong defaults for another, which is why matching the template to the product type is the first and most important step in the selection process.

How to choose

Choosing the right template starts with matching the product shape. Identify the three or four primary screen types in the product and find the template that covers the most of them. A SaaS analytics tool with a dashboard, data tables, settings pages, and a public marketing site needs a template that covers both the dashboard pattern and the marketing pattern — those are two different systems that should be documented separately in the same file or in two distinct DESIGN.md files, one for the app shell and one for the public surface. After matching by shape, tune the defaults. A SaaS dashboard template may default to a 220px sidebar, but the product uses a 280px sidebar with a collapsible section system — update that before using the file for any real work. The mood section also needs to be replaced: a template has a placeholder personality, but each product has a specific one that must be written from scratch to be useful.

Customizing for your product

Customizing a template follows a predictable sequence. Start with the product feel section: write the personality statement from scratch rather than editing a placeholder. Then work through color: replace every token with the actual product values and update the semantic descriptions to match how each color is used in the real UI. Then update typography and spacing with measured values from the codebase or design system. Then work through the components section: keep the rules that match what the product actually does, rewrite rules for components the product treats differently, and add sections for any major surfaces the template does not cover. Finally, write the anti-patterns section fresh from real product experience — do not keep the template's anti-patterns unless they genuinely apply. When this process is complete, the template has been transformed into a product-specific spec. Commit it alongside component code, keep it updated as the product grows, and use it as the primary visual reference for every AI-assisted development session.

Use DESIGN.md with a real product reference

Browse curated DESIGN.md examples from product teams, design systems, developer tools, SaaS dashboards, and AI-native apps. Use them as references before your agent builds the next screen.

Browse directory Submit DESIGN.md

Related guides

Templates7 min read