Design System

Responsive

Layouts recompose, they do not shrink. Each region of the system has a defined behaviour at narrow widths, so a mobile screen is a deliberate design rather than a compressed desktop one.

What is this?

A mobile-first responsive model built on Tailwind breakpoints, with per-region recomposition rules and container queries where a component must respond to its own width rather than the viewport.

When to use it

  • Composing any page from layout primitives
  • Adding a toolbar, table or multi-column form
  • Reviewing a screen before it ships

How to use it

  • Design the narrow layout first, then add complexity upward
  • Recompose regions: collapse, stack, or move behind a drawer
  • Drop the least important information first, never the primary action

What to avoid

  • Horizontal page scroll, or a table that scrolls the whole page sideways
  • Hiding a required control at narrow widths
  • Fixed pixel widths that cannot reflow

Breakpoints

Standard Tailwind breakpoints; the system's decisions cluster at md and xl.
TokenMin widthWhat changes
base0pxSingle column, drawer navigation, stacked actions
sm640pxTwo-column metric and card grids
md768pxPersistent sidebar appears, toolbars sit inline
lg1024pxContent grid widens, secondary column returns
xl1280pxSidebar expands from rail to full labels, 70/30 splits

Recomposition rules

What each region does as width decreases.
RegionDesktopNarrow
Primary navigationPersistent sidebar, collapsible to a railDrawer behind a menu button
Page headerTitle, meta and actions in one rowTitle stacks above a full-width action row
Filters & searchInline toolbar with labelled controlsSearch stays visible, filters collapse behind a Filters toggle
Data tablesAll columns, sortable headersLeast important columns drop; identity column stays
Bulk actionsInline bar above the tableSticky bar pinned to the bottom of the viewport
FormsTwo columns with a section asideOne column, section navigation in a drawer
Detail views70/30 content and metadata splitMetadata moves below the content
OverlaysDialog or popoverDrawer or full-height sheet

Do & don't

Do

  • Keep the primary action reachable at every width.
  • Let tables scroll inside their own container, not the page.
  • Use container queries when a component appears in columns of different widths.
  • Verify every reference screen at 390px, 834px and 1280px.

Don't

  • Do not hide required fields or destructive confirmations on mobile.
  • Do not reduce font sizes to force content to fit.
  • Do not switch a control's type between breakpoints — switch its container.
  • Do not rely on hover-only affordances for touch users.

Why it is designed this way

Defining behaviour per region rather than per screen means a new page inherits the same mobile decisions the reference screens already demonstrate. That is what keeps a data-dense product usable on a phone: the layout changes shape, while priority order stays exactly the same as on desktop.