App Screen Patterns

Most of a product is not the hero feature. It is settings, members, billing, notifications, search, imports, keys, and error pages, and users judge trust on those screens. They fail in predictable ways: a toggle that silently needs a Save, an empty state shown when the fetch failed (users think their data is gone), an invite that charges a seat without warning, a key that can be viewed forever, a deletion flow that app review rejects. This skill fixes the shared rules once, then gives each screen its anatomy, states, and copy. The rules come from design systems that publish their reasoning (GitHub Primer, IBM Carbon, Shopify Polaris, GOV.UK) and from platform policy (Apple, Google Play).

Before you start

If .agents/project-context.md exists (or .claude/project-context.md), read it first and treat it as ground truth for stack, platforms, scale, design system, and constraints. Only ask for what it does not cover. If it does not exist and the task is larger than a quick fix, suggest running the project-context skill — but never block on it.

Then look for what already exists: a design system or component library (Dialog, Banner, Toast, EmptyState, PageHeader), a DESIGN.md, existing settings or error pages, and the roles and plans model. Compose existing components and patterns; don't invent a second modal or a third toast.

Core principles

1. Decide the shared rules once per product. Save model, message placement, and destructive tiers must be the same on every screen, or users can't predict what a click does.
2. Design every state, not the happy path. Loading, empty, error, partial, no-permission, over-limit, and offline are where users lose trust.
3. Never make users think their data is gone. A failed fetch of the user's own content shows "unavailable", never a first-use empty state.
4. Show consequences before commitment. Seats charged, prorated amounts, what a deletion cascades to, what a role can do: stated with numbers before the button.
5. Scale friction to impact. Undo for the reversible, a confirm for the irreversible, type-to-confirm for the catastrophic. Confirming everything trains people to click through.
6. Platform and legal rules are requirements, not polish. In-app account deletion, equal Accept/Reject on cookies, and online cancellation are review- and law-driven.
7. Copy is specific. Verb + noun buttons, the user's own data, exact numbers and dates. "Delete workspace", not "OK".

Workflow

• Identify the screen(s) in the pattern index below and read the matching reference file.
• Fix the shared rules for this product if they aren't fixed yet (save model, message placement, destructive tiers). Write them into DESIGN.md or the project context so every later screen reuses them.
• List the states for the screen: loading, empty (first use, filtered, error), partial/degraded, success, no-permission, plan-limit, offline. Each gets a design and copy.
• Map permissions and billing edges: which roles see, edit, or never see each control; seat and plan limits; IdP-managed users; failed payment.
• Write the copy from the examples in the reference: headings say the effect, bodies say the fix, buttons say verb + object.
• Build from existing components; add a new pattern only when nothing fits (see design-systems).
• Validate against the pre-ship checklist and Gotchas; fix and repeat until clean.

Shared rules every screen inherits

Save model

• Never mix explicit and auto-save inside one form; avoid mixing them on one page.
• Keep Save enabled even when the form is invalid or unchanged; validate on submit. Disabled buttons can't be reached with Tab and are hard to read. (Exception: type-to-confirm dialogs enable Delete only when the typed name matches.)
• One Save per form, and prefer one per page. Several same-label Save buttons confuse screen-reader and voice-control users. Allow one inline edit mode at a time.
• On error, keep every input and show what failed. Warn on navigation away from unsaved changes (beforeunload shows only a generic browser message; add an in-app route guard for client-side navigation).
• After creating something, go to the new object. For slow creation, show a holding page that says the configuration is safe.

Messages: type and placement

Never put errors that need action in a toast. Never open system pop-ups (NPS survey, promo) while the user is mid-task. Use success messages sparingly. Toast timing and accessibility live in interaction-design.

Degraded experiences

• Separate primary content (the thing the page is for) from secondary (sidebars, counts, related items). Primary fails: render an error page or region with Retry. Secondary fails: render the page without it, or with an "unavailable" note.
• Never show a first-use empty state for data the user created when the fetch failed. Say "Couldn't load your projects. Try again", or remove the section and its heading.
• Hide counts and badges you can't compute; never show "0" as a guess.
• Never disable a control because of an outage. Hide non-critical actions, or keep the button active and explain on click.
• At most about 5 outage messages per page; for a global incident use one banner linking to the status page. Never hide the global navigation.

Disabled vs read-only vs hidden

No tooltips on disabled elements: they can't receive focus, so keyboard and screen-reader users never see the reason. Put the reason in text.

Loading thresholds

Load the most important content first and render items as they arrive; merge adjacent spinners into one. Every job has initiated → in progress → succeeded or failed (with Retry). A full interstitial page only for waits of several seconds that produce a big change (creating a workspace).

Dialog vs panel vs page vs wizard

Never nest modals, never scroll inside a small create dialog, and never use a full-screen modal as a substitute for a page. A task done many times a day belongs on the page, not in a dialog. Cancel in a dialog discards everything done in it.

Action vocabulary

Buttons are verb + noun when the object isn't obvious ("Delete project", "Add SSH key", "Revoke key"). Never "OK", "Yes", "Submit", or "Done" for a consequential action.

Destructive-action ladder

In every confirmation: concrete consequences with numbers ("124 tasks, 38 files, and all comments; 6 members lose access immediately"), whether recovery exists ("Restorable from Trash for 30 days" or "This can't be undone"), danger styling on a specific verb, and initial focus on the safe action for high-impact deletes. Afterwards, return to the list, confirm, and if deletion fails, say so and restore the item.

Error-message content

Say what happened and what to do, using the user's data: "To save this product, make 2 changes: Enter a title · Add a weight", not "There are 2 errors. Invalid title". Headline = effect, body = fix + link, button = one-step solution. No "Oops", no blame, no "invalid", no "we" unless the company caused it. Red for problems that need action now, yellow for warnings.

Pattern index

Pre-ship checklist

• States: loading (by threshold), empty (first use, filtered, error), partial/degraded, error, success, no-permission, plan-limit, offline — each designed with copy.
• Save model consistent with the product rule; dirty state visible; unsaved-changes guard; Save never disabled (except type-to-confirm).
• Destructive actions on the ladder, with numbers, recovery statement, and a specific verb.
• Feedback next to its cause; no success message when the result is visible; no actionable errors in toasts.
• Permissions: hidden vs read-only vs disabled-with-reason applied; IdP-managed and last-owner cases handled.
• Billing edges: seat limit, plan limit, trial end, failed payment (admins only), downgrade effects.
• Real data: 60-character names, zero / one / 10,000 items, RTL, 200% zoom, translated strings much longer than English.
• Keyboard and screen reader: focus moves into dialogs and to error summaries; no tooltips on disabled elements; status messages announced.
• Legal and platform: in-app account deletion plus web link (mobile), Accept/Reject equal, cancel online, no pre-ticked consent, marketing email opt-in.
• Deep links: every settings section and tab has a URL that support can send.

Gotchas

• Toggles that need a Save, or text fields that auto-save. Users leave thinking a setting is on when it isn't. Follow the save-model table.
• A disabled Save button with no explanation. Keyboard users can't reach it and nobody knows what's wrong. Keep it enabled and validate on submit.
• "No projects yet" after a 500. The user thinks their work was deleted. Render an error with Retry, or hide the section.
• A Save button on every card plus a global Save. Nobody knows which one saves what. One per form.
• Confirm dialogs on everything. People click through them by reflex, including the one that matters. Use Undo for reversible actions and keep dialogs for the irreversible.
• "Are you sure?" with Yes/No. The buttons must name the action: "Delete project" / "Cancel".
• Invites that silently add a paid seat, or removals that don't free one. Show seat count and cost in the invite dialog; say whether removing frees the seat.
• Deletion that only deactivates. Apple rejects deactivate-only flows and flows that require a call or email; Google Play also requires a web deletion link.
• Showing the full API key again later or letting the list display it. Show it once; list the prefix and last characters.
• A cookie banner with "Accept all" and a "Manage" link. Reject must sit on the first layer with the same prominence.
• Funny or technical error pages ("Oops! 404 bad request"). Say what happened in plain words, what happens to their data, and what to do next.
• Permission problems shown as disabled buttons with tooltips. The tooltip is unreachable. Hide, make read-only, or explain in text.
• Upsells disguised as errors, or upgrade prompts inside destructive or stressful flows. Show limits honestly, near the thing that is limited.
• Building the app shell, dashboard, onboarding checklist, or login here. Those have their own skills (see Related skills).

Output format

For a screen build or review, deliver:

Screen: <name> · Pattern ref: <reference file>
Shared rules applied: save model <…>; messages <…>; destructive tier <…>
Anatomy: <regions top to bottom, primary action, overflow actions>
States: loading ✓ · empty ✓ · error ✓ · degraded ✓ · no-permission ✓ · limit ✓ · offline ✓/n.a.
Permissions: hidden <…> · read-only <…> · disabled-with-reason <…>
Copy: headings, buttons, confirmations, errors (exact strings)
Platform/legal: <deletion, consent, cancel — or n.a.>
Checked: <pre-ship items verified> · Not checked: <…>

References

Related skills

• interaction-design — control states, forms and validation timing, toasts, overlays, and microcopy that these screens are built from.
• dashboard-design — the app shell, sidebar, account menu, and home dashboards that host these screens.
• onboarding-design — first-run, setup checklists, and empty-account activation.
• auth-flows — login, sign-up, MFA, password reset, and session management behind the account screens.
• data-dense-ui — tables, data grids, filters, and saved views used on list and admin screens.
• conversion-ux — pricing pages, paywalls, checkout, and cancel-flow ethics.
• design-systems — turning these patterns into reusable components and registry blocks.