Scaling & displays
The same interface has to work on a reporting workstation, a cart at the bedside, a gantry console and a handover wall. Pixels do not survive that journey — physical millimetres do. This page is how the system converts between them.
Overview
A 44 px button is not a size. It is a size on a particular display. On a 24-inch 1080p monitor it is roughly 11 mm across; on a 10-inch 1920×1200 cart display it is under 6 mm — below the point where a gloved fingertip can hit it reliably. Same code, same token, different hazard.
So the system treats the interface as a whole that scales, rather than a set of components that get individually resized. Type, spacing, stroke and hit area move together by one factor, so proportions and touch targets stay correct by construction.
Physical
Requirements are stated in millimetres and degrees of visual angle, not pixels. A pixel specification that does not name its display is not a specification.
Proportional
The whole interface scales by a single factor. Enlarging type alone breaks hit areas and rhythm — it is not an accessibility fix, it is a new defect.
Deliberate
Scale factor is a per-deployment engineering decision, recorded and tested — never inferred at runtime from a guessed device class.
Terms
| Term | Meaning |
|---|---|
| Screen resolution | Pixels, width × height. 1920×1080. |
| Screen size | Physical diagonal, inches or mm. |
| Pixel size | Physical width of one pixel in mm. Screen width mm ÷ width px. |
| Pixel density | Pixels per inch (PPI). Higher density means each pixel is physically smaller. |
| Design resolution | The artboard size the UI is designed at. Often not the screen resolution. |
| Scale factor | Screen resolution ÷ design resolution. The multiplier applied to the whole interface. |
| Touch target | The physical area that responds to a touch, in mm. |
Two governed floors
Touch target ≥ 10 mm × 10 mm physically on any touch-operated display, and ≥ 12 mm where the task is time-critical, the user may be gloved, or the device may be in motion — a monitor in a moving ambulance, a console during a procedure.
Body text ≥ 12 px, and ≥ 14 px for anything a clinician reads to make a decision, at the final rendered scale. See Typography.
Both are stated at the final rendered size. A design that satisfies them on the artboard and violates them on the target display has not satisfied them.
Automatic scaling — desktop and web
On standard desktop and browser platforms the operating system already handles scaling. The system's job is to define the breakpoint bands and the factor that applies in each, so a 4K reading-room monitor does not render the UI as a postage stamp in the corner.
| Band | Viewport width | Factor | Typical display |
|---|---|---|---|
| Compact | 320 – 639 px | 1× | Handheld, companion app |
| Small | 640 – 1023 px | 1× | Tablet, small cart display |
| Medium | 1024 – 1279 px | 1× | Large tablet, secondary monitor |
| Default | 1280 – 2559 px | 1× | Workstation. The design baseline. |
| Large | 2560 – 3839 px | 1.35× | 2K reporting monitor |
| Largest | 3840 – 4200 px | 1.75× | 4K diagnostic display, wall board |
The factor multiplies the root font size, and every token is expressed in rem, so
the whole interface follows:
/* One line moves the entire system. Every spacing, type and
target token is rem-based specifically so this works. */
html { font-size: 16px; }
@media (min-width: 2560px) { html { font-size: 21.6px; } } /* 1.35× */
@media (min-width: 3840px) { html { font-size: 28px; } } /* 1.75× */A 4K display could show four times the content. In a reading room it usually should not. Beyond the Default band the extra pixels buy legibility at distance, not density — the clinician is further from a wall display, not closer. Adding content instead of scale is the most common way a 4K deployment ends up less usable than the 1080p one it replaced.
Custom scaling — touch platforms
Embedded and touch platforms — patient monitors, cardiographs, gantry consoles, ultrasound carts — do not scale themselves. Here the factor is calculated per device and baked into the build. The method is arithmetic, not judgement.
The five steps
- Measure the screen. Physical width and height to 0.1 mm, and the native resolution. Pixel size = width mm ÷ width px, to 0.001 mm.
- Characterise the use. Distance, mounting angle, gloves, motion, urgency. This sets the target touch size — 10 mm baseline, 12 mm for time-critical or gloved use.
- Compute the actual target. System touch controls are 44 px tall
(
size="lg"). Actual mm = 44 × pixel size. - Derive the factor. Scale factor = desired mm ÷ actual mm.
- Derive the design resolution. Design resolution = screen resolution ÷ scale factor. Design at that size; engineering scales it up at build.
Worked example — bedside patient monitor
Design the UI at 1200×675. Engineering renders it at 1.6× onto the 1920×1080 panel. Every 44 px control lands at 12.2 mm.
The same button on four displays
| Display | Resolution | Pixel size | 44 px = | Verdict |
|---|---|---|---|---|
| 24″ workstation | 1920×1080 | 0.277 mm | 12.2 mm | Passes — pointer input anyway |
| 15″ bedside monitor | 1920×1080 | 0.173 mm | 7.6 mm | Fails — scale 1.6× |
| 10″ handheld cart | 1280×800 | 0.168 mm | 7.4 mm | Fails — scale 1.4× |
| 21″ gantry console | 1920×1200 | 0.236 mm | 10.4 mm | Passes at 10 mm; scale 1.2× if gloved |
Designers deliver at the design resolution with the scale factor stated in the handoff. Engineering applies the factor to match the target display. Designers do not hand-pick larger sizes for a specific device, and engineers do not re-lay-out to fill space. Both shortcuts break the proportional guarantee that makes the touch floor hold.
Viewing distance and content
Beyond about 1.5 m, scale alone stops being enough. A wall display read from four metres needs less on it, not merely bigger type.
| Context | Distance | Factor | Content strategy |
|---|---|---|---|
| Reporting workstation | 50–70 cm | 1× | Full density. The design baseline. |
| Bedside / cart | 70–120 cm | 1.2–1.6× | Full content, larger targets. Touch-first. |
| Procedure console | 1–2 m | 1.35× | Reduce to the active task. Hide administrative content. |
| Handover / wall board | 2–4 m | 1.75× | Show one thing per region. No tables, no metadata, no icon-only controls. |
Choosing a display
Where a product ships with its own hardware, the display is part of the design. Minimum characteristics for a surface that renders clinical imagery and this system's UI:
| Characteristic | Minimum | Why |
|---|---|---|
| Colour gamut | 100 % sRGB | Alarm hues render as specified. Below this, IEC red drifts. |
| Contrast ratio | 1000:1 | Published text contrast holds in practice. |
| Brightness | 300–1200 cd/m², adjustable | Same panel must work in a bright ward and a darkened reading room. |
| Gamma | 2.2, calibratable | Consistent rendering across a fleet. |
| Viewing angle | ≥ 170° H and V | Colour and contrast hold when read off-axis — the normal case at a bedside. |
| Refresh rate | ≥ 60 Hz | Waveform rendering without motion artefact. |
| Touch latency | ≤ 50 ms | Above this, users double-tap. See the pending-state rule. |
| Surface | Anti-reflective, glove-compatible | Reflections defeat contrast; gloves defeat capacitive thresholds. |
These are guidelines for the UI layer. Displays used for primary diagnostic reading — where a clinician makes a diagnosis from the image itself — carry additional regulatory requirements including higher bit-depth greyscale and DICOM GSDF calibration. Those are outside this design system's scope; consult your regulatory lead.
Do's and don'ts
scale 1.6×
target 1920 × 1080, 15″
touch 12.2 mm ✓
Handoff states the factor and the resulting physical target. Verifiable by anyone, testable in CI.
"buttons bumped to 56 px
on the monitor build"
touch ? mm
Hand-picked pixel sizes for one device. Type and spacing no longer match, and nobody can state the physical target size.
More do's and don'ts
pixel 0.173 mm
scale 1.6×
touch 12.2 mm ✓
The physical result is computed and stated, so anyone can check it.
scale “looks about right”
touch ? mm
No pixel size, no factor, no physical target. The touch floor cannot be shown to hold.
At distance the display shows less, larger. Findings and confidence are removed.
The same dense table, enlarged. At 4 m it is a wall of unreadable text that passes a font-size rule.
Clinical safety notes
Trace these in your risk file (ISO 14971) and your usability engineering file (IEC 62366-1).
- 10 mm touch floor, 12 mm for gloved / time-critical / in-motion use. Mitigates: mis-tap selecting the wrong patient, wrong lead, or the adjacent destructive control.
- Whole-interface scaling, never per-element. Mitigates: enlarged text with unchanged hit areas — an interface that looks accessible and is not.
- Scale factor recorded per deployment. Mitigates: an untested display configuration reaching a ward; makes the touch floor verifiable rather than assumed.
- Content reduced at distance, not merely enlarged. Mitigates: unreadable wall displays that technically meet a font-size rule.
- Display minimums specified. Mitigates: alarm hues rendering outside their specified appearance on an under-spec panel.
- Touch latency ≤ 50 ms. Mitigates: duplicate activation of irreversible actions caused by a user re-tapping an apparently unresponsive control.
Related
- Typography — the 12 px floor and reading at distance.
- Button — sizes and the touch-safe default.
- Tokens — why every scale token is rem-based.