A component library can tell a team how to render a table, an alert and a dialog. It may still leave the team to invent what happens when a bulk update partly succeeds, an approval expires or two people edit the same record. The visual pieces are shared; the behavior remains local.

That gap becomes visible in complex products. Users encounter familiar controls but different rules. One product preserves selection after filtering; another clears it. One save indicator means the server acknowledged the change; another means the request has merely been queued. Consistency at the component level can conceal inconsistency at the task level.

The seven patterns below are a practical shortlist for mature enterprise systems. They are not a universal maturity model or a requirement to build seven new components. They describe recurring interaction problems that need shared decisions, documented contracts and examples from real workflows.

I would prioritize them according to actual product demand. A small informational website may not need concurrency resolution. A multi-role operations platform probably does. The important question is whether teams can use the system to solve their common work, rather than whether the library contains enough objects.

Repeated units gain meaning through composition and context. Architectural analogy for components and higher-level patterns. Credit: Danist Soh / Unsplash.

What makes a pattern different from a component?

A component is a reusable building block with an API and defined behavior. A pattern describes how building blocks cooperate to solve a user problem in context. The boundary is not absolute, but the distinction is useful when deciding what to document.

A confirmation dialog is a component. Safely changing a set of records involves selection scope, eligibility, confirmation, processing, partial results and recovery. That is a pattern. It may use several components and still require business rules supplied by each product.

A useful pattern contract names the user intent, prerequisites, state transitions, content requirements, accessibility behavior, extension points and failure handling. It also explains when not to use the pattern. Without those boundaries, reuse can spread an inappropriate solution as efficiently as an appropriate one.

1. Search, filtering and finding your way back

Finding information is more than adding a search field above a table. The pattern needs to explain query scope, active filters, result count, empty results, preserved context and the relationship between list and detail views.

Imagine a hypothetical operations user reviewing supplier records. They filter by region and status, open a record, then return. If the product clears the filters or loses their place, a simple lookup becomes repeated setup. A shared pattern should specify which state is retained and how the person can understand the restored view.

Separate search from filtering where their meanings differ. A query might match names and identifiers; a filter might limit eligibility or ownership. Explain the scope in language users can understand. “No results” should make it possible to identify and remove the constraints that produced the result, without suggesting that records were deleted.

Document whether filters apply immediately or after an explicit action, how counts update, and what happens during loading. Define keyboard access and accessible naming for removable filter controls. Include long queries, narrow viewports and permission-restricted results in examples. The shared contract should support a coherent finding experience while allowing the product to supply its domain fields.

2. Selection, bulk action and partial success

Bulk work creates questions that a checkbox component cannot answer. Does “select all” mean the current page, all loaded items or every result matching the query? Does selection survive a filter change? Can some selected records be ineligible for the action?

The pattern should make scope visible before the user commits. For an illustrative batch of invoices, the interface might distinguish selected visible rows from all matching invoices. If the action affects items outside the visible page, the confirmation needs to preserve that distinction. Do not rely on the user inferring it from a small count.

After processing, communicate actual outcomes. If some records fail, show successful and unresolved groups, the reasons permitted by policy and a safe next action. Retrying only failures may be appropriate, but engineering must establish whether repeated requests can duplicate effects. UI language cannot make a non-idempotent operation safe.

Document the selection model, confirmation rules, permission checks, asynchronous state and result summary together. Include the case where eligibility changes between selection and submission. Keep domain policy outside the shared component while requiring each product to explain its consequences. A bulk-action toolbar without this contract standardizes appearance while leaving the hardest decisions unresolved.

Carbon’s published batch-action example connects selection, available actions and cancellation. Credit: IBM / Carbon Design System.

3. Forms that survive interruption

Complex forms need a preservation and recovery pattern, not just field components. The contract should state when validation occurs, how errors are associated with fields, what survives a failure and how users resume an interrupted task.

For a hypothetical supplier application, a user may enter company details, add documents and wait for a lookup service. If the lookup fails, the product should distinguish a dependency problem from invalid user input. Asking the person to correct an already valid field misassigns responsibility and may encourage pointless retries.

