Choose a Pack or a motion primitive

A Motion Primitive solves one clear behavior problem: fade, slide, stagger, easing, press feedback, or reduced motion. It suits moments when a team already knows the object, state, and interface structure and needs a rule for one local change. Its value is clear boundaries: when it fits, how to tune parameters, which neighboring behaviors it can be confused with, and how low-motion mode retains meaning. It makes local decisions reusable and gives a design system a shared language.

A Product Moment solves a complete scenario: save confirmation, deletion confirmation, filtered results, permission change, or approval request. It organizes trigger, waiting, result, related objects, and recovery into one working interaction. Its value is seeing the whole: saving is more than press feedback; it is the joint result of button, status marker, content state, and possible failure guidance. It suits requirements with several states and actors when a team wants a considered skeleton quickly.

Ask whether the problem can be explained as one state transition. If the answer is “the button becomes Saved,” “a card enters from its current context,” or “a number updates in place,” start with a Primitive because the main need is a local rule. If the answer includes “after submission, wait for the server, change top-of-page status, add a list record, and allow retry after failure,” it is already a Moment. Starting from the complete scenario helps reveal missing states, then you can refine the primitives inside it.

Then ask whether a reliable product structure already exists. A mature settings page may already have clear fields, save bar, and status area, so the team only needs local error or confirmation feedback. A new workflow often lacks status area, recovery path, and information hierarchy, making a Pack a faster whole to discuss. Choosing a Pack does not mean copying its visual style. Treat it as an interaction state template while retaining business objects, brand language, and existing navigation. Choosing a Primitive does not mean creating an isolated effect; it still returns to the page to validate focus, spatial relationship, and accessibility.

An efficient way to adopt a Pack is to retain its state sequence and inspect the primitive actions inside it. Take save confirmation: input feedback says the click was received, state-copy change says Saving or Saved, a brief loading loop appears only while waiting, and top status marker and document content update together on completion. A team can keep that causal chain while changing press strength, copy-switch speed, and status-marker position to fit its own design system. The Pack provides structure; Primitives provide precise control at each structural node.

The reverse use matters as well. When a team starts from one Primitive, such as adding a fade to filtered cards, ask immediately: Should result count update too? How do old cards leave? Does the person need to know the filter remains active? If answers introduce several objects and sequential states, open a Moment such as Filter results as a checklist. This back-and-forth lets the libraries feed each other: basic rules keep Packs from becoming black boxes, while real scenarios keep Primitives from floating in a demo detached from product work.

Customization has three levels. First, change content: names, color, copy, data, and brand voice change while interaction states remain. Second, change rules: duration, curve, reveal order, undo window, and low-motion strategy change. Third, change structure: trigger, actors, state graph, and recovery path change. The first level usually adopts a Pack efficiently, the second returns to related Primitives for tuning, and the third is better served by a new scene spec. Naming the level early prevents “just a small change” from turning into a full interaction rewrite.

Control scope also includes technical boundaries. When a product can use only native HTML, CSS, and a small amount of JavaScript, choose a Pack that runs reliably within those constraints and confirm its state source and event bindings migrate cleanly. When a component belongs to an existing design system, a Primitive’s CSS variables, parameter ranges, and accessibility rules may embed more directly. Whatever the starting point, retain copy-ready implementation guidance, browser-compatibility judgment, and a `prefers-reduced-motion` path. Portability itself is part of design quality.

In practice, use a simple loop: describe the product scene in one sentence; decide whether it is a local behavior or a complete flow; open a reference from the matching directory; bring its states, parameters, and boundaries into the current project; preview in the real interface; feed the verified change back as a Pack candidate or Primitive note. The loop keeps the library close to real problems and prevents it from becoming a one-time inspiration board. Every reuse leaves new evidence for future judgment.

During review, look at two things together: Does this interaction help people understand the current task, and can this basic rule be reused elsewhere? The first protects product semantics; the second protects system quality. If a Pack repeatedly yields the same basic action, that action deserves fuller Primitive documentation. If several Primitives repeatedly combine in one business scenario, that scenario deserves promotion to a Pack. The site’s information architecture then evolves with real use, and people gradually encounter a motion language with both taste and practical delivery.