A claims portal's claim-detail template checks each claim's status to decide whether to show the payment region; what is wrong with that, and how would you restructure it?

seniorshould knowfreq 32%

answer

business rules leaked into layout
cannot render with placeholders
regions plus empty behaviour
the application fills the regions
second template only for a new skeleton

basics

~20 s

The template has absorbed business rules, so it cannot render with placeholders and changes whenever claim rules do. Let the template define regions and how an empty one collapses; the application decides which organism fills each region.

solid answer

~50 s

A template's job is layout: which regions exist, their order and sizing, and what happens when a region is empty. 'Show payment once approved, show an appeal panel when denied, hide amounts during fraud review' are business rules that change with the claims operation and differ by product line. Put them in the template and it must know claim data, can no longer be reviewed with placeholder content, and grows a branch for every status. I would restructure it so the template exposes named regions — primary, supporting, actions — with documented empty behaviour, and the application layer maps claim state to which organism fills which region. If a status truly needs a different skeleton, that is a second template, not a conditional. The check: the template renders completely with placeholder content and no claim object.

A template's job is **layout**: which regions exist, their order and sizing, and what happens when a region is empty. 'Show payment once approved, show an appeal panel when denied, hide amounts during fraud review' are **business rules** that change with the claims operation and differ by product line. Put them in the template and it must know claim data, can no longer be reviewed with placeholder content, and grows a branch for every status. I would restructure it so the template exposes named regions — primary, supporting, actions — with documented empty behaviour, and the application layer maps claim state to which organism fills which region. If a status truly needs a different skeleton, that is a second template, not a conditional. The check: the template renders completely with placeholder content and no claim object.

code

pseudocode · 16 lines

pseudocode

template ClaimDetail
  regions: summary, timeline, documents, messages, actions, sidebar
  empty behaviour:
    documents, messages -> collapse without gap
    actions             -> collapse
  // no claim data read here

screen ClaimDetailScreen(claim, viewer)
  fill ClaimDetail:
    summary  <- ClaimSummary(claim)
    timeline <- StatusTimeline(claim.events)
    actions  <- when claim.status
                  approved   -> PaymentDetails(claim, viewer)
                  denied     -> AppealPanel(claim)
                  otherwise  -> nothing
    sidebar  <- NextSteps(claim, viewer)

go deeper

for a junior

Recall that a template is layout and structure; deciding what a particular claim should show is not its job.

for a middle

Explain which concerns a template owns — regions, order, sizing, empty behaviour — and why business rules inside it block placeholder rendering and reuse.

for a senior

Walk through restructuring a template that reads domain data: naming regions, defining empty behaviour, moving rules to the application, and choosing when a second template is justified.

for a principal

Discuss how the template boundary divides ownership between the design system and product teams, and what that means for reuse across portals.

The symptom

In atomic design, a template places organisms into a layout and shows content structure, while pages are instances filled with real content. In practice the template becomes a reusable layout — a design-editor frame, a coded layout component, a native screen scaffold. Trouble starts when that layout begins to read the data it displays.

In an insurance claims portal, the claim-detail template contains code like 'if the claim is approved, show the payment region; if it is denied, show the appeal region; if it is under fraud review, hide the amounts'. It works, and it slowly turns the skeleton into the place where claims policy lives.

Why it is a problem

The template needs domain data. It can no longer render with placeholder content in a component workshop or design review, because every branch needs a real claim.
Business change edits layout. When the claims operation adds a 'partially approved' status, someone edits the page skeleton.
Branches multiply. Statuses times product lines (auto, home, travel) times roles (policyholder, broker) produce combinations nobody reviewed.
Reuse dies. A second portal for brokers wants the same skeleton with different rules, and cannot have it.
Ownership blurs. Design-system engineers end up reviewing insurance policy logic.

What the template should own, and what it should not

Concern	Template	Application layer
Which regions exist and their order	yes	no
Relative size and reflow of regions	yes	no
How an empty region collapses	yes	no
Heading levels and landmark roles per region	yes	no
Which organism fills a region for this claim	no	yes
Whether this user may see settlement amounts	no	yes

Restructuring

Name the regions by role, not by content: primary, supporting, actions, messages.
Define empty behaviour for each: collapse without a gap, or show a neutral placeholder.
Move the rules out: the application reads the claim and decides, for example, that the actions region gets the payment organism when approved and the appeal organism when denied.
Render the template with placeholders in the component workshop to prove it no longer needs a claim.
Test the rules separately, as application logic with claim fixtures, where they can be exercised exhaustively.

When a second template is right

