Centrim Design System — a token-first, accessible React component system.
Patterns
Composed, industry-agnostic UX patterns. Every pattern reuses existing components and tokens — no new visual language, no product-specific screens. Each example is live: interact with it, resize the preview and switch the theme in the header.
Search & data management
Finding, filtering and acting on sets of records.
Search Filter Pattern
Search, filter and sort controls with removable active-filter chips and a single clear-all escape hatch.
SearchInputSelectMultiSelectDrawerBadgeButton
When to use
- Any collection that can be narrowed by more than one criterion.
- When applied filters must stay visible.
- Above tables, lists and result grids alike.
When not to use
- For a single search box — use SearchInput on its own.
- For navigation between views — use Tabs.
- When filtering happens inside the table's own filter bar already.
Live example
Responsive behaviour
- Controls sit inline from md up.
- Below md the same filter nodes move into a Drawer behind a Filters button.
- Active filter chips wrap and stay reachable at every width.
Accessibility
- The toolbar is a labelled search region.
- Each chip's remove control names the filter it clears.
- Filter count is announced, not only shown as a dot.
Table Management Pattern
A full list-management page: header, search and filters, selection with bulk actions, row actions and pagination.
TablePageLayoutPageHeaderPatternDataTableFilterBarBulkActionBarPagination
When to use
- The primary index page for a record type.
- When rows need bulk operations.
- When comparing many records across columns.
When not to use
- For fewer than a handful of records — use a list.
- For dense read-only reporting without actions.
- When one record is the subject — use the Detail Page pattern.
Live example
Items
Search, filter, select and act on records in one place.
| Status | Actions | ||
|---|---|---|---|
| Onboarding checklist | |||
| Quarterly review | |||
| Access policy | |||
| Vendor list |
Showing 1–4 of 5 items
Responsive behaviour
- Lower-priority columns hide at their declared breakpoints.
- The table scrolls horizontally rather than crushing columns.
- Bulk action bar becomes a full-width stacked bar on mobile.
Accessibility
- Sortable headers expose aria-sort and are keyboard operable.
- Row checkboxes are individually labelled; the header checkbox is tri-state.
- Selection count is announced by the bulk action bar.
Filtered Results Pattern
Search, filters, result count, results and pagination with loading, no-results and error states swapped in.
SearchFilterPatternPaginationLoadingStateEmptyStateErrorState
When to use
- Result surfaces that are not tables — lists, cards, grids.
- When the result count matters to the user.
- When queries can fail and need a retry.
When not to use
- For static content that is never filtered.
- When the DataTable already provides these states.
- For a global command palette — use Quick Action.
Live example
5 results
Onboarding checklist
Updated 2 hours ago
Quarterly review
Updated Yesterday
Access policy
Updated 3 days ago
Vendor list
Updated Last week
Release notes
Updated Last week
Responsive behaviour
- Filters collapse into a Drawer below md.
- Result count and pagination stack under the results on mobile.
- Results themselves are supplied by the caller, so they reflow freely.
Accessibility
- Result count is a polite live region.
- States keep focus order stable when they replace results.
- Retry is a real button, reachable by keyboard.
Bulk Selection Pattern
Select-all with partial selection, a selected count, bulk actions and a clear-selection escape hatch.
CheckboxBulkActionBarButtonIconButtonDivider
When to use
- Lists where the same action applies to many items.
- When users need select-all across the visible set.
- Alongside a destructive bulk action that requires confirmation.
When not to use
- When only one item can be acted on at a time.
- For navigation lists.
- Inside a DataTable, which already provides selection.
Live example
1 selected
1 item selected
Onboarding checklist
Owner A. Reyes
2 hours agoQuarterly review
Owner M. Chen
YesterdayAccess policy
Owner J. Okafor
3 days agoVendor list
Owner S. Novak
Last weekRelease notes
Owner L. Haddad
Last week
Responsive behaviour
- The action bar sticks to the bottom and stacks its actions on mobile.
- Item metadata drops below the label at narrow widths.
- Touch targets stay at least 44px tall.
Accessibility
- Header checkbox reflects the indeterminate state.
- Every row checkbox names the item it selects.
- Clearing the selection returns focus to the list.
Forms & workflows
Creating, editing and completing multi-part work.
CRUD Pattern
Create in a dialog, edit in place with a sticky action footer, and delete behind a destructive confirmation.
DialogAlertDialogFormFormFieldInputSelectTextareaButton
When to use
- Short creation flows that should not lose page context.
- Editing an existing record on its own page.
- Any irreversible removal.
When not to use
- For long or multi-section creation — use the workflow patterns.
- For inline single-field edits.
- When the delete is trivially undoable — offer undo instead.
Live example
Responsive behaviour
- The create dialog becomes near-full-screen on mobile.
- Form fields move to a single column below md.
- The edit footer stays reachable while the body scrolls.
Accessibility
- Dialogs trap focus and restore it to the trigger on close.
- Validation summaries are announced as alerts.
- Cancel precedes Save in DOM order to match visual order.
Form Workflow Pattern
A long single-page form with optional progress, sectioned fields, a validation summary and terminal success or error states.
FormFormSectionProgressAlertSuccessStateErrorStateButton
When to use
- Forms with several sections that still belong on one page.
- When users benefit from seeing the whole form at once.
- When submission has a clear success or failure outcome.
When not to use
- When steps depend on earlier answers — use the multi-step flow.
- For two or three fields — use a dialog.
- As a settings surface — use the settings pattern.
Live example
Responsive behaviour
- Section headers stack above their fields below lg.
- Progress moves above the form on narrow screens.
- Actions become full-width buttons on mobile.
Accessibility
- The validation summary links to the fields that need attention.
- Each field error is associated with its control.
- Terminal states move focus to the outcome heading.
Multi Step Pattern
A stepper-led flow: orientation, the active step's content and Previous/Next navigation with Save, Cancel and a completed state.
StepperFormButtonSuccessStateAlert
When to use
- Sequential work where later steps depend on earlier ones.
- When users need a sense of progress and remaining effort.
- When each step can be validated independently.
When not to use
- When all fields could reasonably fit one page.
- For navigation between unrelated sections.
- When users must be able to jump around freely.
Live example
- 1Current step
Details
Name and category
- 2Upcoming
Options
Preferences
- 3Upcoming
Review
Confirm and submit
Details
Name and category
Responsive behaviour
- The stepper switches from horizontal to a compact vertical list on mobile.
- Navigation actions stack, keeping Next the most prominent.
- Step content is single-column at narrow widths.
Accessibility
- Step status is exposed as text, not only colour.
- The failed step is announced and described by its error.
- Moving between steps moves focus to the new step heading.
Settings Page Pattern
Grouped settings navigation, a header, sectioned form content and a footer action row.
SettingsLayoutSidebarPageHeaderFormSectionSwitchSelectPageFooter
When to use
- Preference surfaces with several related groups.
- When changes are saved explicitly rather than instantly.
- For account, workspace or notification style settings.
When not to use
- For one-off configuration inside a feature.
- For record editing — use the Edit Form pattern.
- When there is only one group of settings.
Live example
Responsive behaviour
- Navigation moves above the content below lg.
- Switch rows keep their labels beside the control at every width.
- The action footer becomes a full-width bar on mobile.
Accessibility
- Settings navigation is a nav landmark with the active item marked.
- Every toggle has a persistent visible label.
- Save state is announced politely.
Feedback & recovery
Confirming intent and handling the empty, failed, waiting and finished moments.
Confirmation Pattern
A blocking confirmation in standard, warning or destructive tone, built on AlertDialog.
AlertDialogButton
When to use
- Before an action that is hard or impossible to reverse.
- When the consequence is not obvious from the trigger.
- For bulk actions affecting many records.
When not to use
- For routine, reversible actions — prefer undo.
- As a substitute for validation.
- To confirm every save.
Live example
Responsive behaviour
- The dialog is width-clamped and near-full-screen on mobile.
- Actions stack with the confirm action last.
- Copy stays short enough to read without scrolling.
Accessibility
- Focus starts on Cancel so confirm is never triggered accidentally.
- Escape cancels; the dialog traps focus while open.
- The consequence is stated in the description, not only the title.
Empty Experience Pattern
Nothing-yet state with an icon, title, short description and up to two actions.
EmptyStateButton
When to use
- First-run surfaces with no data yet.
- When there is a clear next step the user can take.
- Inside cards, panels and page bodies alike.
When not to use
- For filtered searches with no matches — use no-results.
- For failures — use error recovery.
- While data is still loading.
Live example
No items yet
Nothing has been added yet.
No files yet
Upload a file to get started.
Responsive behaviour
- Content stays centred and width-limited for readability.
- Actions stack vertically on mobile.
- Icon size is fixed so the block never dominates.
Accessibility
- The icon is decorative and hidden from assistive tech.
- The title is a real heading in the page outline.
- The primary action is the first control in tab order.
Error Recovery Pattern
A recoverable failure with retry and an optional secondary route out, in network, permission or generic form.
ErrorStateButton
When to use
- When a request fails and retrying may succeed.
- When access is unavailable and the user needs an explanation.
- In place of content that could not load.
When not to use
- For field-level validation errors.
- For transient issues better shown as a toast.
- When there is simply no data — use the empty experience.
Live example
Connection lost
The content could not be loaded. Check the connection and try again.
Responsive behaviour
- Stays centred and width-limited at every breakpoint.
- Retry and secondary action stack on mobile.
- Copy wraps rather than truncating.
Accessibility
- The error is described in text, never by colour alone.
- Retry is focusable and clearly labelled.
- Replacing content keeps a predictable focus target.
Loading Experience Pattern
Chooses the right waiting affordance: skeleton, spinner, determinate progress or an indeterminate state.
SkeletonSpinnerProgressLoadingState
When to use
- Skeleton when the content structure is known.
- Spinner for short operations in a control or small region.
- Progress when completion is measurable.
When not to use
- Several concurrent spinners on one screen.
- A full-page loader for a small local update.
- Fake progress that does not track real work.
Live example
- Skeleton
- Use when the page or content structure is known.
- Spinner
- Use for short operations inside a control or region.
- Progress
- Use when measurable progress is available.
- Indeterminate
- Use when completion cannot be calculated.
Responsive behaviour
- Skeletons mirror the layout they stand in for at each width.
- Progress bars run full width of their container.
- Inline spinners never change surrounding layout height.
Accessibility
- Loading regions set aria-busy.
- Progress exposes its value to assistive tech.
- Animation is reduced under prefers-reduced-motion.
Success Experience Pattern
Restrained completion confirmation with an optional label/value recap and next actions.
SuccessStateDescriptionListButtonBadge
When to use
- After a flow that ended somewhere new.
- When a short summary helps confirm what happened.
- When there is a sensible next action.
When not to use
- After every routine save — a toast is enough.
- As a celebration screen with heavy colour.
- When the user should stay in the form.
Live example
Item created
The item is now available in the workspace.
- Name
- Project name
- Status
- Owner
- A. Reyes
Responsive behaviour
- The summary block stays width-limited and centred.
- Actions stack on mobile with the primary action first.
- No full-bleed coloured panels at any width.
Accessibility
- Success is stated in text, not only by a green glyph.
- Focus moves to the outcome heading when it appears.
- The recap is a definition list for label/value semantics.
Actions & notifications
Consistent action sets, ambient updates and keyboard-first shortcuts.
Detail Action Pattern
A record header with status, metadata, one emphasised action and the remaining actions collected in a menu.
ButtonIconButtonDropdownMenuAlertDialogBadgeKeyValue
When to use
- Record surfaces with more actions than fit inline.
- When destructive actions must be kept out of easy reach.
- When status and key metadata belong beside the title.
When not to use
- When a single action is all that exists.
- For bulk actions across records.
- For page-level navigation.
Live example
Item
Onboarding checklist
One emphasised action inline; everything else collected in a single menu.
Reference: ITM-4821Owner: A. ReyesLast updated: 2 hours ago
Responsive behaviour
- Metadata reflows into a stacked list on mobile.
- The primary action stays visible; the rest remain in the menu.
- The menu is width-clamped and flips to stay on screen.
Accessibility
- The menu trigger has an accessible name and full keyboard support.
- Destructive items are labelled, not only tinted.
- Destructive selections open a confirmation instead of acting immediately.
Notification Center Pattern
An icon trigger with an unread count and a grouped, scrollable notification panel with read and unread items.
PopoverNotificationBadgeAvatarEmptyStateButtonDivider
When to use
- Ambient updates that do not interrupt the current task.
- When a history of updates is useful.
- When updates group naturally by recency.
When not to use
- For immediate feedback on a user's own action — use a toast.
- For blocking messages — use a dialog.
- As a primary inbox experience.
Live example
Trigger sits in an application top bar.
Responsive behaviour
- The panel clamps to the viewport width and flips to stay on screen.
- The list scrolls internally rather than growing past the viewport.
- The trigger stays a 44px touch target.
Accessibility
- The trigger announces the unread count in its accessible name.
- Groups are labelled sections; items are a real list.
- Unread state is conveyed by text as well as a marker.
Quick Action Pattern
A command palette for search and quick actions, with grouped recent and suggested actions and keyboard shortcuts.
CommandMenuDialogButton
When to use
- Keyboard-first navigation across a large product.
- When frequent actions are spread across many pages.
- As an accelerator alongside — never instead of — visible controls.
When not to use
- As the only route to an action.
- For long forms or multi-step input.
- For filtering a single list — use search and filters.
Live example
Responsive behaviour
- The dialog is near-full-screen on mobile with a large input target.
- Shortcut hints hide when there is no keyboard.
- The list scrolls internally at every width.
Accessibility
- Type-to-filter with arrow-key navigation and Enter to select.
- The active option is announced as the selection moves.
- Escape closes and restores focus to the trigger.