Dynamic Trays
Dynamic trays keep the base interface simple while revealing advanced, contextual actions inside adaptive bottom-sheet flows.
Dynamic trays are a progressive-disclosure pattern for complex products. They let a product keep its default screen uncluttered while surfacing deeper actions, warnings, payment choices, regional settings, or education only when the user is already in that context. Benji Taylor described the Family wallet tray system as the way Family made a complex crypto product feel simple, fluid, and welcoming; he later said X is bringing the same dynamic tray model into advanced X flows. Source: Benji Taylor, "Family Values", 2024-07-08; Source: X/@benjitaylor, 2026-06-26
Interaction Model
Use a dynamic tray when the user should stay anchored to the current surface while briefly entering a deeper action. Compared with a full-screen route, the tray preserves context: the underlying content remains the place the action belongs.
The reusable rules from the Family/X evidence:
- Trigger trays from explicit user intent: buttons, icons, push notifications, or a selected object.
- Give every tray a title and clear dismiss/back affordance.
- Keep each tray focused on one content block or primary action.
- Vary tray height across sequential steps so progression is visually legible.
- Adapt theme and content to the surrounding context.
- Use trays for transient actions, confirmations, warnings, payment choices, and educational steps.
- Escalate to a full-screen flow only when the task becomes too large for a compact contextual surface.
The reviewed X video shows the pattern in a "Boost Post" flow: the base post remains behind the sheet, the boost setup opens as a tray, payment method and X Money/Apple Pay choices open as deeper trays, region selection appears as a search/list tray, and the final step returns to a confirm/cancel action. The useful detail is not the ad product itself. It is that advanced configuration stays reachable without making the default composer/post surface carry all of that complexity.
Design-System Implication
Trays need to be encoded as first-class primitives, not one-off modals. A design system should specify tray size steps, origin and dismissal behavior, title/icon treatment, nested navigation rules, scrim behavior, keyboard and screen-reader behavior, reduced-motion behavior, and the threshold where a tray becomes a full page.
Pair this with design-engineering-polish for motion and gesture quality. Trays are especially sensitive to height animation, opacity timing, drag boundaries, and perceived continuity. A technically correct tray that jumps, scales from the wrong origin, or loses focus order will read as a constrained modal rather than a contextual surface.
Failure Modes
- Putting every advanced option in the base UI because it might be useful later.
- Treating trays as generic modals with no context-preservation contract.
- Nesting trays without height/label changes, making progress ambiguous.
- Hiding destructive or costly actions behind a pretty sheet without clear confirmation.
- Letting tray content grow until it should have become a full-screen flow.
Timeline
- 2026-07-01 | Promoted Benji Taylor's X dynamic-trays bookmark after reviewing the local video artifact, the Family Values article, the self-thread credit, and the artifact reply linking the Family tray system. Source: X/@benjitaylor, 2026-06-26; Source: Benji Taylor, "Family Values"