skip to content

Why is screen-size class a separate coverage axis from a handheld's capability tier?

level: middleimportance: nice to knowfreq 28%

answer

  1. Two independent axes, not one
  2. Geometry failures, not scarcity failures
  3. Width, height and density differ
  4. Larger text shrinks usable space
  5. Cross the width where arrangements switch

basics

~20 s

Screen size and device capability vary independently: large low-cost displays and small powerful devices both exist. Layout failures — clipped labels, controls out of reach, a keyboard covering the focused field — track the screen class, not the hardware's speed.

solid answer

~50 s

A target list needs a screen axis of its own because the two axes do not correlate: a large inexpensive display sits on weak hardware, and a small premium device has plenty of memory. The failures also differ in kind. A capability failure is about scarcity and timing; a screen-class failure is about geometry — a label that fits at one width and clips at another, a primary control pushed below the visible area on a short screen, an on-screen keyboard covering the field being typed into, a wider arrangement that only appears above some width and is therefore never executed, and edges the system reserves for its own indicators that the app must not draw under. **User-chosen text scaling belongs on this axis too**: a larger text setting effectively shrinks the usable area and breaks the same layouts a small display breaks.

code

pseudocode · 13 lines
pseudocode
screen_rows = [
  { name: "narrow",      width_units: 320, height_units: 568, text_scale: 1.0 },
  { name: "narrow_big_text", width_units: 320, height_units: 568, text_scale: 1.6 },
  { name: "wide",        width_units: 900, height_units: 1200, text_scale: 1.0 }
]

for row in screen_rows:
    open_screen("checkout", row)
    focus(field: "card_number")            # raises the on-screen keyboard
    assert is_visible(field: "card_number")
    assert is_visible(control: "pay") and is_reachable(control: "pay")
    assert no_text_truncated(screen)
    assert nothing_interactive_under(system_reserved_edges)

go deeper

for a junior

Recall that handheld displays differ in both physical size and how much content they fit, and that a layout looking right on one device can clip text or push a button out of reach on another.

for a middle

Explain why width, height and density are three separate properties, and name what each one breaks: wrapping and truncation, what survives an on-screen keyboard, and how much content a logical size actually holds.

for a senior

Demonstrate the judgement to pick rows that earn their place — the smallest supported width, a row on each side of a layout switch, and the largest supported text setting — and to assert layout facts rather than relying on someone looking at the result.

for a principal

Own this axis as a commitment: every row multiplies the run, so be able to say which rows produce failures nothing else produces, and how the axis gets re-cut when the shape of shipping displays changes.

Screen class and capability tier are frequently collapsed into one idea — "small old phone" versus "big new phone" — and the collapse costs coverage, because the two vary independently and fail in different ways. ## Two axes that do not correlate A large display is not a promise of memory or processing power: inexpensive large-screen devices are a whole market segment, and compact premium devices pair a small display with the fastest hardware available. Treating the screen as a proxy for capability produces two blind spots at once — big-and-slow, and small-and-fast — and neither is rare in the field. The failures also arrive from different mechanisms: - A **capability** failure is about **scarcity**: something took too long, ran out, or was reclaimed. It is timing-sensitive and often intermittent. - A **screen-class** failure is about **geometry**: something did not fit, was pushed out of view, or was covered. It is deterministic — at that size it always fails, which is why a single correct row catches it every time. ## What only fails at a particular screen class | Symptom | Where it shows up | What a case should assert | | --- | --- | --- | | Text clipped or ellipsised | narrow widths, long translations, large text settings | the full label is present, not merely that some element exists | | Primary action out of reach | short screens, or once the keyboard is up | the action is visible and reachable in the current layout | | Field hidden while typing | short screens with an on-screen keyboard raised | the focused field remains visible after the keyboard appears | | A wider arrangement never exercised | above the width where the layout switches | the alternative arrangement's navigation and actions work | | Content drawn under reserved edges | devices reserving space for system indicators | nothing interactive sits beneath the reserved regions | ## Width, height and density are three separate properties They are routinely treated as one number, and they are not: 1. **Width** decides wrapping, truncation and which arrangement a responsive layout selects. 2. **Height** decides what is visible without scrolling and what survives an on-screen keyboard taking half the screen. 3. **Density** decides how many physical dots a logical unit occupies. Two devices can share a logical size and differ hugely in physical size, or share a physical size and differ in how much content fits. A row that only records "large" or "small" cannot express the case that fails at a wide-but-short size, which is exactly where a tall form loses its submit control. ## Text scaling is part of this axis Users can enlarge text system-wide, and many do. A larger setting is arithmetically equivalent to shrinking the display: the same wrapping, truncation and overflow failures appear, plus a few of their own where a fixed-height container was sized around default text. Because it multiplies with a small display rather than replacing it, **the smallest supported width at the largest text setting is usually the single most productive row on this axis** — it compresses the layout harder than any real device does on its own. ## Choosing the rows - Take the smallest supported width, since most compression failures surface there first. - Take one row on each side of a width where the layout switches arrangement, because the wider arrangement is a distinct path with its own navigation and its own defects. - Take one row at the largest text setting the product claims to support. - Assert on layout facts — the control is visible, the text is not truncated, the focused field is not covered, nothing interactive sits under reserved edges — rather than on a human glance at the result. ## Common mistakes - Assuming a big display implies a fast device, or that a small one implies a slow one. - Checking one size and recording layout as covered, when the interesting behaviour is the switch between arrangements. - Ignoring user-chosen text size entirely, which is both a large real population and the cheapest way to reproduce compression failures. - Confusing density with size, so two rows that look different in the list exercise the same layout decisions. - Treating layout failures as cosmetic, when a control that cannot be reached is a functional outage for the people who meet it.

  • If the list has only one screen row today, which row would you add first and why?
    The smallest supported width at the largest text setting the product claims to support. That combination compresses the layout harder than any single device does, so it reproduces most clipping, overflow, out-of-reach and covered-field failures in one row, and it is deterministic — if it fails there, it fails every time.
  • Why is a wider arrangement that only appears above a width threshold a risk when no row crosses that threshold?
    Because it is a distinct path nothing ever executes. The arrangement, the navigation between its panes and the placement of the primary action are all different code, so its defects reach users without ever failing a run. A layout switch is a branch, and an untested branch is untested regardless of how good coverage looks elsewhere.

saying these in an interview costs you the question

  • Assumes a big display implies a fast device
  • Checks one size and calls layout covered
  • Ignores user-chosen text scaling entirely
  • Treats density as interchangeable with width
  • Calls layout failures cosmetic rather than functional