SaaS List-Detail (Master-Detail) Layout UX Patterns: Real Screenshots (2026)
Open almost any productive SaaS product and you land in the same shape: a narrow list of things on the left, and a wide panel on the right showing the one you picked. An inbox with the message list beside the open email; an issue tracker with the backlog beside the selected issue; a CRM with the contact list beside the open record; a support tool with the conversation queue beside the live chat. This is the list-detail (or master-detail) layout, and it is the workhorse pattern of B2B software because it does two jobs at once — it keeps the whole collection in view so users never lose their place, and it gives the selected item enough room to actually be worked on, without a full page navigation between every click. Done well it feels like a desk where your papers stay spread out: pick an item and its detail appears instantly beside the list, the selection is unmistakable, keyboard users fly through with j/k, and a direct link still opens the right item deep inside the app. Done badly it disorients — the list collapses the moment you click, the selected row is impossible to spot, the detail pane forgets to load or forgets which item it belongs to, and a refresh dumps you back at the top with your place lost. This guide covers the decisions that make a list-detail layout feel like a fast, grounded workspace rather than a maze — how to split the screen, how to keep the list scannable and the selection obvious, how to make the detail pane earn its width, how to preserve context as users move between items, and how to handle empty, loading, and multi-select states — each shown with real SaaS screenshots from shipped products instead of mockups.
Spend a day inside almost any serious SaaS product and you keep meeting the same layout: a list of items running down one side of the screen, and a wide panel filling the rest with the details of whichever item you selected. Gmail and Outlook put the message list beside the open email; Linear and Jira put the issue list beside the selected issue; Intercom and Front put the conversation queue beside the live thread; Notion and Airtable put a row list beside the expanded record; a CRM puts the contact list beside the open profile. This is the list-detail layout — also called master-detail — and it is the single most common shape in B2B software for a simple reason: it lets a user hold an entire collection in view while working on one member of it, moving between items in a single click instead of navigating to a new page and back for every one. When a product is about processing a queue of things — emails, tickets, issues, leads, files, records — this is the pattern that makes the processing fast.
The job of a list-detail layout is to keep the collection and the current item on screen at the same time, so a user never trades context for depth: the list preserves their place and their sense of what is left to do, while the detail pane gives the selected item room to be read and edited properly. It is worth scoping precisely because it neighbours patterns it is not. It is not plain navigation (which moves you to a wholly new destination and does not keep the previous list visible beside it); it is not a data table (which shows many rows of structured columns for scanning and sorting, not a list paired with a rich detail view); and it is not a modal or slide-over drawer (which overlays a temporary detail on top of the current screen rather than sitting permanently beside a persistent list). Master-detail is the two-region workspace — persistent list on one side, full detail on the other, both live at once. The decisions below are what separate a list-detail layout that feels like a grounded, fast workspace from one that disorients users every time they click — each shown with real SaaS screenshots so you can see how mature products split the screen, mark the selection, and keep people oriented as they move through a queue.
Choose the split that fits your content and the screen you have
The first decision is the shape of the split itself: how wide the list is, how wide the detail is, and what happens when the screen is too narrow to show both. The strong pattern sizes the two regions to the work — a list pane wide enough to show each item’s meaningful summary (sender, subject, status, timestamp) without truncating everything to uselessness, and a detail pane wide enough that the selected item does not feel cramped, often with the ability to drag the divider so a user can favour whichever side their task needs. It picks the two-pane side-by-side view when the screen affords it and the workflow is queue processing, because seeing list and detail together is the whole point; and it degrades honestly on narrow screens by switching to a stacked, drill-down model — list first, tap to push the detail in, a clear back affordance to return — rather than trying to cram two panes into a phone width where neither is usable. It considers a three-pane variant (folders/filters, then list, then detail — the classic mail layout) only when the extra navigation column genuinely earns its space. The anti-patterns are a list so narrow every item is an unreadable ellipsis, a detail pane so squeezed the content wraps into noise, a fixed split that cannot flex for different tasks, and a desktop two-pane layout crushed unchanged onto mobile so both halves are broken. Fit the split to the content and the viewport, and let it adapt instead of shattering.
Keep the list scannable and the current selection unmistakable
The list pane is a navigation surface a user scans dozens of times a minute, so its density, its item summaries, and above all its selected state decide whether the layout feels fast or frustrating. The strong pattern gives each list item a compact, information-rich summary — the two or three fields that let a user decide whether to open it (who, what, when, and a status or unread marker) — at a density that shows enough of the queue to give a sense of scale without becoming an unreadable wall. It makes the currently selected item impossible to mistake: a clear highlight or accent bar that reads instantly against both the unselected rows and the hover state, so a user glancing back at the list always knows exactly where they are. It distinguishes states that matter — unread versus read, resolved versus open, mine versus unassigned — with weight and colour rather than requiring the user to open each item to find out. And it keeps the list’s scroll position and selection stable as the detail changes, so moving between items never makes the list jump. The anti-patterns are list items so sparse they force an open-to-find-out on every one, a selected state so subtle it is indistinguishable from hover or from nothing, unread and read rows that look identical, and a list that reshuffles or scrolls itself every time the selection changes. Make the list tell users what each item is and, unmistakably, which one they are looking at.
Make the detail pane earn its width — and stay in sync with the list
The detail pane is where the actual work happens, so it has to reward the space it takes: it should show the selected item in full, load the moment the selection changes, and never leave a user staring at content that belongs to a different row. The strong pattern renders the complete, workable detail — the full email and its reply box, the issue with its description, comments, and properties, the record with all its fields and related items — laid out for reading and editing rather than a thin echo of the list summary. It updates instantly and visibly when the selection changes, showing a lightweight loading state (a skeleton in the pane, not a full-screen spinner that hides the list) so the transition feels responsive and the list stays put. It guarantees the pane and the list agree: the detail always reflects the row highlighted in the list, and an action taken in the detail (mark resolved, change status, delete) is reflected back in the list item immediately, so the two never tell different stories. It keeps the detail scoped to one item — related things link out or expand in place rather than silently swapping what the pane is about. The anti-patterns are a detail pane that merely repeats the list summary and forces yet another click to see anything real, a selection change that blanks the whole screen or spins forever, a detail that lags a step behind the highlighted row, and a list item whose status never updates after you change it in the detail. Give the pane real content, keep it in lockstep with the list, and load it without hiding everything else.
CommandBar — a real dashboard screen from the SaaSUI library.
Preserve context as users move between items — selection, keyboard, and deep links
The reason to use a list-detail layout at all is throughput — moving through a queue quickly without losing your place — so the behaviours that preserve context as users navigate are the ones that make or break it. The strong pattern keeps the selection and scroll position sticky: after you act on an item, the list holds its place (and a well-designed queue can advance to the sensible next item rather than dumping you back at the top), so processing forty tickets feels like a rhythm instead of forty fresh starts. It supports full keyboard navigation — arrow or j/k to move the selection through the list, Enter to focus the detail, shortcuts to act on the current item — because power users live in these layouts and a mouse-only master-detail is slow by design. It makes each item deep-linkable: selecting an item updates the URL so a direct link, a browser refresh, or a shared link opens the app with that exact item selected inside its list, rather than resetting to an empty pane or the top of the queue. And it makes the browser Back button behave sensibly, returning to the previous selection rather than leaving the app. The anti-patterns are a selection that resets to the top after every action so the user loses their place, no keyboard path so the fast pattern is crippled by mousing, an item that cannot be linked to or survives no refresh, and a Back button that either does nothing or blows away the whole view. Keep users’ place, let them fly with the keyboard, and make every item a real, linkable location.
Confluence — a real dashboard screen from the SaaSUI library.
Handle empty, loading, and multi-select states so the layout never looks broken
A two-region layout has more states than a single page, and the ones around no selection, no items, loading, and multiple selection are exactly where lazy implementations fall apart. The strong pattern gives the detail pane a purposeful empty state when nothing is selected — a short prompt to pick an item, or a useful summary of the queue — rather than a jarring blank void beside a full list. It handles an empty list (no items yet, or a filter that matches nothing) with a real empty state that explains why and offers the next action, and it distinguishes an empty result from a still-loading one with skeletons so users are not left guessing. When the pattern supports acting on many items at once, it makes multi-select coherent: checkboxes or shift-click build a selection, a clear count and a contextual action bar appear, and the detail pane either shows a sensible summary of the selection or steps aside for the bulk toolbar — never a detail of one arbitrary item while five are selected. It also handles the deleted-or-moved current item gracefully, falling back to the next item or the empty state instead of showing a detail of something that no longer exists. The anti-patterns are a raw blank pane on first load, an empty list with no explanation, a loading state indistinguishable from a truly empty one, and a multi-select that leaves the detail showing a single confusing item. Design the in-between states deliberately, because in a list-detail layout users hit them constantly.
The details that separate a grounded list-detail from a disorienting one
Each decision above is modest on its own; a list-detail layout feels like a fast, grounded workspace — one where users keep their place, always know what they are looking at, and move through a queue in a rhythm — when they are handled together. These are the behaviours mature SaaS products share across their inboxes, issue lists, record views, and conversation queues.
- The split is sized to the content and the task — a list wide enough to show meaningful summaries, a detail wide enough to work in — and it degrades to a stacked drill-down on narrow screens instead of crushing two panes onto a phone.
- List items carry a compact, information-rich summary (who, what, when, status) so users can triage without opening every one.
- The currently selected item is unmistakable — a clear highlight or accent that reads instantly against both unselected rows and the hover state.
- Meaningful states (unread/read, open/resolved, mine/unassigned) are shown in the list with weight and colour, not hidden until you open the item.
- The detail pane shows the full, workable item and loads with a skeleton in-pane when the selection changes — the list stays visible and in place, never blanked by a full-screen spinner.
- List and detail stay in lockstep: the pane always reflects the highlighted row, and an action in the detail updates the list item immediately.
- Selection and scroll position are sticky after actions (and a queue can advance to the next item), so processing many items feels like a rhythm, not repeated fresh starts.
- Full keyboard navigation (arrow or j/k to move, Enter to focus the detail, shortcuts to act) makes the fast pattern actually fast for power users.
- Every item is deep-linkable — selecting it updates the URL so a direct link, refresh, or shared link opens the app with that exact item selected inside its list.
- Empty (no selection / no items), loading, and multi-select states are designed deliberately, and a deleted current item falls back gracefully instead of showing a ghost detail.
- List-detail stays distinct from plain navigation (which leaves the list behind), the data table (rows and columns for scanning), and the modal/slide-over drawer (a temporary overlay, not a persistent second region).
Common SaaS list-detail (master-detail) mistakes
- The list collapses or navigates away the moment you click an item, so you lose the queue and your place with every open.
- The selected row is styled so subtly it is indistinguishable from hover — users cannot tell which item the detail belongs to.
- List items are so sparse they force an open-to-find-out on every one, turning triage into a slog.
- The detail pane just repeats the list summary, so the second region adds width without adding information.
- Changing the selection blanks the entire screen with a full-page spinner, hiding the list instead of loading a skeleton in the pane.
- An action in the detail (resolve, reassign, delete) does not update the matching list item, so the two panes disagree.
- After acting on an item the selection resets to the top of the list, destroying the rhythm of processing a queue.
- There is no keyboard navigation, so a layout built for speed is crippled by mouse-only movement.
- Items cannot be linked to and do not survive a refresh — a shared link or reload dumps the user at an empty pane or the top of the list.
- The no-selection and empty-list states are raw blank voids with no prompt, and multi-select leaves the detail showing one arbitrary item.
Frequently asked questions
When should I use a list-detail (master-detail) layout instead of separate pages or a table?
Reach for list-detail when the core job is processing or browsing a collection where users repeatedly move between the whole and one member of it — inboxes, ticket queues, issue backlogs, lead lists, file browsers, record views. The pattern’s value is keeping the collection and the current item on screen together so navigation between items is a single click and the user never loses their place; if your workflow has users hopping among many items in a sitting, that throughput is exactly what you want. Prefer separate full pages when each destination is genuinely standalone and users rarely need the previous list beside it — a settings page or a checkout is not a queue. Prefer a data table when the task is scanning, comparing, and sorting many rows by their columns rather than opening one to work on it in depth, though the two combine well: a table row can open a detail pane or drawer. And prefer a modal or slide-over drawer when the detail is a brief, temporary interruption over the current screen rather than a persistent second region you live in. If users process a queue, list-detail; if they compare rows, a table; if they glance at one thing briefly, an overlay.
How should a list-detail layout behave on mobile?
On a phone there is not room for two useful panes side by side, so the honest answer is to switch to a stacked, drill-down model rather than shrinking both regions until neither works. Show the list first, full width, at a comfortable density; tapping an item pushes the detail in as its own full-screen view with a clear back affordance (a labelled back button or an edge-swipe) that returns to the list at the exact scroll position and selection the user left. Keep the deep-linking and state behaviour intact so a shared link still opens the right item, and consider carrying forward next/previous controls in the detail so users can move through the queue without bouncing back to the list every time. On tablets and large phones in landscape you can often restore the true two-pane view, so treat the split as responsive rather than a fixed desktop-only shape. The mistake to avoid is rendering the desktop two-pane layout unchanged on a narrow screen, which leaves a cramped list and a cramped detail that are both frustrating; adapt to the viewport instead of forcing it.
How do I keep the list and detail pane from getting out of sync?
Treat the selected item as a single source of truth that both regions read from, so they can never tell different stories. The detail pane should always render whatever item is highlighted in the list, and the highlight should always match what the pane shows — there is one selection, and both sides reflect it. Just as important, changes flow both ways: when a user acts in the detail (marks a ticket resolved, changes a status, deletes a record), the corresponding list item must update immediately — its badge, its position if the list is sorted by that field, its presence if a filter now excludes it — so the list never shows stale state. Load the detail with an in-pane skeleton when the selection changes rather than blanking the screen, so the sync is visible and the list stays put. Handle the edge where the current item disappears (deleted, moved, filtered out) by advancing to the next sensible item or falling back to the empty state, never leaving a detail of something that no longer exists. When both panes derive from one selection and one item state, they stay in lockstep by construction instead of by luck.
Study real SaaS list-detail and master-detail layouts in the SaaSUI library
Every decision above is easier to apply when you can see how real products solved it. Browse real two-pane and three-pane master-detail layouts, scannable list panes with unmistakable selected states, full-width detail panes that load in-pane while the list stays put, keyboard-driven queue processing, deep-linked item URLs, and deliberate empty, loading, and multi-select states from shipped SaaS applications like Linear, Notion, Intercom, Front, Airtable and other polished products in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products split the screen, keep the list scannable and the selection obvious, make the detail pane earn its width, preserve context as users move between items, and handle the in-between states that a single-page layout never has to.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →