SaaS Slide-Over & Drawer Panels: Real Screenshots & UX Patterns (2026)
The slide-over — the panel that slides in from the edge of the screen to show or edit a record without leaving the list behind it — is one of the most useful surfaces in modern SaaS, and one of the easiest to get subtly wrong. It is the pattern that lets a user click a row, see the full detail, make an edit, and get back to the list without a full-page navigation and without losing their place, which is exactly why it has quietly replaced the detail-page round-trip across so many well-designed products. But drawers fail in specific, familiar ways: they open so wide they are really just a modal that forgot to center, they trap the user with no obvious way out, they lose unsaved edits the moment the user clicks the backdrop, they stack drawer-on-drawer until nobody can tell where they are, they fight the modal pattern instead of choosing between the two, and they animate in a way that feels heavy instead of instant. This guide covers the UX that makes a slide-over earn its place — when to use a drawer versus a modal versus a full page, sizing and the visible list behind it, entry and exit, unsaved-changes protection, focus and keyboard handling, nesting, and motion — each shown with real SaaS screenshots instead of mockups.
The slide-over is the panel that slides in from the edge of the screen — almost always the right — to show or edit one record while the list it came from stays visible behind it. It is the pattern that lets a user in Linear click an issue and read the whole thing, in Attio open a contact and edit a field, in Stripe inspect a payment, in Intercom open a conversation detail — all without a full-page navigation, and all without losing the list, the scroll position, or the sense of where they are. That is the entire value proposition, and it is a real one: the slide-over collapses the old click-into-detail-page, edit, click-back-to-list round-trip into a single in-place gesture, which is why it has quietly become the default detail surface across so much of modern B2B SaaS. When it works, the user feels like the detail was always there, one layer above the list, ready to be summoned and dismissed without ceremony.
When it does not work, the failures are specific and repetitive. A drawer that opens so wide it covers the list entirely is just a modal that forgot to center — it has thrown away the one advantage the pattern exists to deliver, the visible context behind it. A drawer with no obvious close affordance, no Esc handler, and a backdrop that may or may not dismiss it leaves users guessing how to get out. A drawer that silently discards a half-finished edit when the user clicks the backdrop or hits Esc turns a convenience into a data-loss trap. A product that opens a drawer to edit one thing, then a second drawer on top to edit a related thing, then a third, produces a stack nobody can navigate. And a product that uses drawers and modals interchangeably, with no rule for which is which, teaches users nothing they can rely on. This guide walks the decisions that separate a slide-over that feels effortless from one that feels like a liability — each shown with real SaaS screenshots so you can see how shipped products actually handle it.
Choose the right container: drawer vs modal vs full page
Before designing the drawer, decide whether it should be a drawer at all, because the slide-over is one of three related containers and using the wrong one is the root cause of most drawer problems. The rule of thumb is about context and depth. A modal dialog centers over a dimmed page and is for a short, focused, interrupting task the user must finish or cancel before doing anything else — a confirmation, a single decision, a create form with a few fields — precisely because it takes the page away. A slide-over drawer is for viewing or editing one item while the surrounding context stays useful behind it — a record detail, an edit panel, a settings sub-section, a filter builder — where the whole point is that the user can still see the list they came from and glance between them. A full page is for a task with enough depth, sub-navigation, or persistence that it deserves its own URL and back-button behaviour — a complex configuration, a multi-tab record, a report. The failure mode is collapsing these distinctions: using a drawer for a task so involved it needed a page (so the cramped panel fights the content), or using a modal for a detail view the user wanted to keep referencing against the list (so the context they needed got hidden). Pick the container by asking what the user needs to see while they work: if they need the background, use a drawer; if they must not be distracted by it, use a modal; if the task is a destination in its own right, use a page. Get this choice right and most of the other drawer decisions get easier.
Keep the list visible — the context behind the panel is the whole point
The single defining advantage of a slide-over over a modal is that the surface it came from stays visible, so a drawer that hides that surface has quietly become a worse modal. This is why width matters so much: a drawer should be wide enough for its content to breathe but narrow enough that a meaningful slice of the list remains on screen, so the user can still see which row they opened, glance at neighbouring rows, and feel the panel as one layer above the list rather than a replacement for it. On a wide desktop that usually means a fixed or max width — comfortable for a form or a record, not the full viewport — with the list dimmed but present beside it. The relationship should be legible: the row the drawer opened from is often highlighted or anchored, so the connection between panel and list is obvious, and closing the drawer returns the user to exactly that spot with scroll position intact. This visible-context property is also what makes drawers so good for triage and rapid review — open a record, act, close, open the next, all without ever leaving the list — a rhythm that a full-page detail view breaks and a centered modal only half-supports. The moment a drawer expands to cover everything behind it, reconsider whether it should have been a full page instead: the pattern only earns its place when the context it preserves is genuinely useful to the task.
Zoho WorkDrive — a real dashboard screen from the SaaSUI library.
Design entry and exit so users always know how to get out
A drawer must make leaving as obvious as arriving, because the fastest way to make a panel feel like a trap is to hide the way out. Every slide-over needs a visible, conventional close affordance — an X in the top corner is the near-universal expectation — and it must also respond to Esc, the key users reach for by reflex to dismiss any overlay. The backdrop is the subtler decision: clicking the dimmed area behind a drawer commonly closes it, and that is a fine default for a read-only or trivially-editable panel, but it becomes dangerous the instant the drawer holds unsaved work (covered next). Entry should feel like the drawer slid in from where it lives, not like a modal that teleported in, and it should be fast — the animation is there to communicate direction and relationship, not to make the user wait. Consider how the drawer is summoned, too: a clear affordance (a row click, a "details" button, an expand icon) that reliably opens the same panel builds the mental model that this content lives one slide away. And when the drawer closes, return focus and scroll to where the user was, so dismissing the panel feels like stepping back rather than being dropped somewhere new. The test is simple: a first-time user should never have to hunt for how to close the thing, and a returning user should be able to open, act, and dismiss without a single moment of hesitation.
appsmith — a real dashboard screen from the SaaSUI library.
Protect unsaved changes — never discard an edit on a stray click
The most damaging drawer bug is the one that loses work: a user opens an edit drawer, types for a minute, then clicks the backdrop or hits Esc out of habit, and the panel vanishes with everything they entered. Because the backdrop-to-close and Esc-to-close conventions are exactly the reflexes users bring to overlays, an edit drawer that honours them blindly is a data-loss machine. The fix is to make the drawer aware of whether it holds unsaved changes and to guard the exits when it does: if the form is dirty, clicking the backdrop or pressing Esc should not silently discard — it should prompt ("Discard changes?") or simply keep the drawer open and nudge the user toward Save or an explicit Cancel. A clean, unmodified drawer can close freely on backdrop or Esc; a dirty one must ask. This is also where the container choice pays off — a drawer built for editing should have unmistakable primary and secondary actions (Save and Cancel) pinned where the user expects them, usually a footer that stays visible, so there is always a deliberate way to commit or abandon that does not depend on guessing what the backdrop does. Some products sidestep the problem with autosave, persisting each change as it is made so there is nothing to lose on close; that is excellent when the model supports it, but it must be communicated (a visible "saved" state) so the user trusts that closing the drawer kept their work. Whichever route a product takes, the non-negotiable is that a routine dismissal gesture must never quietly destroy something the user spent effort creating.
baremetrics — a real dashboard screen from the SaaSUI library.
Handle focus, keyboard, and accessibility like the overlay it is
A slide-over is a layered surface, and it has to behave like one for keyboard and assistive-technology users, not just mouse users. When the drawer opens, focus should move into it — typically to the first field or a sensible starting element — so a keyboard user is immediately working inside the panel rather than tabbing through the list behind it. While the drawer is open, focus should be trapped within it, so Tab and Shift+Tab cycle through the drawer's own controls and cannot wander into the now-inert background; and Esc should close it (subject to the unsaved-changes guard above). When it closes, focus must return to the element that opened it — the row or button the user came from — so their place in the keyboard flow is preserved rather than reset to the top of the page. The drawer should be announced as a dialog to assistive technology, with an accessible label so a screen-reader user knows what opened, and the background content should be marked inert so it is not read out or reachable while the panel is up. These are the same obligations any modal overlay carries, and drawers earn them precisely because, like modals, they sit above the page and take over interaction — the fact that the list is still visible does not exempt the panel from managing focus. Products that skip this ship a drawer that works with a mouse and is unusable with a keyboard, which quietly excludes a real slice of their users.
Avoid drawer stacking — one panel deep, not three
The pattern breaks down fast when drawers open on top of drawers. A user opens a record in a slide-over, clicks a related record inside it that opens a second drawer, follows a link in that to a third, and now there is a stack of panels sliding over each other with no clear map of where the user is, which one Esc will close, or how to get back to the original. Each layer also eats more of the visible list behind it, until the context the drawer existed to preserve is gone entirely. The discipline is to treat one drawer deep as the default and to design the alternatives to related content deliberately: navigate within the same drawer (replace its contents and offer a back control, so the panel becomes a small stack the user can page through in place), or promote the related item to a full page when it genuinely deserves one, rather than reflexively spawning another overlay. If a second drawer is truly warranted for a brief sub-task, make the layering unmistakable and make dismissal predictable, so Esc closes the top panel and returns to the one beneath it rather than collapsing the whole stack at once. But the honest answer most of the time is that a drawer-on-drawer-on-drawer is a sign the flow outgrew the pattern: the moment users need to navigate a hierarchy of related records, a persistent surface (a page, or a master-detail layout) serves them better than an accreting pile of slide-overs.
Keep the motion restrained — a drawer should feel instant, not heavy
The slide-in animation is part of what makes a drawer legible — it communicates where the panel came from and that the list is still there underneath — but it is a signal, not a performance, and it should be quick enough to feel instant. A drawer that takes a beat too long to slide in, eases with an over-elastic bounce, or animates every close with a slow retreat makes the whole product feel sluggish, because this is a surface users open and dismiss constantly, and any latency they add compounds across a workday of triage. The right feel is a short, confident slide with a restrained easing — fast enough that a power user opening record after record never waits on the animation, smooth enough that a first-time user reads the spatial relationship. The same restraint applies to the backdrop: a subtle dim that appears with the drawer is enough to focus attention on the panel without staging a dramatic transition. Motion here should serve comprehension and speed, not decoration; the products whose drawers feel best are the ones where the animation is barely noticed because it never gets in the way. If a drawer's motion is drawing attention to itself, it is too much — trim it until the panel simply appears to be there, one layer above the list, the instant the user asks for it.
The details that separate a great drawer from a modal in disguise
Each rule above is small on its own; a slide-over feels effortless when they are handled together. These are the behaviours mature SaaS products share across their drawer surfaces.
- The container choice is deliberate: drawer for view/edit with the list still useful behind it, modal for a short interrupting task, full page for a destination that deserves its own URL.
- The list stays visible — the drawer is sized so a meaningful slice of the surrounding context remains on screen, and closing returns the user to the exact row and scroll position.
- Exit is obvious: a visible X, an Esc handler, and a backdrop whose behaviour is predictable for the panel's content.
- Unsaved changes are protected — a dirty edit drawer prompts before discarding on backdrop or Esc, or autosaves with a visible saved state, and always offers explicit Save and Cancel.
- Focus moves into the drawer on open, is trapped while it is up, and returns to the triggering element on close; the panel is announced as a dialog and the background is inert.
- Drawers do not stack indefinitely — one deep by default, with in-panel back navigation or promotion to a full page instead of spawning overlay on overlay.
- Motion is restrained: a short, confident slide with a subtle backdrop dim, fast enough that opening record after record never feels like waiting.
- The relationship between panel and list is legible — the opened row is anchored or highlighted so the user always knows where the drawer came from.
Common SaaS slide-over and drawer mistakes
- A drawer so wide it covers the list entirely — a modal in disguise that has thrown away the visible context the pattern exists to provide.
- No obvious close affordance and no Esc handler, so users have to guess how to get out of the panel.
- Discarding unsaved edits the instant the user clicks the backdrop or hits Esc, turning a routine dismissal into data loss.
- Stacking drawer on drawer on drawer until nobody can tell where they are or which Esc closes what.
- Using drawers and modals interchangeably with no rule for which is which, so users can never predict how an overlay will behave.
- Skipping focus management — focus never enters the drawer, is not trapped, or is not returned on close — leaving the panel unusable by keyboard.
- Heavy, slow, or bouncy slide-in animation on a surface users open and dismiss dozens of times a day, making the whole product feel sluggish.
- Losing the user's place on close — resetting scroll or dropping them at the top of the list instead of back at the row they opened.
Frequently asked questions
When should you use a drawer instead of a modal?
Use a drawer when the user needs to keep seeing the surface behind it while they work, and a modal when they must not be distracted by it. A slide-over drawer is for viewing or editing one item — a record detail, an edit panel, a settings sub-section, a filter builder — where the whole value is that the list or page it came from stays visible, so the user can glance between the panel and its context and move through items in place. A modal dialog centers over a dimmed page and deliberately takes that context away, which is right for a short, focused, interrupting task the user should finish or cancel before doing anything else: a confirmation, a single decision, a small create form. If the user would benefit from still seeing the list — triaging records, editing a field while comparing against neighbours, keeping their place — reach for a drawer. If the task demands their full attention and the background would only distract, reach for a modal. And if the task has enough depth, sub-navigation, or persistence that it deserves its own URL and back-button behaviour, it has outgrown both and should be a full page. Choosing the container by what the user needs to see while they work resolves most drawer design questions before they arise.
How wide should a slide-over drawer be?
Wide enough for its content to breathe, but narrow enough that a meaningful slice of the list behind it stays visible — because that visible context is the entire reason to use a drawer instead of a modal. On a wide desktop that usually means a comfortable fixed or maximum width sized to the content (a record detail or an edit form), not the full viewport, with the list dimmed but present alongside. If the content genuinely needs most of the screen to be usable, that is a strong signal it should have been a full page rather than a drawer, because a panel that covers everything has become a worse modal. On smaller screens the calculus changes: a drawer often expands toward full width out of necessity, at which point it behaves more like a full-screen sheet, and the priority shifts to a clear close affordance and preserved scroll position on return rather than a visible list. The guiding question is not a pixel value but a relationship: can the user still tell which row they opened and see enough of the surrounding context to make the drawer worth choosing over a modal? Size the panel to keep that answer yes.
How do you stop a drawer from losing unsaved changes?
Make the drawer aware of whether it holds unsaved edits, and guard the exit gestures when it does. The danger comes from the very conventions users rely on: clicking the backdrop and pressing Esc both commonly close overlays, so an edit drawer that honours them blindly will discard a half-finished form the moment a user does either out of habit. The fix is conditional — a clean, unmodified drawer can close freely on backdrop or Esc, but a dirty one should not silently vanish; it should prompt to discard, or stay open and steer the user to an explicit Save or Cancel. Pin those primary and secondary actions where the user expects them, typically a persistent footer, so there is always a deliberate way to commit or abandon that does not depend on guessing what the backdrop does. The alternative is autosave — persisting each change as it is made so there is nothing to lose on close — which is excellent when the data model supports it, provided the saved state is shown so the user trusts that dismissing the drawer kept their work. Either approach is acceptable; what is not is letting a routine close gesture quietly destroy something the user spent effort creating.
Study real SaaS slide-overs and drawers in the SaaSUI library
Every pattern above is easier to apply when you can see how real products solved it. Browse real slide-over and drawer surfaces — right-side record details, edit panels, filter builders, and settings sub-sections — from shipped SaaS applications like Linear, Notion, Attio, Stripe, Intercom and other polished tools in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products keep the list visible, protect unsaved edits, manage focus, and keep drawer motion fast and restrained rather than heavy.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →