skip to content

In a design system, what content structure should an insurance claim-detail template specify, and why is identical filler text in every region not enough?

level: middleimportance: should knowfreq 36%

answer

  1. made from, not what it is
  2. type, length range, count
  3. image ratio, optional or required
  4. headings and landmark regions
  5. filler hides the extremes

basics

~20 s

It should specify what each region's content is made of: type, length range, count, image ratio, whether it is optional, and heading and landmark structure. Identical filler hides the long, empty and many-item cases that break real layouts.

solid answer

~40 s

Frost quotes Mark Boulton: you can design without knowing the content, but not without knowing its **structure** — what it is made from. For a claim-detail template I would state per region: the **content type**; a **length range** (claim title 10 to 80 characters); a **count range** (0 to 20 documents, 1 to 30 timeline events); **image ratios** (damage photos, often portrait from phones); whether the region is **optional** and what happens when empty; and the **semantic structure** — heading levels and one main landmark with the sidebar as complementary. Identical filler of the same length in every region looks tidy and hides exactly the cases that break layouts: a long adjuster name, no documents yet, forty timeline events. Structured placeholders that state their ranges, plus extreme examples, catch those before real content does.

go deeper

for a junior

Recall that a template shows what content is made from — types, lengths, counts, image sizes — rather than the content itself.

for a middle

Explain which properties to specify per region and why uniform filler hides long, empty and many-item cases. Know that one main landmark per page is the guidance.

for a senior

Show how you would derive ranges from real claims data, place heading levels and landmarks at the template, and hand the ranges to engineering and content.

for a principal

Discuss how content-structure specs become a contract among design, content and engineering, and who maintains the ranges as the product evolves.

## Content structure versus content In **atomic design**, a **template** is a page-level skeleton that places organisms into a layout and shows the **content structure** rather than the final content. Brad Frost leans on Mark Boulton here: *you can create good experiences without knowing the content; what you can't do is create good experiences without knowing your content structure — what your content is made from, not what your content is*. Frost adds that templates should articulate properties such as **image sizes and character lengths**, providing guardrails for the content that fills each pattern. ## What to specify for each region For the claim-detail screen of an insurance claims portal: | Region | Type | Length or count | Other structure | |---|---|---|---| | Claim summary | title, type, status, dates | title 10 to 80 characters | required; top-level heading for the screen | | Status timeline | list of events | 1 to 30 events, notes up to 200 characters | newest first; section heading | | Documents and photos | files and images | 0 to 20 items | photos landscape or portrait; empty state when none | | Messages | thread | 0 to many, each up to several paragraphs | optional; section heading | | Next steps | actions | 1 to 4, labels up to 30 characters | complementary to the main content | The numbers are the team's decisions, informed by real claims data; the point is that they are written down. ## Why identical filler misleads Filler text of the same length in every region produces a tidy mock-up and hides the cases that fail in production: - **Long values.** A 60-character adjuster name or a claim title in a language with long compound words wraps and pushes the timeline down. - **Empty regions.** A new claim has no documents and no messages; the layout may collapse into an odd gap. - **Many items.** A disputed claim with forty timeline events turns a neat column into a long scroll that buries the next steps. - **Missing media.** A claim filed by phone call has no photos; the image region needs a defined empty shape. - **Unusual media.** Phone photos arrive in portrait; a region drawn for landscape crops them badly. Frost's person-block example makes the same point: if a name wraps onto five lines inside a pattern, the problem has to be fixed at a more atomic level — and structured placeholders reveal it before real content does. ## Structure includes semantics Content structure is not only visual. The template is the natural place to fix the screen's **heading hierarchy** and **landmark regions**, because it is the level that sees the whole page: - WCAG 2.2 success criterion **1.3.1 Info and Relationships** (Level A) expects structure conveyed visually to be programmatically determinable, and **2.4.6 Headings and Labels** (Level AA) expects headings to describe topic or purpose. - **2.4.1 Bypass Blocks** (Level A) expects a way to skip repeated blocks such as the header; landmarks are one common way to provide it. - The WAI-ARIA Authoring Practices landmark guidance says each page should have **one main landmark**, and that banner, main, complementary and contentinfo should be top-level landmarks. On the web those regions are usually expressed with landmark elements; a native mobile screen expresses the same grouping through its accessibility containers and heading traits. Either way the template, not each organism, decides the page-level structure. ## Writing placeholders that carry structure 1. **Label each placeholder with its range** — 'Claim title, 10 to 80 characters' — instead of generic filler. 2. **Show the extremes side by side**: shortest, typical, longest; zero, one and many items. 3. **Mark optional regions** and draw their empty behaviour explicitly. 4. **Record image ratios and orientation** for every media region. 5. **Hand the ranges to engineering and content** so validation and writing guidelines match the design. ## Common mistakes - Designing every region around one ideal claim. - Treating heading order and landmarks as an engineering afterthought instead of part of the template. - Specifying lengths nobody checked against real claims.

  • Where do the length and count ranges come from?
    From real content: existing claims data, the claims team's knowledge of edge cases and the content guidelines. Designers propose ranges, the data confirms or corrects them, and engineering reflects them in validation. Ranges invented without evidence give false confidence.
  • Should the template or each organism own its section heading?
    The organism can render the heading, but the template should decide its level, because only the template knows the page's hierarchy. A timeline organism placed under the claim summary on one screen and at top level on another needs a different heading level in each.

saying these in an interview costs you the question

  • Identical filler text in every region is enough to review a template.
  • Content structure can wait until real content exists.
  • Heading order and landmarks are an engineering detail, not a template decision.
  • A page may have as many main landmarks as it has columns.
  • Only visual size matters; empty and many-item cases can be ignored.