UX · Enterprise

Print Views Are a Different UI: Designing for Paper in a Web App

Wrapping the live screen in `@media print` looks like it should work. On a real roster or report, it almost never does.

Jaymin Maheta 28 Feb 2026 6 min read

@media print is a patch, not a design

The instinct is reasonable: hide the nav, hide the buttons, let the browser's print dialog handle the rest. It works for a simple invoice. It falls apart for a weekly roster with 40 staff rows, a task board meant to be scanned on a wall, or any report with charts, color coding, or a layout genuinely optimized for a 1200px screen.

Managers who print rosters for a shift handover, or staff who print a task list for a site without reliable device access, aren't edge cases in enterprise software — they're a real, recurring workflow that deserves its own design pass.

What a real print view needs that the screen version doesn't

A separate route, not a CSS toggle

Build `/roster/print` as its own view with its own layout logic. Trying to make one component serve both screen and paper compromises both.

Explicit page-break control

Use `break-inside: avoid` on rows and cards so a shift entry or task never splits mid-content across two pages — the single most common print complaint.

Color-independent status indication

Most office printers are black and white. Pair every color-coded status with a label, icon or pattern so the printed page still communicates the same information.

Fixed, print-appropriate typography

Screen font sizes optimized for a monitor often print too small or waste too much paper. Set explicit point sizes for the print stylesheet rather than inheriting screen `rem` values.

Repeat table headers on every page

`thead { display: table-header-group }` keeps column headers visible on every printed page of a long table — without it, page two of a roster is unreadable on its own.

A print-preview step before the OS dialog

Show the formatted print view in the app first, with a "Print" button, rather than jumping straight to `window.print()` on the live screen and hoping the browser's print CSS handles it well.

Test on paper, not in the browser's print preview

Browser print previews are more forgiving than actual printers and paper. Page breaks that look fine in Chrome's preview sometimes land differently once a real print driver and paper size are involved. Print an actual page before calling a roster or report print view done — it catches spacing and break issues no amount of on-screen checking will.

The takeaway

A print view deserves its own route, its own typography, explicit page-break rules, color-independent status indicators, and repeating table headers — not a `@media print` patch bolted onto the live screen layout. If staff and managers actually print rosters and reports, that workflow earns real design time, and a physical test print before shipping.

Let's talk about your frontend