Define draft behavior explicitly. Is a draft saved locally or remotely? Can it be accessed on another device? Does a session expiry preserve unsent work where policy allows it? Which data must never be retained? These questions belong in the interaction contract and its implementation guidance.

The GOV.UK check-answers pattern is a useful reference for reviewing information before submission and returning to change it. A review page is valuable only if the edit route preserves the task context. Your system should also define focus and error-summary behavior rather than treating validation as a red border variant.

Selection is an interface state; eligibility is a domain decision. This supplier table is an original hypothetical example. Credit: Original editorial visual prepared for Andrea Mabellini.

4. Permissions, approvals and delegated responsibility

Permission design often appears as a disabled button. That is insufficient when people need to understand who can act, why they cannot and how work progresses between roles. A reusable pattern should describe the boundary without exposing information the person is not authorized to see.

Distinguish the inability to view an object from the inability to perform one action on it. Also distinguish a missing permission from a pending approval. These conditions may have similar visual treatments but different recovery routes. Requesting access is not the same as asking someone to approve the current work.

For an approval sequence, show the relevant actor, current state and permitted next action. Explain what happens when the approver is unavailable, the request changes or authorization expires. A changed request may require renewed approval; the product must not imply that an earlier decision applies automatically.

The system can supply structure and content rules while each product supplies policy. Security must enforce authorization independently of interface controls. Document safe disclosure, state changes and escalation routes with engineering and domain owners. Reusable visual components should not be mistaken for a complete authorization model.

5. Asynchronous work, progress and result verification

A spinner does not tell users whether they can leave, whether the task is still running or whether a result has been committed. Long-running work needs a pattern covering acceptance, processing, completion, failure and the return journey.

For a report export, the user may need an acknowledgement that the request was received, a way to inspect status and a later route to the result. For a consequential update, they may also need confirmation of the affected version. These are different promises and should not share an ambiguous “Done” label.

Specify what each state means in terms of system events. Queued should mean queued. Saved should reflect the persistence condition the product promises. If progress cannot be measured accurately, do not fabricate a percentage. Explain what is known and provide the next useful action.

Include timeout, cancellation and reconnect behavior. Cancellation may stop queued work without reversing effects already completed; the interface must communicate that boundary. Notifications should link back to a durable result where appropriate. Accessibility guidance should cover status announcements and focus without making every background event interrupt the user.

A mature interface coordinates repeated controls with state, grouping and task intent. Physical interface analogy. Credit: Magnus Skaare / Unsplash.

6. Concurrent editing and version conflict

Shared records create a recurring problem: the version a person reviewed may no longer be the version being changed. A mature pattern should distinguish a conflict from a failed save and make the available resolutions understandable.

Imagine two administrators editing a policy record. One changes the effective date while the other changes an eligibility condition. The appropriate response depends on the data model and business meaning. Automatic merging may be safe for some independent fields and unsafe for changes that interact. The design system should not prescribe merging without that context.

The shared pattern can require a clear account of what changed, whose unsaved work is retained and which version will be committed. It can provide structures for comparing versions, reloading safely or requesting review. Products supply the conflict rules and identify changes that cannot be resolved automatically.

Include the case where permissions changed during editing. Preserving a draft does not imply permission to submit it. Avoid showing “Save again” when the action would silently overwrite newer work. A concise, honest explanation is more useful than a generic error that makes the user guess whether their work exists anywhere.

7. Evidence, history and consequential change

When people make important decisions, they often need more than a current value. They need to know where it came from, what changed and whether an action can be corrected. This is a pattern for provenance and change understanding, not merely an activity-feed component.

For a hypothetical compliance record, show the current state alongside the relevant source and change history where permitted. Distinguish an observed fact from a recommendation or inferred value. If AI supplied a suggestion, the interface should not visually erase the difference between that suggestion and an approved record.

History should support a question: who changed what, under which conditions, and what can be done now? Avoid overwhelming people with every technical event. Domain and security owners need to define retention and disclosure; the design pattern should make the resulting information understandable.

