UX Patterns
[admin] [ux] [design-system]
Recurring UI patterns in the Admin. This page records how certain interactions should look consistently, both as a reference for providers who expect the behavior and as an anchor for further development.
Today one pattern is documented (sticky save footer). More will follow with the respective sprints.
Sticky save footer on form pages
Where: on most form pages in the Admin, the save button sticks to the bottom edge when the form is longer than the viewport. This way you never have to scroll down to save.
Visual: a narrow white bar with a 1-pixel divider line at the top, save button on the right (on edit forms, additionally a delete button on the left). It stays stuck to the bottom edge until the end of the form is reached.
Where active (as of 2026-05-28, 9 forms):
- Billing (
/settings/billing) - Account editor (portal customer settings)
- Product editor (
/products/[id]/edit) : with a delete button on the left - New product (
/products/new) - Branding (
/settings/branding) - Email templates (
/settings/emails) - Legal texts (
/settings/legal) - Email notifications (
/settings/advanced/notifications) - Invite customer (
/customers/new)
Intentionally NOT active (2 forms):
- Widget settings (
/settings/widget) : save refers to the upper config block. Below it follow the live preview, embed code, and Shopify guide as read-only helpers. A sticky footer would permanently cover these. - Language & Region (
/settings/advanced/language) : same form architecture: save at the top for the language config, status tags about landing page languages below it.
In both cases the "save at the end of the form" refactor would be structurally wrong, because the read-only sections follow on from the configuration in terms of content. If a different behavior is desired long term, that would be its own UX refactor.
Why this pattern: on long form pages (BillingForm ~120 fields, EditProductForm 4 tabs with ~50 fields), finding the save button was a frequent pain point. The sticky footer solves this without breaking the layout: the pattern is additive and changes no existing buttons.
History: foundation in BillingForm (2026-05-15). Cleanup sprint Phase 3 (2026-05-27 to 2026-05-28) rolled the pattern out to 7 more forms.