Some configuration only makes sense next to the thing being configured. Setting up inbox previews for an email is the case this pattern was built for: every choice is about how that email renders, so the email itself has to stay on screen while the choices are made. Take it away and each step becomes a guess that can only be checked by finishing the flow.

Build it from a SetupFlow and the preview side by side in a SplitView, inside a Drawer at size="page".

Structure

size="page" is the size to use here. It is viewport-relative rather than a fixed width — 90% of the viewport, capped at the same maximum width as a Page — so there is room for two working columns. The other sizes are fixed widths meant for a single column of content, and a split view inside one leaves both halves too narrow to work in.

Inside the drawer:

DrawerBody — required for the body to handle overflow scrolling correctly.
SplitView — give it a height. It fills the body rather than sizing to its content, so without one the panes collapse.
A SplitViewPane holding the SetupFlow.
A SplitViewResizer — resizers are not inserted for you. A SplitView with no resizer between its panes is a fixed layout, not a resizable one.
A second SplitViewPane holding the preview.

Loading editor

Sizing the panes

Start the preview pane at 30% and refine from there — a preview of a phone-shaped email wants less than a preview of a table. What the number should never do is pass 50%.

The steps are the task and the preview is reference material. Up to about a third, the preview is large enough to read and the flow still owns the screen. Past halfway the relationship inverts: the form the person is actually filling in becomes the smaller of the two, and the preview stops supporting the configuration and starts competing with it. Cap it with maxSize="50%" so a drag cannot get there either.

SplitView sizes are percentages of the space available to panes, and the visible panes always add up to 100. Two equivalent ways to seed them:

defaultSize on a single pane, as in the example above. The pane that declares nothing takes the rest.
defaultSizes={[70, 30]} on the SplitView, listing every pane in DOM order.

Write percentages as strings — "30%", or the unitless "30". A bare number is pixels, so defaultSize={30} gives you a 30px sliver rather than 30% of the split.

Give the steps a floor as well as the preview a ceiling. minSize="50%" on the flow pane keeps form fields from being squeezed into a column too narrow to fill in.

The preview is the feature's

Pluma defines the space, not what goes in it. The second pane is a plain SplitViewPane and the feature renders whatever the preview is — an iframe, a canvas, a list of thumbnails.

That means the pane owns its own states, and it has to hold all three without reaching outside itself:

Loading. A Spinner inside the pane while the preview renders. The steps stay live throughout — a preview that takes four seconds to regenerate must not freeze the form that triggered it.
Failed. An explanation of what went wrong and a Refresh action, in the pane. A preview failing to render is not a reason to block the configuration; someone may well know what they want without seeing it.
Ready. The preview.

The one thing the preview must never do is gate the flow. Every step stays operable whatever the pane is showing.

When not to use it

Only use the split when there is something live to show. If the second pane would hold help text, an illustration, or a static example that never responds to the choices being made, there is no preview — drop the SplitView and put the SetupFlow in a narrower Drawer on its own.

An inert second pane costs real width and teaches people to ignore that half of the screen, which is exactly the half a real preview needs them to watch. Help text belongs with the field it explains.

Closing the drawer

A drawer holding a flow with unsaved input should not close on a stray Escape or a click on the overlay. Guard it with a ConfirmationModal: title the question, label the confirm "Discard" and make it isCritical, and label the cancel "Keep editing". Cancel is the safe default, and dismissing the confirmation resolves the same way, so an Escape at either level leaves the work alone.

A pristine flow closes silently. Someone who opened the drawer, changed nothing and pressed Escape has nothing to lose, and a confirmation there is noise that trains people to dismiss the next one without reading it.

This is the container's job. SetupFlow tracks which step is open, not whether the surface holding it may go away.

const confirmDiscard = useConfirmationModal();

const handleClose = async () => {
	if (!isDirty) {
		setIsOpen(false);
		return;
	}

	const isConfirmed = await confirmDiscard({
		title: 'Discard this setup?',
		message: 'The steps you have filled in will not be saved.',
		confirmLabel: 'Discard',
		cancelLabel: 'Keep editing',
		isCritical: true,
	});

	if (isConfirmed) {
		setIsOpen(false);
	}
};

Compared to the wizard layout

Both shapes walk someone through an ordered set of decisions, and they differ in how much of the flow is on screen at once.

The wizard layout pages the flow: one step per screen, a Stepper at the top of a Page to say where you are, and Back and Next to move between screens. The steps you are not on are a progress indicator, not content.

This pattern keeps every step on one surface. Completed steps collapse into a one-line summary of what was chosen and stay in place, so the whole configuration reads top to bottom while the current step is open, and any earlier decision can be reopened where it sits. That is what lets the preview mean something: the choices behind what is rendered are all still visible beside it.

Pick the wizard when the steps are long enough that one of them fills a screen. Pick this one when the steps are short, the decisions inform each other, and there is something live to check them against.