Skip to main content
Exemplar section — first pass. Destructive confirmation was already reviewed to this standard. The nine pages added alongside it are new and carry the same standing its own banner already states: proposals for review, not established policy. None were produced by auditing a shipped Invoca screen — Titan’s design library and the product surfaces that would confirm or correct them were not available while writing this pass. Each is built from general interaction-design practice and from the constraints Foundations and Components already establish. Treat every constraint below as a starting point to check against real product screens, not as a rule already enforced. The CRUD group nested below was added the same way, under the same standing. See Coverage, stated honestly.

​
What Patterns governs

A pattern is a named composition of two or more components, with rules, but no export. It sits between Components and Views in Titan’s four-tier ladder: a pattern tells you which components to combine, in what order, and how they behave together, but it ships nothing of its own — no import, no props API, no tokens. If you can import it, it’s a Component. If it defines a page’s regions, it’s a View. If it’s a recurring, rule-bound arrangement of existing components that answers to neither of those tests, it’s a Pattern. Patterns exist because component pages answer “what does a Button do” and views answer “what regions does this page have,” and neither answers “how do these five components work together to let someone delete a campaign safely” or “what happens across a whole form when three fields are invalid at once.” That composition-level question is this section’s job.

​
Choosing a pattern

The reader’s intent, not the component name, is the useful index. Use this table before the card grid below — it is written in the words of the problem, not the solution.

​
Coverage, stated honestly

Every pattern on this site carries the same standing right now: a first-pass proposal, not a decision confirmed against a shipped screen. Nothing here is generated, and nothing here has been signed off — the column below exists so that changes later, not so it reads as settled today.

​
Choosing where to look

Destructive confirmation

Undo versus confirm, and three tiers of friction matched to consequence.

Bulk selection

Selecting many rows and acting on them as one batch.

Empty & zero states

Nothing here yet, versus nothing matched, versus something went wrong.

Error handling

Where a failure is shown, and what it must tell the user next.

Filtering & search

Narrowing a list, and keeping the narrowing visible and reversible.

Form validation

When an error appears, where it appears, and how many places say it at once.

Inline editing

Editing a value in place, and when that stops being the right idea.

Loading & skeletons

Matching a loading placeholder to the shape of what’s coming.

Notifications

Toast, banner, or alert — and what decides which.

Progressive disclosure

Keeping a screen simple without hiding what people actually need.

CRUD

Full page, drawer, modal, or inline — the decision tree for Create, Read, Update, and Delete.

​
Constraints

Components, the units these compositions are built from. Views, which decide the page regions a pattern is placed into. AI Experience, the sibling section for anything in this composition tier where the output isn’t deterministic — several patterns here have an AI-driven counterpart there (Empty & zero states pairs with Welcome / empty state; Filtering & search pairs with Search).

​
Why it works this way

A pattern is defined by what it lacks, not by what it contains. Any of these could be redescribed as “a Card, a Button, and some state” — that description is true of nearly every screen in the product and explains nothing. What makes something worth a page here is a recurring decision — when to skip the pattern entirely, what order the pieces go in, what happens on failure — not the inventory of components involved. Proposal-first is the honest way to grow this section without Titan. Waiting for every pattern to be confirmed against a shipped screen before writing it down means the vocabulary for “how does Invoca do bulk selection” doesn’t exist until someone happens to build bulk selection first and document it after. Writing the proposal first gives the next person building one a starting point to correct, instead of a blank page.

Destructive confirmation

How to ask before an action that destroys work — and when not to ask at all.

Form validation

When an error appears, where it renders, and how many places say it at once.

Empty & zero states

Nothing here yet, versus nothing matched — and why a failed load is neither.

Loading & skeletons

Matching a loading placeholder to the shape of what's coming — and when to reach for a spinner or a progress bar instead.

Error handling

Where a deterministic action or load failure is shown, and what it must tell the reader next.

Filtering and search

Narrowing a list down to what someone wants, with deterministic filters and a search box — not natural-language interpretation.

Bulk selection

Selecting many rows at once and acting on them as a single batch.

Inline editing

Editing a value in place, and when that stops being the right idea.

Progressive disclosure

Keeping a screen simple without hiding what people actually need.

Notifications

Toast, banner, or alert — and what decides which one tells the reader something happened.

CRUD

Create

The decision tree for where a new object gets created — full page, modal, drawer, or inline — based on permanence, density, and continuity, not habit.

Read

Viewing one object in detail — full Detail view, Drawer preview, or inline expansion — based on how much the reader needs right now.

Update

What changes once an object already has data — prefill, partial versus whole-form save, dirty-state tracking, and concurrent edits.
Last modified on September 2, 2026