Reversal also needs a contract. Some changes can be undone directly. Others require a compensating action or another approval. Label the action according to what it actually does. A system-wide “Undo” pattern is unsafe if products attach it to actions with different guarantees. The shared guidance should explain how to communicate those distinctions before and after commitment.

Shopify’s published extension example places domain actions inside an existing task surface. The example order data belongs to the documentation. Credit: Shopify.

Document behavior with a real example and a deliberate exception

For each pattern, include a complete example with realistic difficulty. A search example should include no results and return navigation. A bulk-action example should include ineligible items and partial completion. An approval example should include a changed request rather than only the first successful submission.

Then include an exception that tests the boundary. Explain why the pattern may not fit and what alternative the product should consider. This is often more valuable than adding another visually identical variant. It helps consumers make decisions rather than copy screenshots.

The WAI-ARIA dialog guidance provides a useful component-level reference for focus and keyboard behavior. A task-level pattern must then explain when opening a dialog is appropriate and what happens after the decision. Accessibility and product semantics need to connect across those levels.

Promote a pattern only when the shared need is real

Patterns are expensive to maintain because they encode more assumptions than visual primitives. Before promoting one, collect representative workflows from the products that need it. Identify what is common, what varies legitimately and what remains domain-specific.

Pilot the proposed contract in more than one relevant context when feasible. This is a practical test of transferability, not a universal numerical threshold. If the second context needs extensive exceptions, the proposed abstraction may be too broad or based on the first product’s terminology.

Assign ownership for design guidance, implementation and updates. The USWDS lifecycle offers a reference for making maturity visible. Apply the principle to patterns: consumers should know whether guidance is experimental, stable or being replaced, and what that status means for adoption.

Measure the gap between shared pieces and shared decisions

Maintain a small coverage map connecting common tasks to the patterns that support them. For each entry, show the current guidance, known implementation gaps and a consumer who can demonstrate the behavior. This is more informative than a gallery of component names because it reveals whether a team can complete the task with the system as it exists today.

For a proposed pattern update, review a consumer’s acceptance criteria alongside the documentation. If both describe “partial success” differently, resolve the meaning before refining the visuals. Capture that resolution as a change to the contract and explain which products need to adapt. This helps prevent the documentation from looking authoritative while live behavior continues to drift.

The broader challenge of providing structured rules for tools is covered in my article on AI-ready design systems. Here, the priority is identifying the task semantics that deserve those rules in the first place.

Component usage alone will not reveal whether a pattern is working. Inspect whether products implement the agreed state semantics, preserve the required data and communicate outcomes consistently. The same imported components can support very different behavior.

Useful signals include recurring support questions, repeated local workarounds, unresolved contribution requests and divergence in acceptance criteria. These indicate where a pattern may help. They do not prove that every variation should be removed. Some differences reflect legitimate workflow needs.

Ask consumers whether they can make the intended decision from the documentation without contacting the system team. If they can find the component but not determine its appropriate use, the system has a discoverability or guidance problem. Adding more variants may make that problem harder.

The visible status should correspond to an event the system knows occurred. This simplified sequence is conceptual. Credit: Original editorial visual prepared for Andrea Mabellini.

Why this matters when AI assembles interfaces

An AI tool can select familiar components and still compose the wrong behavior. It may apply a toast to an outcome requiring durable verification, offer an unsafe retry or create a permission state that reveals too much. Visual consistency does not resolve semantic gaps.

Patterns make the expected decisions explicit: which state triggers the feedback, what must be preserved and which action is safe next. That context complements the technical connections described in my Figma MCP and design-to-code guide. Mapping components helps tools reuse the system; documenting patterns helps teams judge whether the resulting experience is appropriate.

A mature design system earns its value in the moments when the pieces alone are insufficient. Start with the interaction problem your product teams repeatedly solve badly or differently. Build a contract around it, test it in real work and keep its ownership visible. That is how a library becomes a dependable way to design products.