A dialog’s size should follow how much content it holds, not a single hardcoded box

What it is

A dialog’s width and height are a viewport for this content. Size follows content means a short confirm gets a small box and a long form gets a box that can be filled, rather than every conversation sharing one hardcoded rectangle. A box larger than its content makes the question look empty; a box smaller than its content clips it or forces internal scroll too early. This is the match between box and content. It is not whether a narrow screen should go fullscreen, and not how overflow scrolls.

Why it happens

People estimate the size of a task from the area of the box. A small box around two lines of confirm reads as light; the same two lines in a large empty frame look as if steps are missing. Conversely, a real multi-field form jammed into a small box is already scrolling before filling starts, so the task is underestimated in weight and overestimated in cost. A hardcoded size presses every task into one weight signal: short ones are inflated, long ones compressed. Following content does not mean the box grows without bound with every wrapped line. There is a readable max width (line length) and a max height relative to the viewport; past those, internal scroll begins. Following content is “shrink to content inside a ceiling,” not “no ceiling.” When content changes (one more validation line, German copy), the box should grow a notch rather than squeeze new words off the buttons.

Studying it

Present the same conversations as fixed size versus shrink-to-content, with short confirms, medium forms, and long copy. Record misjudged task length, how many complete fields are visible on first screen, scrolls to see buttons. Independent variables: sizing strategy, copy length, language. Dependent variables: weight misjudgement, unseen required fields. Short confirms in a fixed large box should produce more “what else is there” hesitation.

Where it stops holding

Content that must be compared side by side (two permission columns) has its own minimum width and cannot shrink to a single-column confirm. Decorative motion or illustration should not drive the box — they are not task content. Jumping to a different size on every dialog makes people doubt they are still in the same kind of control; following content should still land inside a shared min/max, not a random width per dialog.

Applying it

• Set min and max width and height for dialogs, and shrink to content inside that band. Short confirms sit near the min.
• Decorative illustration does not count toward the grow.
• Re-measure after copy or fields change, so buttons are not pushed off the first screen.
• How to check: screenshot a short confirm and a long form. The short one should not be a field of whitespace; the long one’s first screen should show the full question and the main fields.

Related

• Within the group: E4.19.2 On a narrow screen a dialog often has to become fullscreen · E4.19.3 When content exceeds the visible height, scroll inside the dialog rather than bursting the overlay · E4.19.4 A focused element should not jump when the dialog’s size changes
• Adjacent: E4.10 Modal dialogs · E4.03 Tables
• Search terms: dialog sizing · content-sized overlay · modal dimensions