skip to content

In atomic design, which page variations would you build for a cloud admin console's resource-detail template, and what does each one test?

level: middleimportance: should knowfreq 38%

answer

  1. same skeleton, different content
  2. extremes, not averages
  3. sparse, heavy, long, missing
  4. partial failure on one panel
  5. what each role can see

basics

~20 s

Build pages for the extremes real data produces: first use, heavy volume, shortest and longest strings, missing optional fields, partial failure, and each permission role. Each tests whether the template and its parts survive content they will actually meet.

solid answer

~40 s

In atomic design the template stays constant while content varies, so pages are where you articulate those variations. For a resource-detail screen in a cloud console I would build: a **first-use** page (a new project with no activity or attachments, so suppressed regions must collapse cleanly); a **volume** page (sixty tags, thirty attached disks); a **string-length** page (the shortest and the longest real names, including identifiers with no spaces); a **missing-data** page (no description, no owner, a metric not offered in that region); a **degraded** page (the resource in a failed state, one panel's data unavailable while the rest loaded); and one page per **permission role**, since an owner, an operator and a read-only viewer see different actions and regions. Each failure points back to a specific lower level.

go deeper

for a junior

Recall that one template has many pages and name the main variation kinds: sparse, heavy, long strings, missing data, errors and permission roles.

for a middle

Explain what each variation tests and which level a failure usually points to, and why variations come from the data model and real ranges rather than guesswork.

for a senior

Show how you choose a reviewable set on a real product: grounding ranges in production data, picking worst-case combinations, and routing each failure to its owning level.

for a principal

Consider who owns variation coverage at scale: the system team for shared templates, product teams for their screens, and how that split shows up in review gates.

## Why variations live at the page level In Brad Frost's **atomic design**, a **template** is the layout skeleton and a **page** is that skeleton filled with real, representative content. Frost states that pages "provide a place to articulate variations in templates", and that these variations "directly influence how the underlying molecules, organisms, and templates are constructed". The skeleton is the same in every case; the content is not, and a pattern that looks right for typical content can fail at the extremes. A single page with typical data therefore proves very little. The value comes from a deliberate **variation set**: the cases real data will produce, chosen so that each one stresses a different decision in the lower levels. ## A variation set for a resource-detail template Consider a cloud provider's admin console. The resource-detail template has a header (name, status), a summary panel of properties, a tabbed configuration area, a panel of related resources and an action bar. | Variation | Example in the console | What it tests | Where a failure usually lands | |---|---|---|---| | **First use / sparse** | New project: no activity history, no attached disks, no tags | Whether suppressed regions collapse without leaving holes or orphaned headings | Template region rules | | **Volume** | One tag versus sixty; one disk versus thirty | Wrapping, overflow and the point where a list stops growing inline | Organism | | **String length** | A four-character name versus the maximum; generated identifiers with no spaces; a long owner address | Truncation, wrapping, column sharing | Atom or molecule | | **Missing data** | No description, no owner, a metric not offered in this region | Whether an absent value is shown deliberately instead of blank space or a raw null | Molecule | | **Degraded** | Resource in a failed state; the metrics panel failed while the rest loaded | Status emphasis and partial-failure layout | Organism and template | | **Permission** | Owner, operator, read-only viewer, billing-only role | An action bar holding zero to six actions; regions a role cannot see | Organism and template | ## How to choose the set 1. **Start from the data model.** Every optional field, every unbounded list and every enumerated status is a candidate variation. 2. **Take ranges from production.** Typical and extreme name lengths, tag counts and attachment counts, so the variations are grounded rather than guessed. 3. **Enumerate roles.** List what each role can see and do on this screen; roles that change the layout get their own page. 4. **List failure modes.** A dependency that is down, a panel that times out, data that is stale. 5. **Combine sparingly.** Build a few deliberate worst-case combinations, such as a long name with a read-only viewer in a failed state, instead of the full cross product, which grows faster than anyone will review. ## Permission-dependent pages deserve extra care Frost's own list includes administrators seeing "additional buttons and options" that others do not. In a console this is common and easy to under-test: - the action bar may shrink from six actions to none, and an empty bar with its divider still drawn is a template defect - a whole region, such as billing details, may be absent for some roles, so its neighbours must reflow rather than leave a gap - a role that sees data but cannot change it needs the same layout to read as view-only, which usually changes a molecule, not the page ## Signs a variation set is too thin - every page shows a healthy resource, so status emphasis has never been reviewed - every page is viewed as the owner, so no one has seen the screen with fewer actions - the longest name on any page was typed by a designer, not taken from real ranges - no page has an optional field left empty ## What stays out of this list Some states are specified by their own components rather than by the page: how an empty list is designed, how loading is shown, and how translated text expands. The page shows *where* those states appear on the screen; the owning component's specification says *how* they look. ## The same practice on every platform Nothing here is web-specific. A native mobile team builds the same set as preview fixtures per variation, and a design team builds it as duplicated editor frames filled with the matching data. What matters is that the set exists, is reviewed, and that each failure it exposes is sent back to the level that owns it.

  • Why not build every combination of every variation?
    The cross product grows multiplicatively and nobody reviews hundreds of pages, so coverage becomes nominal. Build each variation alone, then a handful of deliberate worst-case combinations where two stresses interact, such as a maximum-length name in a narrow panel for a read-only role. Coverage you actually look at beats coverage you only generated.
  • A read-only viewer's page shows an action bar with no actions. Whose defect is that?
    Not the page's. The template or the action-bar organism needs a rule for the zero-actions case: remove the bar and its divider, and let the regions around it reflow. The page found the defect; the fix belongs to the level that decided the bar is always drawn.

saying these in an interview costs you the question

  • One page with typical data is enough to validate a template.
  • Each variation needs its own separate template.
  • Permissions are a backend concern and never change the layout.
  • The API always returns every field, so missing data cannot happen.
  • Rigour means building every combination of every variation.