Sometimes a state changes the skeleton itself, not just what fills a region. A claim under litigation might replace the whole main area with a restricted notice and a legal-contact region, with a different heading structure. That is a second template, chosen by the application. The test is simple: if the difference is 'which organism fills region X', keep one template; if it is 'the regions themselves differ', make another.

Across platforms

The same separation holds on native mobile: a screen scaffold defines regions and spacing, and feature code decides which views fill them. The design editor mirrors it with a frame whose regions accept any organism instance. Whatever the platform, the skeleton should not know what a claim is.

Common mistakes

Hiding a region by checking status inside the layout instead of simply not filling it.
Moving the rules into a neighbouring organism, which only relocates the coupling.
Creating a template per status when only one region's content differs.
Leaving empty behaviour undefined, so an unfilled region leaves a visible hole.

## The symptom In **atomic design**, a **template** places organisms into a layout and shows content structure, while **pages** are instances filled with real content. In practice the template becomes a reusable layout — a design-editor frame, a coded layout component, a native screen scaffold. Trouble starts when that layout begins to read the data it displays. In an insurance claims portal, the claim-detail template contains code like 'if the claim is approved, show the payment region; if it is denied, show the appeal region; if it is under fraud review, hide the amounts'. It works, and it slowly turns the skeleton into the place where claims policy lives. ## Why it is a problem - **The template needs domain data.** It can no longer render with placeholder content in a component workshop or design review, because every branch needs a real claim. - **Business change edits layout.** When the claims operation adds a 'partially approved' status, someone edits the page skeleton. - **Branches multiply.** Statuses times product lines (auto, home, travel) times roles (policyholder, broker) produce combinations nobody reviewed. - **Reuse dies.** A second portal for brokers wants the same skeleton with different rules, and cannot have it. - **Ownership blurs.** Design-system engineers end up reviewing insurance policy logic. ## What the template should own, and what it should not | Concern | Template | Application layer | |---|---|---| | Which regions exist and their order | yes | no | | Relative size and reflow of regions | yes | no | | How an empty region collapses | yes | no | | Heading levels and landmark roles per region | yes | no | | Which organism fills a region for this claim | no | yes | | Whether this user may see settlement amounts | no | yes | ## Restructuring 1. **Name the regions** by role, not by content: primary, supporting, actions, messages. 2. **Define empty behaviour** for each: collapse without a gap, or show a neutral placeholder. 3. **Move the rules out**: the application reads the claim and decides, for example, that the actions region gets the payment organism when approved and the appeal organism when denied. 4. **Render the template with placeholders** in the component workshop to prove it no longer needs a claim. 5. **Test the rules separately**, as application logic with claim fixtures, where they can be exercised exhaustively. ## When a second template is right Sometimes a state changes the skeleton itself, not just what fills a region. A claim under litigation might replace the whole main area with a restricted notice and a legal-contact region, with a different heading structure. That is a **second template**, chosen by the application. The test is simple: if the difference is 'which organism fills region X', keep one template; if it is 'the regions themselves differ', make another. ## Across platforms The same separation holds on native mobile: a screen scaffold defines regions and spacing, and feature code decides which views fill them. The design editor mirrors it with a frame whose regions accept any organism instance. Whatever the platform, the skeleton should not know what a claim is. ## Common mistakes - Hiding a region by checking status inside the layout instead of simply not filling it. - Moving the rules into a neighbouring organism, which only relocates the coupling. - Creating a template per status when only one region's content differs. - Leaving empty behaviour undefined, so an unfilled region leaves a visible hole.

The team says moving the rules out just relocates the complexity; why is that still better?
Because it relocates it to where it belongs and can be tested. Rules in the application layer are tested with claim fixtures, exhaustively and without rendering; the template becomes testable with placeholders alone. The total logic is the same, but each part now has one reason to change and one owner.
How does this separation help a second, broker-facing portal?
The broker portal reuses the same claim-detail template and fills its regions under its own rules, such as showing commission details in the sidebar. With rules baked into the template, it would need a fork or new branches inside the shared skeleton.

saying these in an interview costs you the question

Checking claim status inside the template keeps logic close to where it shows.
A template should be able to decide who may see settlement amounts.
Every claim status deserves its own template.
Moving the rules into the neighbouring organism fixes the coupling.
Empty-region behaviour can be left for each screen to improvise.

A claims portal's claim-detail template checks each claim's status to decide whether to show the payment region; what is wrong with that, and how would you restructure it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The symptom

Why it is a problem

What the template should own, and what it should not

Restructuring

When a second template is right

Across platforms

Common mistakes

▾common follow-ups2 questions

▾red flags5 flags

The symptom

Why it is a problem

What the template should own, and what it should not

Restructuring

When a second template is right

Across platforms

Common mistakes

answer

go deeper