Google Stitch Web App Design Guide

A web app is more than a landing page with a login button. It has navigation, permissions, data tables, forms, settings, empty states, and responsive layouts. Stitch can generate a convincing first pass when the prompt describes the product structure instead of only the visual style.

This guide focuses on the pages and systems that make a web app usable: the seven core page types, the main layout models, a repeatable prompt formula, and a design-to-code handoff.

Web app vs landing page vs mobile app

A landing page has one conversion goal and a linear story. A web app supports recurring tasks, so it needs navigation, state, data density, and permissions. A mobile app prioritizes touch, one-handed use, and short sessions. If you prompt all three with the same structure, at least one will be wrong.

Name the surface in the first sentence of the prompt. Then describe the page type, because "dashboard" and "settings" need different components even inside the same product.

The seven page types every web app needs

Auth

Sign in, sign up, password reset, and verification. Keep the layout simple, make the primary action obvious, and include error and loading states.

Onboarding

Collect only what the product needs to deliver the first useful result. Use a progress indicator, one decision per step, and a clear way to skip or go back.

Dashboard

A dashboard is for scanning and comparison. Prioritize a few metrics, one trend, and a path into the work that needs attention. Do not turn it into a gallery of every chart in the product.

List and table

Lists need sorting, filtering, pagination, row selection, bulk actions, and a clear empty state. Tables need enough density for real data without becoming unreadable.

Detail

A detail page should answer "what is this, what happened, and what can I do next?" Keep the primary action visible and group secondary actions.

Settings and billing

Settings are where users manage identity, preferences, team access, and payments. Use clear sections, safe defaults, and confirmation for destructive actions.

Empty and error states

New accounts are empty. Networks fail. Permissions change. Design these states on purpose instead of letting the interface collapse.

Layout systems for web apps

Sidebar plus content

The most common SaaS layout: persistent navigation, a top bar for search and account actions, and a content area that can switch between list, detail, and settings. It scales well to dense products.

Useful for simpler web apps and marketing-adjacent products. It keeps the content area wide, but it can become crowded when there are many sections or user roles.

Split view

Useful for inboxes, support tools, and anything where users compare a list with a detail. The left pane carries selection; the right pane carries context and actions.

Responsive breakpoints

Start at 1440px, then check 1280px, 1024px, and 768px. Collapse the sidebar, reduce table columns, and move secondary actions into menus. Read the Stitch guidance on device types before you generate multiple sizes.

The web app prompt formula

Use this structure for each page. Replace the brackets with product-specific details.

Design a [web app type] for [audience].
Page: [page type] whose primary job is [job].
Navigation: [sidebar / top nav / split view].
Layout: [columns, density, max width].
Components: [table, filters, forms, charts, modals].
States: [loading, empty, error, success, permission denied].
Style: [design system or visual direction].
Constraints: [breakpoints, accessibility, data volume].

The formula keeps the page, navigation, and states in the same prompt. That is usually the difference between a pretty mockup and a usable app screen.

Dashboard prompt example

Design a B2B analytics web app dashboard for a customer support platform.
Page: dashboard; primary job is to show queue health and surface the most urgent conversations.
Navigation: left sidebar with Inbox, Analytics, Team, Settings; top bar with date range and search.
Layout: 12-column grid, four KPI cards, two charts, and a conversation table below.
Components: KPI cards, line chart, stacked bar chart, sortable table, filter bar.
States: loading skeletons, empty queue, error banner, permission-denied state.
Style: clean SaaS interface with neutral surfaces and one blue accent.
Constraints: 1440px first, responsive to 1024px; table must remain scannable.

Landing page prompt example

Design a landing page for a developer tool that turns API logs into dashboards.
Audience: backend engineers at small SaaS teams.
Primary goal: start a free trial.
Sections: hero with code sample, three feature blocks, integration logos, pricing preview, FAQ, final CTA.
Style: technical editorial, monospace accents, restrained color, generous whitespace.
Constraints: mobile-first; one primary CTA repeated; no stock-photo hero.

A landing page is not a web app, but the same product may need both. Keep the visual system shared while changing the navigation and density.

Components and states

Tables are where most web apps succeed or fail. Specify sorting, filtering, pagination, bulk actions, column priorities, and what happens when there are no rows. Forms need labels, validation, error messages, success feedback, and a clear primary button. Modals and toasts should be reserved for decisions and short feedback, not for content that deserves its own page.

Ask Stitch for the state, not just the happy path. A prompt that includes loading, empty, error, and permission states produces a more complete screen and exposes layout problems earlier.

Keep pages consistent

Write a shared prompt prefix with the product, audience, style rules, and constraints. Then reuse the same color, type, spacing, radius, and component vocabulary on every page. If a page drifts, fix the shared constraint rather than prompting around it.

Stitch variants can help you test layout alternatives without changing the visual system. For a broader system, turn the design rules into a DESIGN.md file and reuse it across screens and coding agents.

Design-to-code handoff

A web app design is only useful if a developer can build it. Start with a clean layout, named components, and documented states. Then use Stitch's HTML, React, or Tailwind-oriented outputs as a starting point, and review the result before shipping it.

See the download artifacts reference for export capabilities, the CLI tutorial for a terminal workflow, and the code-to-design workflow for moving between a codebase and a design system.

QA checklist

Before you hand off a web app screen, check:

one primary action and a clear page title;
navigation that matches the user's role and task;
a table or list that remains readable at 1024px;
loading, empty, error, success, and permission states;
form labels, validation, and confirmation;
consistent colors, typography, spacing, and radius;
a responsive plan for the next breakpoint;
no duplicate or conflicting actions.

FAQ

Is Stitch good for complex admin interfaces?

It is a good first-pass tool for layout, hierarchy, and visual direction. Complex admin products still need real data modeling, permissions, and usability testing. Use Stitch to explore and align, then validate with users.

How do I generate responsive web app screens?

Prompt the desktop layout first, then ask for the same page at 1024px and 768px with specific changes: collapsed sidebar, fewer table columns, stacked cards. Do not assume the AI will infer every breakpoint.

How do I export a web app design to code?

Use Stitch's export options and review the generated HTML, React, or Tailwind output. Treat it as a starting point, then apply your architecture, accessibility, and testing standards. For a repeatable pipeline, use the SDK or CLI.

Next steps

If you need the broader design workflow, read the Google Stitch AI UI Design Guide. Browse web app styles, try the editor, or follow the tutorials for structured practice.